Re: [PATCH 09/27] hibernate: Disable when the kernel is locked down

On Thu, Mar 7, 2019 at 6:55 AM Alan Cox wrote: > > On Wed, 6 Mar 2019 15:58:55 -0800 > Matthew Garrett wrote: > > > From: Josh Boyer > > > > There is currently no way to verify the resume image when returning > > from hibernate. This might compromise th

Re: [PULL REQUEST] Kernel lockdown patches for 5.2

On Wed, Mar 6, 2019 at 7:56 PM Mimi Zohar wrote: > The kexec and kernel modules patches in this patch set continues to > ignore IMA. This patch set should up front either provide an > alternative solution to coordinate the different signature > verification methods or rely on the architecture

Re: [PATCH 02/27] Add a SysRq option to lift kernel lockdown

On Wed, Mar 6, 2019 at 4:10 PM Randy Dunlap wrote: > > On 3/6/19 3:58 PM, Matthew Garrett wrote: > > From: Kyle McMartin > > > > Make an option to provide a sysrq key that will lift the kernel lockdown, > > thereby allowing the running kernel image to be accessed an

[PATCH 01/27] Add the ability to lock down access to the running kernel image

, fiddling with MSR registers and disallowing hibernation. Signed-off-by: David Howells Acked-by: James Morris Signed-off-by: Matthew Garrett --- include/linux/kernel.h | 17 include/linux/security.h | 9 +- security/Kconfig | 15 ++ security/Makefile

[PATCH 09/27] hibernate: Disable when the kernel is locked down

-by: David Howells Reviewed-by: "Lee, Chun-Yi" cc: linux...@vger.kernel.org Signed-off-by: Matthew Garrett --- kernel/power/hibernate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c index abef759de7c8..802795bec

[PATCH 17/27] acpi: Disable APEI error injection if the kernel is locked down

cc: linux-a...@vger.kernel.org Signed-off-by: Matthew Garrett --- drivers/acpi/apei/einj.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c index fcccbfdbdd1a..9fe6bbab2e7d 100644 --- a/drivers/acpi/apei/einj.c +++ b/drivers/acpi/apei/einj.c @@ -51

[PATCH 12/27] x86: Lock down IO port access when the kernel is locked down

From: 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. This also implicitly locks

[PATCH 27/27] lockdown: Print current->comm in restriction messages

man kernel_lockdown.7 Signed-off-by: David Howells Signed-off-by: Matthew Garrett --- security/lock_down.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/security/lock_down.c b/security/lock_down.c index cfbc2c39712b..5243b55b3c1f 100644 --- a/security/lock_down.c +++ b/secur

[PATCH 19/27] Lock down TIOCSSERIAL

. Reported-by: Greg Kroah-Hartman Signed-off-by: David Howells cc: Jiri Slaby Signed-off-by: Matthew Garrett --- drivers/tty/serial/serial_core.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index d4cca5bdaf1c

[PATCH 15/27] acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

un-Yi" cc: Dave Young cc: linux-a...@vger.kernel.org Signed-off-by: Matthew Garrett --- drivers/acpi/osl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c index f29e427d0d1d..3e44cef7a0cd 100644 --- a/drivers/acpi/osl.c +++ b/drivers/

[PATCH 26/27] debugfs: Restrict debugfs when the kernel is locked down

, as there are 19 creation functions and ~1600 call sites (some of them in loops scanning tables). Signed-off-by: David Howells cc: Andy Shevchenko cc: acpi4asus-u...@lists.sourceforge.net cc: platform-driver-...@vger.kernel.org cc: Matthew Garrett cc: Thomas Gleixner Signed-off-by: Matthew Garrett

[PATCH 25/27] Lock down perf

From: David Howells Disallow the use of certain perf facilities that might allow userspace to access kernel data. Signed-off-by: David Howells Signed-off-by: Matthew Garrett --- kernel/events/core.c | 5 + 1 file changed, 5 insertions(+) diff --git a/kernel/events/core.c b/kernel

[PATCH 23/27] Lock down kprobes

Howells Signed-off-by: Matthew Garrett --- kernel/kprobes.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/kprobes.c b/kernel/kprobes.c index f4ddfdd2d07e..6f66cca8e2c6 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -1552,6 +1552,9 @@ int register_kprobe(struct kprobe *p

[PATCH 18/27] Prohibit PCMCIA CIS storage when the kernel is locked down

From: David Howells Prohibit replacement of the PCMCIA Card Information Structure when the kernel is locked down. Suggested-by: Dominik Brodowski Signed-off-by: David Howells cc: linux-pcm...@lists.infradead.org Signed-off-by: Matthew Garrett --- drivers/pcmcia/cistpl.c | 3 +++ 1 file

[PATCH 24/27] bpf: Restrict kernel image access functions when the kernel is locked down

restriction. Completely prohibit the use of BPF when the kernel is locked down. Suggested-by: Alexei Starovoitov Signed-off-by: David Howells cc: net...@vger.kernel.org cc: Chun-Yi Lee cc: Alexei Starovoitov Signed-off-by: Matthew Garrett --- kernel/bpf/syscall.c | 3 +++ 1 file changed, 3

[PATCH 21/27] x86/mmiotrace: Lock down the testmmiotrace module

ot; cc: x...@kernel.org Signed-off-by: Matthew Garrett --- arch/x86/mm/testmmiotrace.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/mm/testmmiotrace.c b/arch/x86/mm/testmmiotrace.c index f6ae6830b341..bbaad357f5d7 100644 --- a/arch/x86/mm/testmmiotrace.c +++ b/arch/x86/mm/testmmiotrace.c

[PATCH 11/27] PCI: Lock down BAR access when the kernel is locked down

From: Matthew Garrett Any hardware that can potentially generate DMA has to be locked down 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

[PATCH 20/27] Lock down module params that specify hardware parameters (eg. ioport)

From: David Howells Provided an annotation for module parameters that specify hardware parameters (such as io ports, iomem addresses, irqs, dma channels, fixed dma buffers and other types). Suggested-by: Alan Cox Signed-off-by: David Howells Signed-off-by: Matthew Garrett --- kernel

[PATCH 22/27] Lock down /proc/kcore

From: David Howells Disallow access to /proc/kcore when the kernel is locked down to prevent access to cryptographic data. Signed-off-by: David Howells Reviewed-by: James Morris Signed-off-by: Matthew Garrett --- fs/proc/kcore.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/proc

[PATCH 14/27] ACPI: Limit access to custom_method when the kernel is locked down

From: Matthew Garrett custom_method effectively allows arbitrary access to system memory, making it possible for an attacker to circumvent restrictions on module loading. Disable it if the kernel is locked down. Signed-off-by: Matthew Garrett Signed-off-by: David Howells Reviewed-by: &quo

[PATCH 16/27] acpi: Disable ACPI table override if the kernel is locked down

er.kernel.org Signed-off-by: Matthew Garrett --- drivers/acpi/tables.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c index 48eabb6c2d4f..f3b4117cd8f3 100644 --- a/drivers/acpi/tables.c +++ b/drivers/acpi/tables.c @@ -531,6 +531,11 @

[PATCH 10/27] uswsusp: Disable when the kernel is locked down

From: Matthew Garrett uswsusp allows a user process to dump and then restore kernel state, which makes it possible to modify the running kernel. Disable this if the kernel is locked down. Signed-off-by: Matthew Garrett Signed-off-by: David Howells Reviewed-by: "Lee, Chun-Yi"

[PATCH 08/27] kexec_file: Restrict at runtime if the kernel is locked down

lockdowns. Modified by Matthew Garrett to remove the IMA integration, which will be replaced by integrating with the IMA architecture policy patches.] Signed-off-by: Jiri Bohac Signed-off-by: David Howells Reviewed-by: Jiri Bohac Cc: Matthew Garrett cc: Chun-Yi Lee cc: ke...@lists.infradead.org

[PATCH 13/27] x86/msr: Restrict MSR access when the kernel is locked down

From: Matthew Garrett Writing to MSRs should not be allowed if the kernel is locked down, since it could lead to execution of arbitrary code in kernel mode. Based on a patch by Kees Cook. MSR accesses are logged for the purposes of building up a whitelist as per Alan Cox's suggestion. Signed

[PATCH 06/27] Copy secure_boot flag in boot params across kexec reboot

t; cc: ke...@lists.infradead.org Signed-off-by: Matthew Garrett --- arch/x86/kernel/kexec-bzimage64.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c index 278cd07228dd..d49554b948fd 100644 --- a/arch/x86/kernel/kexec-bzimage64.c +++ b/arch/

[PATCH 07/27] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

: Matthew Garrett cc: Chun-Yi Lee cc: ke...@lists.infradead.org Signed-off-by: Matthew Garrett --- arch/x86/Kconfig | 20 --- crypto/asymmetric_keys/verify_pefile.c | 4 ++- include/linux/kexec.h | 4 +-- kernel/kexec_file.c| 48

[PATCH 05/27] kexec_load: Disable at runtime if the kernel is locked down

From: Matthew Garrett The kexec_load() syscall permits the loading and execution of arbitrary code in ring 0, which is something that lock-down is meant to prevent. It makes sense to disable kexec_load() in this situation. This does not affect kexec_file_load() syscall which can check

[PATCH 04/27] Restrict /dev/{mem,kmem,port} when the kernel is locked down

From: Matthew Garrett Allowing users to read and write to core kernel memory makes it possible for the kernel to be subverted, avoiding module loading restrictions, and also to steal cryptographic information. Disallow /dev/mem and /dev/kmem from being opened this when the kernel has been

[PULL REQUEST] Kernel lockdown patches for 5.2

l lockdown Linn Crosetto (2): acpi: Disable ACPI table override if the kernel is locked down acpi: Disable APEI error injection if the kernel is locked down Matthew Garrett (7): Restrict /dev/{mem,kmem,port} when the kernel is locked down kexec_load: Disable at runtime if the

[PATCH 03/27] Enforce module signatures if the kernel is locked down

(EKEYREJECTED) or a system error occurs (eg. ENOMEM), we return the error we got. Note that the X.509 code doesn't check for key expiry as the RTC might not be valid or might not have been transferred to the kernel's clock yet. [Modified by Matthew Garrett to remove the IMA integration

[PATCH 02/27] Add a SysRq option to lift kernel lockdown

in asm/setup.h. Since this macro must be defined in an arch to be able to use this facility for that arch, the Kconfig option is restricted to arches that support it. Signed-off-by: Kyle McMartin Signed-off-by: David Howells cc: x...@kernel.org Signed-off-by: Matthew Garrett --- arch/x86

Re: [PULL REQUEST] Lock down patches

Hi James, Based on feedback, I'm going to make a couple of small changes to this patchset and then resend.

Re: [PULL REQUEST] Lock down patches

On Thu, Feb 28, 2019 at 5:45 PM Mimi Zohar wrote: > > On Thu, 2019-02-28 at 17:01 -0800, Matthew Garrett wrote: > > > > That's not a valid reason for preventing systems that do use IMA for > > > verifying the kexec kernel image signature or kernel module signatures >

Re: [PULL REQUEST] Lock down patches

On Thu, Feb 28, 2019 at 4:05 PM Mimi Zohar wrote: > > On Thu, 2019-02-28 at 15:13 -0800, Matthew Garrett wrote: > > On Thu, Feb 28, 2019 at 2:20 PM Mimi Zohar wrote: > > > Where/when was this latest version of the patches posted? > > > > They should have followe

[PATCH 06/27] Copy secure_boot flag in boot params across kexec reboot

From: Dave Young Kexec reboot in case secure boot being enabled does not keep the secure boot mode in new kernel, so later one can load unsigned kernel via legacy kexec_load. In this state, the system is missing the protections provided by secure boot. Adding a patch to fix this by retain the

[PATCH 08/27] kexec_file: Restrict at runtime if the kernel is locked down

is locked down for consistency with other lockdowns] Signed-off-by: Jiri Bohac Signed-off-by: David Howells Reviewed-by: Jiri Bohac Cc: Matthew Garrett cc: Chun-Yi Lee cc: ke...@lists.infradead.org --- include/linux/ima.h | 6 ++ kernel/kexec_file.c | 8 2 files changed, 14

[PATCH 12/27] x86: Lock down IO port access when the kernel is locked down

From: 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. This also implicitly locks

[PATCH 11/27] PCI: Lock down BAR access when the kernel is locked down

From: Matthew Garrett Any hardware that can potentially generate DMA has to be locked down 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

[PATCH 10/27] uswsusp: Disable when the kernel is locked down

From: Matthew Garrett uswsusp allows a user process to dump and then restore kernel state, which makes it possible to modify the running kernel. Disable this if the kernel is locked down. Signed-off-by: Matthew Garrett Signed-off-by: David Howells Reviewed-by: "Lee, Chun-Yi"

[PATCH 16/27] acpi: Disable ACPI table override if the kernel is locked down

From: Linn Crosetto >From the kernel documentation (initrd_table_override.txt): If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible to override nearly any ACPI table provided by the BIOS with an instrumented, modified one. When securelevel is set, the kernel should

[PATCH 14/27] ACPI: Limit access to custom_method when the kernel is locked down

From: Matthew Garrett custom_method effectively allows arbitrary access to system memory, making it possible for an attacker to circumvent restrictions on module loading. Disable it if the kernel is locked down. Signed-off-by: Matthew Garrett Signed-off-by: David Howells Reviewed-by: &quo

[PATCH 24/27] bpf: Restrict kernel image access functions when the kernel is locked down

From: David Howells There are some bpf functions can be used to read kernel memory: bpf_probe_read, bpf_probe_write_user and bpf_trace_printk. These allow private keys in kernel memory (e.g. the hibernation image signing key) to be read by an eBPF program and kernel memory to be altered without

[PATCH 13/27] x86/msr: Restrict MSR access when the kernel is locked down

From: Matthew Garrett Writing to MSRs should not be allowed if the kernel is locked down, since it could lead to execution of arbitrary code in kernel mode. Based on a patch by Kees Cook. MSR accesses are logged for the purposes of building up a whitelist as per Alan Cox's suggestion. Signed

[PATCH 21/27] x86/mmiotrace: Lock down the testmmiotrace module

From: David Howells The testmmiotrace module shouldn't be permitted when the kernel is locked down as it can be used to arbitrarily read and write MMIO space. Suggested-by: Thomas Gleixner Signed-off-by: David Howells cc: Steven Rostedt cc: Ingo Molnar cc: "H. Peter Anvin" cc:

[PATCH 19/27] Lock down TIOCSSERIAL

From: David Howells Lock down TIOCSSERIAL as that can be used to change the ioport and irq settings on a serial port. This only appears to be an issue for the serial drivers that use the core serial code. All other drivers seem to either ignore attempts to change port/irq or give an error.

[PATCH 26/27] debugfs: Restrict debugfs when the kernel is locked down

, as there are 19 creation functions and ~1600 call sites (some of them in loops scanning tables). Signed-off-by: David Howells cc: Andy Shevchenko cc: acpi4asus-u...@lists.sourceforge.net cc: platform-driver-...@vger.kernel.org cc: Matthew Garrett cc: Thomas Gleixner --- fs/debugfs/file.c | 28

Re: [PULL REQUEST] Lock down patches

On Thu, Feb 28, 2019 at 2:20 PM Mimi Zohar wrote: > On Thu, 2019-02-28 at 13:28 -0800, Matthew Garrett wrote: > > This PR is mostly the same as the previous attempt, but with the > > following changes: > > Where/when was this latest version of the patches posted? They

[PATCH 23/27] Lock down kprobes

From: David Howells Disallow the creation of kprobes when the kernel is locked down by preventing their registration. This prevents kprobes from being used to access kernel memory, either to make modifications or to steal crypto data. Reported-by: Alexei Starovoitov Signed-off-by: David

[PATCH 27/27] lockdown: Print current->comm in restriction messages

From: David Howells Print the content of current->comm in messages generated by lockdown to indicate a restriction that was hit. This makes it a bit easier to find out what caused the message. The message now patterned something like: Lockdown: : is restricted; see man

[PATCH 18/27] Prohibit PCMCIA CIS storage when the kernel is locked down

From: David Howells Prohibit replacement of the PCMCIA Card Information Structure when the kernel is locked down. Suggested-by: Dominik Brodowski Signed-off-by: David Howells cc: linux-pcm...@lists.infradead.org --- drivers/pcmcia/cistpl.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH 25/27] Lock down perf

From: David Howells Disallow the use of certain perf facilities that might allow userspace to access kernel data. Signed-off-by: David Howells --- kernel/events/core.c | 5 + 1 file changed, 5 insertions(+) diff --git a/kernel/events/core.c b/kernel/events/core.c index

[PATCH 22/27] Lock down /proc/kcore

From: David Howells Disallow access to /proc/kcore when the kernel is locked down to prevent access to cryptographic data. Signed-off-by: David Howells Reviewed-by: James Morris --- fs/proc/kcore.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c index

[PATCH 15/27] acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

From: Josh Boyer This option allows userspace to pass the RSDP address to the kernel, which makes it possible for a user to modify the workings of hardware . Reject the option when the kernel is locked down. Signed-off-by: Josh Boyer Signed-off-by: David Howells Reviewed-by: "Lee, Chun-Yi"

[PATCH 03/27] Enforce module signatures if the kernel is locked down

From: David Howells If the kernel is locked down, require that all modules have valid signatures that we can verify or that IMA can validate the file. I have adjusted the errors generated: (1) If there's no signature (ENODATA) or we can't check it (ENOPKG, ENOKEY), then: (a) If

[PATCH 02/27] Add a SysRq option to lift kernel lockdown

From: Kyle McMartin Make an option to provide a sysrq key that will lift the kernel lockdown, thereby allowing the running kernel image to be accessed and modified. On x86 this is triggered with SysRq+x, but this key may not be available on all arches, so it is set by setting LOCKDOWN_LIFT_KEY

[PATCH 17/27] acpi: Disable APEI error injection if the kernel is locked down

From: Linn Crosetto ACPI provides an error injection mechanism, EINJ, for debugging and testing the ACPI Platform Error Interface (APEI) and other RAS features. If supported by the firmware, ACPI specification 5.0 and later provide for a way to specify a physical memory address to which to

[PATCH 04/27] Restrict /dev/{mem,kmem,port} when the kernel is locked down

From: Matthew Garrett Allowing users to read and write to core kernel memory makes it possible for the kernel to be subverted, avoiding module loading restrictions, and also to steal cryptographic information. Disallow /dev/mem and /dev/kmem from being opened this when the kernel has been

[PATCH 20/27] Lock down module params that specify hardware parameters (eg. ioport)

From: David Howells Provided an annotation for module parameters that specify hardware parameters (such as io ports, iomem addresses, irqs, dma channels, fixed dma buffers and other types). Suggested-by: Alan Cox Signed-off-by: David Howells --- kernel/params.c | 26

[PATCH 01/27] Add the ability to lock down access to the running kernel image

From: David Howells Provide a single call to allow kernel code to determine whether the system should be locked down, thereby disallowing various accesses that might allow the running kernel image to be changed including the loading of modules that aren't validly signed with a key we recognise,

[PATCH 05/27] kexec_load: Disable at runtime if the kernel is locked down

From: Matthew Garrett The kexec_load() syscall permits the loading and execution of arbitrary code in ring 0, which is something that lock-down is meant to prevent. It makes sense to disable kexec_load() in this situation. This does not affect kexec_file_load() syscall which can check

[PATCH 09/27] hibernate: Disable when the kernel is locked down

From: Josh Boyer There is currently no way to verify the resume image when returning from hibernate. This might compromise the signed modules trust model, so until we can work with signed hibernate images we disable it when the kernel is locked down. Signed-off-by: Josh Boyer Signed-off-by:

[PATCH 07/27] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

: Matthew Garrett cc: Chun-Yi Lee cc: ke...@lists.infradead.org --- arch/x86/Kconfig | 20 --- crypto/asymmetric_keys/verify_pefile.c | 4 ++- include/linux/kexec.h | 4 +-- kernel/kexec_file.c| 48 ++ 4

[PATCH 02/27] Add a SysRq option to lift kernel lockdown

From: Kyle McMartin Make an option to provide a sysrq key that will lift the kernel lockdown, thereby allowing the running kernel image to be accessed and modified. On x86 this is triggered with SysRq+x, but this key may not be available on all arches, so it is set by setting LOCKDOWN_LIFT_KEY

[PATCH 01/27] Add the ability to lock down access to the running kernel image

From: David Howells Provide a single call to allow kernel code to determine whether the system should be locked down, thereby disallowing various accesses that might allow the running kernel image to be changed including the loading of modules that aren't validly signed with a key we recognise,

[PATCH 01/27] Add the ability to lock down access to the running kernel image

From: David Howells Provide a single call to allow kernel code to determine whether the system should be locked down, thereby disallowing various accesses that might allow the running kernel image to be changed including the loading of modules that aren't validly signed with a key we recognise,

[PATCH 02/27] Add a SysRq option to lift kernel lockdown

From: Kyle McMartin Make an option to provide a sysrq key that will lift the kernel lockdown, thereby allowing the running kernel image to be accessed and modified. On x86 this is triggered with SysRq+x, but this key may not be available on all arches, so it is set by setting LOCKDOWN_LIFT_KEY

[PATCH 02/27] Add a SysRq option to lift kernel lockdown

From: Kyle McMartin Make an option to provide a sysrq key that will lift the kernel lockdown, thereby allowing the running kernel image to be accessed and modified. On x86 this is triggered with SysRq+x, but this key may not be available on all arches, so it is set by setting LOCKDOWN_LIFT_KEY

[PATCH 01/27] Add the ability to lock down access to the running kernel image

From: David Howells Provide a single call to allow kernel code to determine whether the system should be locked down, thereby disallowing various accesses that might allow the running kernel image to be changed including the loading of modules that aren't validly signed with a key we recognise,

[PULL REQUEST] Lock down patches

acpi_rsdp kernel param when the kernel has been locked down Kyle McMartin (1): Add a SysRq option to lift kernel lockdown Linn Crosetto (2): acpi: Disable ACPI table override if the kernel is locked down acpi: Disable APEI error injection if the kernel is locked down Ma

[PATCH V5 2/4] tpm: Reserve the TPM final events table

From: Matthew Garrett UEFI systems provide a boot services protocol for obtaining the TPM event log, but this is unusable after ExitBootServices() is called. Unfortunately ExitBootServices() itself triggers additional TPM events that then can't be obtained using this protocol. The platform

[PATCH V5 3/4] tpm: Append the final event log to the TPM event log

From: Matthew Garrett Any events that are logged after GetEventsLog() is called are logged to the EFI Final Events table. These events are defined as being in the crypto agile log format, so we can just append them directly to the existing log if it's in the same format. In theory we can also

[PATCH V5 4/4] efi: Attempt to get the TCG2 event log in the boot stub

From: Matthew Garrett Right now we only attempt to obtain the SHA1-only event log. The protocol also supports a crypto agile log format, which contains digests for all algorithms in use. Attempt to obtain this first, and fall back to obtaining the older format if the system doesn't support

[PATCH V5 1/4] tpm: Abstract crypto agile event size calculations

From: Matthew Garrett We need to calculate the size of crypto agile events in multiple locations, including in the EFI boot stub. The easiest way to do this is to put it in a header file as an inline and leave a wrapper to ensure we don't end up with multiple copies of it embedded

Add support for TCG2 log format on UEFI systems

Identical to V4, but based on tpmdd-next

Re: [PATCH V4 2/4] tpm: Reserve the TPM final events table

On Wed, Feb 27, 2019 at 6:03 AM Jarkko Sakkinen wrote: > My guess is that your patches are based a later 5.0-rcX. Unfortunately I > cannot update my master at this point because my 5.1 PR was taken to > security tree and rebasing would change the commit IDs of 5.1 content > because

[PATCH V4 3/4] tpm: Append the final event log to the TPM event log

From: Matthew Garrett Any events that are logged after GetEventsLog() is called are logged to the EFI Final Events table. These events are defined as being in the crypto agile log format, so we can just append them directly to the existing log if it's in the same format. In theory we can also

[PATCH V4 4/4] efi: Attempt to get the TCG2 event log in the boot stub

From: Matthew Garrett Right now we only attempt to obtain the SHA1-only event log. The protocol also supports a crypto agile log format, which contains digests for all algorithms in use. Attempt to obtain this first, and fall back to obtaining the older format if the system doesn't support

[PATCH V4 1/4] tpm: Abstract crypto agile event size calculations

From: Matthew Garrett We need to calculate the size of crypto agile events in multiple locations, including in the EFI boot stub. The easiest way to do this is to put it in a header file as an inline and leave a wrapper to ensure we don't end up with multiple copies of it embedded

[PATCH V4 0/4] Add support for TCG2 event logs on EFI systems

This patchset adds support for obtaining the TCG2 format event log on EFI systems, along with support for copying up the final event log to capture events that occur after the primary log is obtained. V4 is identical to previous versions, except for tpm_read_log_efi() in patch 3 being reworked to

[PATCH V4 2/4] tpm: Reserve the TPM final events table

From: Matthew Garrett UEFI systems provide a boot services protocol for obtaining the TPM event log, but this is unusable after ExitBootServices() is called. Unfortunately ExitBootServices() itself triggers additional TPM events that then can't be obtained using this protocol. The platform

[PATCH 2/2] thermal/int340x_thermal: fix mode setting

int3400 only pushes the UUID into the firmware when the mode is flipped to "enable". The current code only exposes the mode flag if the firmware supports the PASSIVE_1 UUID, which not all machines do. Remove the restriction. Signed-off-by: Matthew Garrett Cc: Zhang Rui --- drive

Expose all known Intel DPTF policies

Intel's Dynamic Platform and Thermal Framework is a combination firmware/OS framework for allowing userland to implement more complex thermal policies in conjunction with the platform firmware. The rough gist is that the firmware exposes a set of information describing the relationships between

[PATCH 2/2] thermal/int340x_thermal: fix mode setting

int3400 only pushes the UUID into the firmware when the mode is flipped to "enable". The current code only exposes the mode flag if the firmware supports the PASSIVE_1 UUID, which not all machines do. Remove the restriction. Signed-off-by: Matthew Garrett Cc: Zhang Rui --- drive

Expose all known Intel DPTF policies

Intel's Dynamic Platform and Thermal Framework is a combination firmware/OS framework for allowing userland to implement more complex thermal policies in conjunction with the platform firmware. The rough gist is that the firmware exposes a set of information describing the relationships between

[PATCH 1/2] thermal/int340x_thermal: Add additional UUIDs

Platforms support more DPTF policies than the driver currently exposes. Add them. This effectively reverts 31908f45a583e8f21db37f402b6e8d5739945afd which removed several UUIDs without explaining why. Signed-off-by: Matthew Garrett Cc: Zhang Rui Cc: Nisha Aram --- drivers/thermal

[PATCH 1/2] thermal/int340x_thermal: Add additional UUIDs

Platforms support more DPTF policies than the driver currently exposes. Add them. This effectively reverts 31908f45a583e8f21db37f402b6e8d5739945afd which removed several UUIDs without explaining why. Signed-off-by: Matthew Garrett Cc: Zhang Rui Cc: Nisha Aram --- drivers/thermal

Re: Bugs involving maliciously crafted file system

On Wed, May 30, 2018 at 1:42 PM Dave Chinner wrote: > We've learnt this lesson the hard way over and over again: don't > parse untrusted input in privileged contexts. How many times do we > have to make the same mistakes before people start to learn from > them? You're not wrong, but we haven't

Re: Bugs involving maliciously crafted file system

On Wed, May 30, 2018 at 1:42 PM Dave Chinner wrote: > We've learnt this lesson the hard way over and over again: don't > parse untrusted input in privileged contexts. How many times do we > have to make the same mistakes before people start to learn from > them? You're not wrong, but we haven't

Re: [PATCH 0/3] kexec: limit kexec_load syscall

On Thu, May 3, 2018 at 2:59 PM Eric W. Biederman <ebied...@xmission.com> wrote: > Matthew Garrett <mj...@google.com> writes: > > kexec_load gives root arbitrary power to modify the running kernel image, > > including the ability to disable enforcement of module

Re: [PATCH 0/3] kexec: limit kexec_load syscall

On Thu, May 3, 2018 at 2:59 PM Eric W. Biederman wrote: > Matthew Garrett writes: > > kexec_load gives root arbitrary power to modify the running kernel image, > > including the ability to disable enforcement of module signatures. > No. It does absolutely nothing to the ru

Re: [PATCH 0/3] kexec: limit kexec_load syscall

On Thu, May 3, 2018 at 1:13 PM Eric W. Biederman wrote: > Mimi Zohar writes: > > In environments that require the kexec kernel image to be signed, prevent > > using the kexec_load syscall. In order for LSMs and IMA to differentiate > > between

Re: [PATCH 0/3] kexec: limit kexec_load syscall

On Thu, May 3, 2018 at 1:13 PM Eric W. Biederman wrote: > Mimi Zohar writes: > > In environments that require the kexec kernel image to be signed, prevent > > using the kexec_load syscall. In order for LSMs and IMA to differentiate > > between kexec_load and kexec_file_load syscalls, this

Re: [GIT PULL] Kernel lockdown for secure boot

On Thu, Apr 5, 2018 at 10:59 AM Alan Cox wrote: > VT-D Once Intel provide that on all hardware and actually make it work reliably with their graphics chipsets it's certainly a solution for the PCI DMA problem, but right now it's still effectively undeployable for a

Re: [GIT PULL] Kernel lockdown for secure boot

On Thu, Apr 5, 2018 at 10:59 AM Alan Cox wrote: > VT-D Once Intel provide that on all hardware and actually make it work reliably with their graphics chipsets it's certainly a solution for the PCI DMA problem, but right now it's still effectively undeployable for a lot of real world cases.

Re: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot)

On Wed, Apr 4, 2018 at 4:25 PM James Morris wrote: > It's surely reasonable to allow an already secure-booted system to be > debugged without needing to be rebooted. alt-sysrq-x from a physical console will do that.

Re: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot)

On Wed, Apr 4, 2018 at 4:25 PM James Morris wrote: > It's surely reasonable to allow an already secure-booted system to be > debugged without needing to be rebooted. alt-sysrq-x from a physical console will do that.

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 5:05 PM Peter Dolding wrote: > > If you don't have secure boot then an attacker with root can modify your > > bootloader or kernel, and on next boot lockdown can be silently disabled. > Stop being narrow minded you don't need secure boot to protect >

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 5:05 PM Peter Dolding wrote: > > If you don't have secure boot then an attacker with root can modify your > > bootloader or kernel, and on next boot lockdown can be silently disabled. > Stop being narrow minded you don't need secure boot to protect > bootloader or kernel

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 1:01 PM Thomas Gleixner wrote: > Now where the disagreement lies is the way how the uid/ring0 aspect is tied > to secure boot, which makes it impossible to be useful independent of > Secure Boot. It doesn't - you can pass a command line parameter that

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 1:01 PM Thomas Gleixner wrote: > Now where the disagreement lies is the way how the uid/ring0 aspect is tied > to secure boot, which makes it impossible to be useful independent of > Secure Boot. It doesn't - you can pass a command line parameter that enables it, or your

<    1   2   3   4   5   6   7   8   9   10   >