nd remote
attestation. Otherwise you implicitly trust that key anyway. In almost
all cases refusing to trust db gives you a false sense of security
without any real improvement. I don't think it's obvious it should be
the default.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from
g.
A kernel parameter that refuses to trust the contents of DB would be
acceptable, but DBX needs to be used unconditionally.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.o
that refuses to trust the contents of DB would be
acceptable, but DBX needs to be used unconditionally.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
attestation. Otherwise you implicitly trust that key anyway. In almost
all cases refusing to trust db gives you a false sense of security
without any real improvement. I don't think it's obvious it should be
the default.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send
.
Just add a sysfs knob that lets you drop the db keys and incorporate
that into the TPM management code.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
to discover that it's easily circumvented.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
+-
drivers/platform/x86/toshiba_acpi.c | 30 +++-
15 files changed, 485 insertions(+), 65 deletions(-)
create mode 100644 Documentation/platform/x86-laptop-drivers.txt
create mode 100644 drivers/platform/x86/dell-smo8800.c
--
Matthew Garrett | mj...@srcf.ucam.org
signature.asc
Description
Hm. Sorry, I thought I'd picked that one up. I'll send it in a couple of
days.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
On Tue, Jun 10, 2014 at 09:24:53PM -0400, Mimi Zohar wrote:
On Tue, 2014-06-10 at 22:40 +0100, Matthew Garrett wrote:
The hole is that the system trusts keys that you don't trust. The
appropriate thing to do is to remove that trust from the entire system,
not just one layer of the system
On Tue, Jun 10, 2014 at 11:08:15PM -0400, Mimi Zohar wrote:
On Wed, 2014-06-11 at 03:22 +0100, Matthew Garrett wrote:
Providing a userspace mechanism for selectively dropping keys from the
kernel seems like a good thing?
No, patch KEYS: verify a certificate is signed by a 'trusted' key
ces, so maybe reverse the check?
Seems fair. I probably won't have time to resend for a couple of days -
if it's easier, please do just rework this yourself.
--
Matthew Garrett
On Sun, 2014-06-01 at 22:45 +0200, Andreas Noever wrote:
> On Sun, Jun 1, 2014 at 6:07 PM, Matthew Garrett
> wrote:
> > Yeah, it seems I don't need the suspend quirk - the NHI is still there
> > without it. I still think we should make the quirk general rather than
> >
down after suspend.
The easiest way to handle this is to special-case it in the Linux-specific
OSI handling code. If we see Darwin, we should answer true and then disable
all other _OSI vendor strings.
Signed-off-by: Matthew Garrett
---
drivers/acpi/acpica/utosi.c | 1 +
drivers/acpi/osl.c
Darwin support and fixing up the behavioural quirks that are exposed as a
result.
--
Matthew Garrett | matthew.garr...@nebula.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
with the
battery.
Signed-off-by: Matthew Garrett
---
drivers/acpi/sbs.c | 51 +++
1 file changed, 43 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/sbs.c b/drivers/acpi/sbs.c
index b1df4ee..32aecea 100644
--- a/drivers/acpi/sbs.c
+++ b/drivers
Apple hardware continues to expose an ACPI AC charger even when using SBS
to report battery state. The charger status byte returns all 0s in this case.
Since the spec requires that bit 4 be 1 at all times, assume that there's not
really a charger if it's set to zero.
Signed-off-by: Matthew
e platform is running in Darwin
mode.
Signed-off-by: Matthew Garrett
---
drivers/acpi/pci_root.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index d388f13..f04b6b9 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/
On Sun, 2014-06-01 at 12:11 +0200, Andreas Noever wrote:
> On Sun, Jun 1, 2014 at 1:51 AM, Matthew Garrett
> wrote:
> > This seems to be working well on my MBP. It appears to broadly work on
> > my Mac Pro, which has Thunderbolt 2 hardware - I added the PCI ID, and
> >
Adding extra device IDs is enough to get this working on the second-gen
Thunderbolt controller in the Mac Pro.
Signed-off-by: Matthew Garrett
---
drivers/pci/quirks.c | 2 ++
drivers/thunderbolt/nhi.c| 5 +
drivers/thunderbolt/switch.c | 5 -
3 files changed, 11 insertions
Adding extra device IDs is enough to get this working on the second-gen
Thunderbolt controller in the Mac Pro.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
drivers/pci/quirks.c | 2 ++
drivers/thunderbolt/nhi.c| 5 +
drivers/thunderbolt/switch.c | 5 -
3
On Sun, 2014-06-01 at 12:11 +0200, Andreas Noever wrote:
On Sun, Jun 1, 2014 at 1:51 AM, Matthew Garrett
matthew.garr...@nebula.com wrote:
This seems to be working well on my MBP. It appears to broadly work on
my Mac Pro, which has Thunderbolt 2 hardware - I added the PCI ID, and
loading
with the
battery.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
drivers/acpi/sbs.c | 51 +++
1 file changed, 43 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/sbs.c b/drivers/acpi/sbs.c
index b1df4ee..32aecea 100644
--- a/drivers
Apple hardware continues to expose an ACPI AC charger even when using SBS
to report battery state. The charger status byte returns all 0s in this case.
Since the spec requires that bit 4 be 1 at all times, assume that there's not
really a charger if it's set to zero.
Signed-off-by: Matthew
is running in Darwin
mode.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
drivers/acpi/pci_root.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index d388f13..f04b6b9 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers
Darwin support and fixing up the behavioural quirks that are exposed as a
result.
--
Matthew Garrett | matthew.garr...@nebula.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
.
The easiest way to handle this is to special-case it in the Linux-specific
OSI handling code. If we see Darwin, we should answer true and then disable
all other _OSI vendor strings.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
drivers/acpi/acpica/utosi.c | 1 +
drivers/acpi
On Sun, 2014-06-01 at 22:45 +0200, Andreas Noever wrote:
On Sun, Jun 1, 2014 at 6:07 PM, Matthew Garrett
matthew.garr...@nebula.com wrote:
Yeah, it seems I don't need the suspend quirk - the NHI is still there
without it. I still think we should make the quirk general rather than
tying
?
Seems fair. I probably won't have time to resend for a couple of days -
if it's easier, please do just rework this yourself.
--
Matthew Garrett matthew.garr...@nebula.com
*dev)
struct pci_dev *sibling = NULL;
struct pci_dev *nhi = NULL;
- if (!dmi_check_system(apple_thunderbolt_whitelist))
+ if (!dmi_match(DMI_BOARD_VENDOR, "Apple Inc."))
return;
if (pci_pcie_type(dev) != PCI_EXP_TYPE_DOWNSTREAM)
return;
--
Matthew Garrett
))
+ if (!dmi_match(DMI_BOARD_VENDOR, Apple Inc.))
return;
if (pci_pcie_type(dev) != PCI_EXP_TYPE_DOWNSTREAM)
return;
--
Matthew Garrett matthew.garr...@nebula.com
d code to the PCI core? I've got an implementation that
currently fails for reasons I haven't debugged, I'll see if I can get it
working today.
--
Matthew Garrett
Adding the PCI IDs for the Thunderbolt 2 device in the Mac Pro seems to
work, with the possible exception of hotplug - I'll look into that some
more. I also have a new set of the ACPI patches, which I'll try to send
out today.
--
Matthew Garrett
Adding the PCI IDs for the Thunderbolt 2 device in the Mac Pro seems to
work, with the possible exception of hotplug - I'll look into that some
more. I also have a new set of the ACPI patches, which I'll try to send
out today.
--
Matthew Garrett matthew.garr...@nebula.com
to the PCI core? I've got an implementation that
currently fails for reasons I haven't debugged, I'll see if I can get it
working today.
--
Matthew Garrett matthew.garr...@nebula.com
Thanks, if there are no objections I'll apply that.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.h
Could you include a description in the patch for why this is necessary?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.
That's not being merged without a Signed-off-by:.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.h
That's not being merged without a Signed-off-by:.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
Could you include a description in the patch for why this is necessary?
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
Thanks, if there are no objections I'll apply that.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
aves? What's the actual difference in state before and after suspend?
--
Matthew Garrett
the actual difference in state before and after suspend?
--
Matthew Garrett matthew.garr...@nebula.com
On Fri, 2014-04-11 at 21:10 +0800, Shuduo Sang wrote:
> Hi Matthew,
>
> This patch is not in your recent for_linus branch. Why?
I'm sorry, I'd somehow missed it. I'll get it in the next pull.
--
Matthew Garrett
On Fri, 2014-04-11 at 21:10 +0800, Shuduo Sang wrote:
Hi Matthew,
This patch is not in your recent for_linus branch. Why?
I'm sorry, I'd somehow missed it. I'll get it in the next pull.
--
Matthew Garrett matthew.garr...@nebula.com
Alienware products
alienware-wmi: cover some scenarios where memory allocations would fail
Matthew Garrett (1):
toshiba_acpi: Fix whitespace
Mattia Dongili (1):
sony-laptop: remove useless sony-laptop versioning
Scott K Logan (1):
fujitsu-tablet: add support for Lifebook T90
products
alienware-wmi: cover some scenarios where memory allocations would fail
Matthew Garrett (1):
toshiba_acpi: Fix whitespace
Mattia Dongili (1):
sony-laptop: remove useless sony-laptop versioning
Scott K Logan (1):
fujitsu-tablet: add support for Lifebook T901 and T902
On Mon, Apr 07, 2014 at 08:21:00PM -0700, Guenter Roeck wrote:
> On 04/07/2014 07:48 PM, Matthew Garrett wrote:
> >You shouldn't need to install an SCI handler - the way the hardware will
> >generate an SCI is to raise a GPE. If you know which GPE the device
> >ra
e of them may just be used as outputs.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
number
+ 0x10) then you can just call acpi_install_gpe_handler(). The problem
is that the firmware may well already be using some of those GPIOs, and
there's no easy way to tell. Checking the interrupt configuration isn't
sufficient, since some of them may just be used as outputs.
--
Matthew
On Mon, Apr 07, 2014 at 08:21:00PM -0700, Guenter Roeck wrote:
On 04/07/2014 07:48 PM, Matthew Garrett wrote:
You shouldn't need to install an SCI handler - the way the hardware will
generate an SCI is to raise a GPE. If you know which GPE the device
raises (my recollection is that for most
On Fri, Apr 04, 2014 at 07:44:37PM +0200, Ingo Molnar wrote:
>
> Before any other change is done beyond the revert of this latest
> broken commit.
The commit in question was the one that added the misleading text to the
comment. I'm sorry, I should have caught that.
--
Matthew Gar
On Fri, Apr 04, 2014 at 09:09:32AM -0700, Linus Torvalds wrote:
> On Fri, Apr 4, 2014 at 8:45 AM, Matthew Garrett wrote:
> >
> > Which is almost certainly because the other reboot methods are trapping
> > into SMI and hitting some hardware that we've left in a different
On Fri, Apr 04, 2014 at 08:38:42AM -0700, Linus Torvalds wrote:
> On Fri, Apr 4, 2014 at 8:12 AM, Matthew Garrett wrote:
> >
> > Production hardware should never require CF9.
>
> That's total BS.
>
> The fact is, we may be doing something wrong, but ACPI fails on a
y
> all Dell systems. So it isn't really quite that simple...
That's the story of all firmware, ever.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Mor
On Fri, Apr 04, 2014 at 08:13:48AM -0700, H. Peter Anvin wrote:
> On 04/04/2014 08:12 AM, Matthew Garrett wrote:
> > On Fri, Apr 04, 2014 at 09:27:48AM +0800, Li, Aubrey wrote:
> >
> >> The current situation is,
> >> - we have one(do we know more?) preproductio
n't
safe, so we should drop that.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please re
require CF9.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
we should drop that.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
On Fri, Apr 04, 2014 at 08:13:48AM -0700, H. Peter Anvin wrote:
On 04/04/2014 08:12 AM, Matthew Garrett wrote:
On Fri, Apr 04, 2014 at 09:27:48AM +0800, Li, Aubrey wrote:
The current situation is,
- we have one(do we know more?) preproduction machine hangs by CF9.
- We have more than
On Fri, Apr 04, 2014 at 08:38:42AM -0700, Linus Torvalds wrote:
On Fri, Apr 4, 2014 at 8:12 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
Production hardware should never require CF9.
That's total BS.
The fact is, we may be doing something wrong, but ACPI fails on a
*lot* of systems
systems. So it isn't really quite that simple...
That's the story of all firmware, ever.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On Fri, Apr 04, 2014 at 09:09:32AM -0700, Linus Torvalds wrote:
On Fri, Apr 4, 2014 at 8:45 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
Which is almost certainly because the other reboot methods are trapping
into SMI and hitting some hardware that we've left in a different state
On Fri, Apr 04, 2014 at 07:44:37PM +0200, Ingo Molnar wrote:
Before any other change is done beyond the revert of this latest
broken commit.
The commit in question was the one that added the misleading text to the
comment. I'm sorry, I should have caught that.
--
Matthew Garrett | mj
On Thu, Apr 03, 2014 at 10:47:21AM -0400, Steven Rostedt wrote:
> > reboot=a
>
> Passed
Huh. We should be trying the acpi method twice before we try PCI at all,
unless something's gone very wrong.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: s
have patches for me to test. I'll be
> happy to test any patches you have on this box. If you need to know
> anything about this box, let me know and I'll run any command that
> would help you.
I think what this tells us is we should revert the patch and never try
0xcf9 by default.
--
Ma
be
happy to test any patches you have on this box. If you need to know
anything about this box, let me know and I'll run any command that
would help you.
I think what this tells us is we should revert the patch and never try
0xcf9 by default.
--
Matthew Garrett | mj...@srcf.ucam.org
On Thu, Apr 03, 2014 at 10:47:21AM -0400, Steven Rostedt wrote:
reboot=a
Passed
Huh. We should be trying the acpi method twice before we try PCI at all,
unless something's gone very wrong.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe
a couple of unrelated things.
--
Matthew Garrett
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
of unrelated things.
--
Matthew Garrett matthew.garr...@nebula.com
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
e, that's a *good* thing.
Whether Microsoft would actually follow through on blacklisting their
own signatures is obviously an unknown - they've told us they would, but
commercial concerns etc who knows. They *will* blacklist our signatures.
--
Matthew Garrett
would actually follow through on blacklisting their
own signatures is obviously an unknown - they've told us they would, but
commercial concerns etc who knows. They *will* blacklist our signatures.
--
Matthew Garrett matthew.garr...@nebula.com
writing the code, so this is great!
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
this is great!
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Fri, 2014-03-14 at 22:31 +, One Thousand Gnomes wrote:
> On Fri, 14 Mar 2014 22:15:45 +
> Matthew Garrett wrote:
> > The general problem includes having to support this even without an
> > selinux policy.
>
> Yes. No dispute about that. But equally the gener
On Fri, 2014-03-14 at 22:08 +, One Thousand Gnomes wrote:
> On Fri, 14 Mar 2014 21:56:33 +
> Matthew Garrett wrote:
> > Signed userspace is not a requirement, and therefore any solution that
> > relies on a signed initrd is inadequate. There are use cases that
> &
On Fri, 2014-03-14 at 21:58 +, One Thousand Gnomes wrote:
> On Fri, 14 Mar 2014 19:24:55 +
> Matthew Garrett wrote:
> > As an example, imagine a platform with the bootloader and kernel on
> > read-only media. The platform can assert that the kernel is trusted e
that the kernel is trustworthy through some other
mechanism. This genuinely is about trust, not measurement.
--
Matthew Garrett
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
On Fri, 2014-03-14 at 13:37 -0700, David Lang wrote:
> On Fri, 14 Mar 2014, Matthew Garrett wrote:
> > As an example, imagine a platform with the bootloader and kernel on
> > read-only media. The platform can assert that the kernel is trusted even
> > if there's no meas
On Fri, 2014-03-14 at 14:11 -0400, Matthew Garrett wrote:
> The fact that you keep saying measured really does make me suspect that
> you misunderstand the problem. There's no measurement involved, there's
> simply an assertion that the firmware (which you're forced to trust)
> cho
ther one for Chrome, another one for ARM trustzone, another
> one for Intel SGX, and so on.
The fact that you keep saying measured really does make me suspect that
you misunderstand the problem. There's no measurement involved, there's
simply an assertion that the firmware (which you're forced to trust)
chose, via some policy you may be unaware of, to trust the booted
kernel.
--
Matthew Garrett
se. The current patchset
adds a restriction to the acpi_rsdp argument, and I've no objection to
adding one to limit the use of mem=.
--
Matthew Garrett
nd line options that allow a user to elevate themselves
into the kernel at boot time.
--
Matthew Garrett
ral of the cases that you point out could be fixed by
> replacing the CAP_SYS_RAWIO using stuff with a proper interface should
> probably just be *fixed* to provide that.
...thus breaking userspace outside this use case. I mean, sure, I'm
absolutely fine with deleting /dev/mem entirely. I don't see Linus
agreeing.
--
Matthew Garrett
probably just be *fixed* to provide that.
...thus breaking userspace outside this use case. I mean, sure, I'm
absolutely fine with deleting /dev/mem entirely. I don't see Linus
agreeing.
--
Matthew Garrett matthew.garr...@nebula.com
that allow a user to elevate themselves
into the kernel at boot time.
--
Matthew Garrett matthew.garr...@nebula.com
adds a restriction to the acpi_rsdp argument, and I've no objection to
adding one to limit the use of mem=.
--
Matthew Garrett matthew.garr...@nebula.com
no measurement involved, there's
simply an assertion that the firmware (which you're forced to trust)
chose, via some policy you may be unaware of, to trust the booted
kernel.
--
Matthew Garrett matthew.garr...@nebula.com
On Fri, 2014-03-14 at 14:11 -0400, Matthew Garrett wrote:
The fact that you keep saying measured really does make me suspect that
you misunderstand the problem. There's no measurement involved, there's
simply an assertion that the firmware (which you're forced to trust)
chose, via some policy
On Fri, 2014-03-14 at 13:37 -0700, David Lang wrote:
On Fri, 14 Mar 2014, Matthew Garrett wrote:
As an example, imagine a platform with the bootloader and kernel on
read-only media. The platform can assert that the kernel is trusted even
if there's no measurement of the kernel.
Trusted
of
measurement as far as the kernel I load. Without that I can just go into
grub and 0wn you.
In my use case. But not all implementations will be measuring things -
they can assert that the kernel is trustworthy through some other
mechanism. This genuinely is about trust, not measurement.
--
Matthew Garrett
On Fri, 2014-03-14 at 21:58 +, One Thousand Gnomes wrote:
On Fri, 14 Mar 2014 19:24:55 +
Matthew Garrett matthew.garr...@nebula.com wrote:
As an example, imagine a platform with the bootloader and kernel on
read-only media. The platform can assert that the kernel is trusted even
On Fri, 2014-03-14 at 22:08 +, One Thousand Gnomes wrote:
On Fri, 14 Mar 2014 21:56:33 +
Matthew Garrett matthew.garr...@nebula.com wrote:
Signed userspace is not a requirement, and therefore any solution that
relies on a signed initrd is inadequate. There are use cases
On Fri, 2014-03-14 at 22:31 +, One Thousand Gnomes wrote:
On Fri, 14 Mar 2014 22:15:45 +
Matthew Garrett matthew.garr...@nebula.com wrote:
The general problem includes having to support this even without an
selinux policy.
Yes. No dispute about that. But equally the general
On Thu, 2014-03-13 at 23:21 +, One Thousand Gnomes wrote:
> On Thu, 13 Mar 2014 21:30:48 +
> Matthew Garrett wrote:
>
> > On Thu, 2014-03-13 at 21:24 +, One Thousand Gnomes wrote:
> >
> > > If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls f
;
> ... and once we eliminate CAP_SYS_RAWIO a bunch of the patches become
> redundant.
We can only drop CAP_SYS_RAWIO if we change a bunch of the existing
CAP_SYS_RAWIO checks to something else. How do we do that without
breaking existing userspace?
--
Matthew Garrett
N�r��yb�X��ǧv�^�){.n�+�
CAP_SYS_RAWIO_SEC is a 'fails
> secure' case.
We've already been through this. We can't add new capabilities. It
breaks existing userspace.
--
Matthew Garrett
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
e.
/dev/mem access is restricted, so what would this buy you? The potential
to have the kernel hand over a region belonging to hardware in response
to a userspace allocation?
--
Matthew Garrett
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&a
ing CAP_SYS_RAWIO *definitely* breaks expected
functionality - firmware loading and the fibmap ioctl are probably the
most obvious. And changing the use of CAP_SYS_RAWIO potentially breaks
userspace expectations, so we're kind of stuck there.
As for signed firmware, I'm looking forward to Kees' work on that.
--
Matthew Garrett
On Thu, 2014-03-13 at 08:22 +0100, Pavel Machek wrote:
> On Wed 2014-03-12 23:22:49, Matthew Garrett wrote:
> > No. The power meter driver knows nothing about IPMI. It makes no IPMI
> > calls. There's no requirement that a vendor implement it via IPMI.
>
> Yet you clai
901 - 1000 of 3200 matches
Mail list logo
