On Fri, 2013-08-16 at 11:20 -0400, John W. Linville wrote:
All,
The Linux Foundation and The UEFI Forum are hosting a UEFI Plugfest
event in New Orleans on September 19-20, 2013. This event will run
concurrent with Linux Plumbers Conference, just after LinuxCon at the
Hyatt Regency New
On Mon, Aug 19, 2013 at 09:25:35AM +0100, David Woodhouse wrote:
Every deviation from the spec (or common sense), however minor, should
show up as a clear failure. Even the ones we *have* been able to work
around, because we still want them *fixed*.
Why? It's not like we can ever stop
On Mon, Aug 19, 2013 at 09:25:35AM +0100, David Woodhouse wrote:
Hm. It would be really useful to have a kernel build option which
*disables* all the workarounds we've ever put in for broken firmware.
Yeah, cool!
I wonder if we could reach a high double-digit percentage of machines
not
On Mon, 2013-08-19 at 13:55 +0100, Matthew Garrett wrote:
On Mon, Aug 19, 2013 at 09:25:35AM +0100, David Woodhouse wrote:
Every deviation from the spec (or common sense), however minor, should
show up as a clear failure. Even the ones we *have* been able to work
around, because we still
On Mon, Aug 19, 2013 at 08:22:45AM -0700, James Bottomley wrote:
On Mon, 2013-08-19 at 13:55 +0100, Matthew Garrett wrote:
On Mon, Aug 19, 2013 at 09:25:35AM +0100, David Woodhouse wrote:
Every deviation from the spec (or common sense), however minor, should
show up as a clear failure.
UEFI Secure Boot provides a mechanism for ensuring that the firmware will
only load signed bootloaders and kernels. Certain use cases may also
require that all kernel modules also be signed. Add a configuration option
that enforces this automatically when enabled.
Signed-off-by: Matthew Garrett
IO port access would permit users to gain access to PCI configuration
registers, which in turn (on a lot of hardware) give access to MMIO register
space. This would potentially permit root to trigger arbitrary DMA, so lock
it down by default.
Signed-off-by: Matthew Garrett
kexec permits the loading and execution of arbitrary code in ring 0, which
is something that module signing enforcement is meant to prevent. It makes
sense to disable kexec in this situation.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
kernel/kexec.c | 4
1 file changed, 4
From: Josh Boyer jwbo...@redhat.com
This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to circumvent any restrictions imposed on
loading modules. Disable it in that case.
Signed-off-by: Josh Boyer jwbo...@redhat.com
---
drivers/acpi/osl.c | 3
Provide a single call to allow kernel code to determine whether the system
has been configured to either disable module loading entirely or to load
only modules signed with a trusted key.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
include/linux/module.h | 7 +++
Allowing users to write to address space makes it possible for the kernel
to be subverted, avoiding module loading restrictions. Prevent this when
any restrictions have been imposed on loading modules.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
drivers/char/mem.c | 6 ++
1
We have no way of validating what all of the Asus WMI methods do on a
given machine, and there's a risk that some will allow hardware state to
be manipulated in such a way that arbitrary code can be executed in the
kernel, circumventing module loading restrictions. Prevent that if any of
these
Any hardware that can potentially generate DMA has to be locked down from
userspace in order to avoid it being possible for an attacker to modify
kernel code, allowing them to circumvent disabled module loading or module
signing. Default to paranoid - in future we can potentially relax this for
custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to circumvent restrictions on module loading.
Disable it if any such restrictions have been enabled.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
drivers/acpi/custom_method.c |
On Mon, Aug 19, 2013 at 9:10 AM, Matthew Garrett
matthew.garr...@nebula.com wrote:
We have no way of validating what all of the Asus WMI methods do on a
given machine, and there's a risk that some will allow hardware state to
be manipulated in such a way that arbitrary code can be executed in
On Mon, 2013-08-19 at 17:00 +0100, Matthew Garrett wrote:
On Mon, Aug 19, 2013 at 08:22:45AM -0700, James Bottomley wrote:
On Mon, 2013-08-19 at 13:55 +0100, Matthew Garrett wrote:
On Mon, Aug 19, 2013 at 09:25:35AM +0100, David Woodhouse wrote:
Every deviation from the spec (or
On Mon, 2013-08-19 at 09:20 -0700, Kees Cook wrote:
Looks like this and the next chunk weren't changed to the
secure_modules() API...
Bother. Yeah, looks like my test config had this left out.
--
Matthew Garrett matthew.garr...@nebula.com
On Mon, Aug 19, 2013 at 10:02:55AM -0700, James Bottomley wrote:
The object of having a test suite conform to the spec is not to
perpetuate the cockups that occurred in round one of the implementation
and to force everyone to pay closer attention to what the spec says.
Otherwise the amount of
We have two in-kernel mechanisms for restricting module loading - disabling
it entirely, or limiting it to the loading of modules signed with a trusted
key. These can both be configured in such a way that even root is unable to
relax the restrictions.
However, right now, there's several other
On Mon, Aug 19, 2013 at 10:26 AM, Matthew Garrett
matthew.garr...@nebula.com wrote:
We have two in-kernel mechanisms for restricting module loading - disabling
it entirely, or limiting it to the loading of modules signed with a trusted
key. These can both be configured in such a way that even
Any hardware that can potentially generate DMA has to be locked down from
userspace in order to avoid it being possible for an attacker to modify
kernel code, allowing them to circumvent disabled module loading or module
signing. Default to paranoid - in future we can potentially relax this for
kexec permits the loading and execution of arbitrary code in ring 0, which
is something that module signing enforcement is meant to prevent. It makes
sense to disable kexec in this situation.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
kernel/kexec.c | 4
1 file changed, 4
From: Josh Boyer jwbo...@redhat.com
This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to circumvent any restrictions imposed on
loading modules. Disable it in that case.
Signed-off-by: Josh Boyer jwbo...@redhat.com
---
drivers/acpi/osl.c | 3
Allowing users to write to address space makes it possible for the kernel
to be subverted, avoiding module loading restrictions. Prevent this when
any restrictions have been imposed on loading modules.
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
drivers/char/mem.c | 6 ++
1
Writing to MSRs should not be allowed if module loading is restricted,
since it could lead to execution of arbitrary code in kernel mode. Based
on a patch by Kees Cook.
Cc: Kees Cook keesc...@chromium.org
Signed-off-by: Matthew Garrett matthew.garr...@nebula.com
---
arch/x86/kernel/msr.c | 7
On Mon, 2013-08-19 at 18:21 +0100, Matthew Garrett wrote:
On Mon, Aug 19, 2013 at 10:02:55AM -0700, James Bottomley wrote:
The object of having a test suite conform to the spec is not to
perpetuate the cockups that occurred in round one of the implementation
and to force everyone to pay
IO port access would permit users to gain access to PCI configuration
registers, which in turn (on a lot of hardware) give access to MMIO register
space. This would potentially permit root to trigger arbitrary DMA, so lock
it down by default.
Signed-off-by: Matthew Garrett
On Mon, Aug 19, 2013 at 10:38:46AM -0700, James Bottomley wrote:
It's not about us removing the code, it's about us having an accurate
compliance test. There are two reasons for having a fully correct
compliance test
1. Our work arounds have unintended consequences which have knock
UEFI Secure Boot provides a mechanism for ensuring that the firmware will
only load signed bootloaders and kernels. Certain use cases may also
require that all kernel modules also be signed. Add a configuration option
that enforces this automatically when enabled.
Signed-off-by: Matthew Garrett
This patch adds support for EFI memory maps larger than 128 entries when
booted using the EFI boot stub.
The e820 map in struct boot_params can only hold 128 entries, but the
memory map provided by EFI may be larger. If the map contained more than
128 entries, exit_boot() would write beyond the
On Mon, 2013-08-19 at 10:38 -0700, James Bottomley wrote:
It's not about us removing the code, it's about us having an accurate
compliance test. There are two reasons for having a fully correct
compliance test
1. Our work arounds have unintended consequences which have knock
On Mon, Aug 19, 2013 at 09:09:54PM +0100, David Woodhouse wrote:
Do we really want to declare that we can only use 50% of the available
NV storage space for *ever* more, just because some muppet thought they
could squeeze some non-upstream value add into their implementation of
the flash
On Mon, Aug 19, 2013 at 09:21:11PM +0100, David Woodhouse wrote:
On Mon, 2013-08-19 at 21:19 +0100, Matthew Garrett wrote:
We have no way to guarantee that. Most board vendors don't turn up to
the plugfests and aren't going to run anything we ship.
Oh well, let's just wring our hands
On Mon, Aug 19, 2013 at 1:06 PM, H. Peter Anvin h...@zytor.com wrote:
I would strongly disagree that option 2 is the cleaner solution.
Agreed.
Linn Crosetto l...@hp.com wrote:
I realize the EFI stub for ARM patches are in flight,
https://lkml.org/lkml/2013/8/9/554
and overlap with some of
On Mon, 2013-08-19 at 21:39 +0100, Matthew Garrett wrote:
The plugfests have, from our perspective, always been useful in
identifying new implementation interpretations before hardware ships.
But even then, it's usually too late to modify the firmware. Vendors who
care about Linux
On Mon, Aug 19, 2013 at 01:47:41PM -0700, Yinghai Lu wrote:
On Mon, Aug 19, 2013 at 1:06 PM, H. Peter Anvin h...@zytor.com wrote:
I would strongly disagree that option 2 is the cleaner solution.
Agreed.
Linn Crosetto l...@hp.com wrote:
I realize the EFI stub for ARM patches are in
On Mon, Aug 19, 2013 at 10:06:51PM +0100, David Woodhouse wrote:
You effectively seem to be suggesting that nothing will ever get better
on the UEFI side, and the only benefit of the plugfest is that we get to
see the latest brokenness and try to come up with a workaround for it
before the
37 matches
Mail list logo
