Re: [PATCH v6 04/14] x86: Secure Launch Resource Table header file

On Fri, Jun 16, 2023 at 04:01:09PM -0400, Daniel P. Smith wrote: > On 5/15/23 21:43, Matthew Garrett wrote: > > On Mon, May 15, 2023 at 08:41:00PM -0400, Daniel P. Smith wrote: > > > On 5/15/23 17:22, Matthew Garrett wrote: > > > > What if I don't use grub,

Re: [PATCH v6 02/14] Documentation/x86: Secure Launch kernel documentation

On Fri, Jun 16, 2023 at 12:44:27PM -0400, Daniel P. Smith wrote: > > On 5/12/23 06:47, Matthew Garrett wrote: > > On Thu, May 04, 2023 at 02:50:11PM +, Ross Philipson wrote: > > > +Secure Launch does not interoperate with KASLR. If possible, the MLE > > > sho

Re: [PATCH v6 04/14] x86: Secure Launch Resource Table header file

On Mon, May 15, 2023 at 08:41:00PM -0400, Daniel P. Smith wrote: > On 5/15/23 17:22, Matthew Garrett wrote: > > What if I don't use grub, but use something that behaves equivalently? > > Which value should be used here? > > Generally we would request that the bootlo

Re: [PATCH v6 07/14] x86: Secure Launch kernel early boot stub

On Mon, May 15, 2023 at 09:11:15PM -0400, Daniel P. Smith wrote: > On 5/12/23 12:17, Ross Philipson wrote: > > This is a good point. At this point it is really something we > > overlooked. We will have to revisit this and figure out the best way to > > find the final event log depending on how

Re: [PATCH v6 04/14] x86: Secure Launch Resource Table header file

On Mon, May 15, 2023 at 05:15:15PM -0400, Daniel P. Smith wrote: > On 5/12/23 06:55, Matthew Garrett wrote: > > On Thu, May 04, 2023 at 02:50:13PM +, Ross Philipson wrote: > > > > > +#define SLR_TABLE_MAGIC 0x4452544d > > > > From convent

Re: [PATCH v6 06/14] x86: Add early SHA support for Secure Launch early measurements

On Sun, May 14, 2023 at 11:18:17AM -0700, Eric Biggers wrote: > On Fri, May 12, 2023 at 01:24:22PM +0100, Andrew Cooper wrote: > > You're suggesting that because Linux has been slow to take D-RTM over > > the past decade, you're going to intentionally break people with older > > hardware just

Re: [PATCH v6 06/14] x86: Add early SHA support for Secure Launch early measurements

On Fri, May 12, 2023 at 08:17:21PM +0200, Thomas Gleixner wrote: > On Fri, May 12 2023 at 17:13, Matthew Garrett wrote: > > On Fri, May 12, 2023 at 03:24:04PM +0200, Thomas Gleixner wrote: > >> On Fri, May 12 2023 at 12:28, Matthew Garrett wrote: > >> > Unle

Re: [PATCH v6 07/14] x86: Secure Launch kernel early boot stub

On Fri, May 12, 2023 at 12:17:50PM -0400, Ross Philipson wrote: > I am not 100% sure what you are asking but we also measure the EFI memory > map. This comment is just to note that if the e820 exceeded the space in the > fixed map in boot parameters, we would pick up any extra entries when >

Re: [PATCH v6 06/14] x86: Add early SHA support for Secure Launch early measurements

On Fri, May 12, 2023 at 03:24:04PM +0200, Thomas Gleixner wrote: > On Fri, May 12 2023 at 12:28, Matthew Garrett wrote: > > Unless we assert that SHA-1 events are unsupported, it seems a bit odd > > to force a policy on people who have both banks enabled. People with &

Re: [PATCH v6 13/14] tpm: Allow locality 2 to be set when initializing the TPM for Secure Launch

On Thu, May 04, 2023 at 02:50:22PM +, Ross Philipson wrote: > The Secure Launch MLE environment uses PCRs that are only accessible from > the DRTM locality 2. By default the TPM drivers always initialize the > locality to 0. When a Secure Launch is in progress, initialize the > locality to 2.

Re: [PATCH v6 11/14] reboot: Secure Launch SEXIT support on reboot paths

On Thu, May 04, 2023 at 02:50:20PM +, Ross Philipson wrote: > If the MLE kernel is being powered off, rebooted or halted, > then SEXIT must be called. Note that the SEXIT GETSEC leaf > can only be called after a machine_shutdown() has been done on > these paths. The machine_shutdown() is not

Re: [PATCH v6 06/14] x86: Add early SHA support for Secure Launch early measurements

On Fri, May 12, 2023 at 01:18:45PM +0200, Ard Biesheuvel wrote: > On Fri, 12 May 2023 at 13:04, Matthew Garrett wrote: > > > > On Tue, May 09, 2023 at 06:21:44PM -0700, Eric Biggers wrote: > > > > > SHA-1 is insecure. Why are you still using SHA-1? Don't TPMs

Re: [PATCH v6 07/14] x86: Secure Launch kernel early boot stub

On Thu, May 04, 2023 at 02:50:16PM +, Ross Philipson wrote: > +static void sl_find_event_log(struct slr_table *slrt) If this is called after the EFI stub then we're presumably post-ExitBootServices and we're copied the TPM event log into a configuration table so it's available to the

Re: [PATCH v6 06/14] x86: Add early SHA support for Secure Launch early measurements

On Tue, May 09, 2023 at 06:21:44PM -0700, Eric Biggers wrote: > SHA-1 is insecure. Why are you still using SHA-1? Don't TPMs support SHA-2 > now? TXT is supported on some TPM 1.2 systems as well. TPM 2 systems are also at the whim of the firmware in terms of whether the SHA-2 banks are

Re: [PATCH v6 05/14] x86: Secure Launch main header file

On Thu, May 04, 2023 at 02:50:14PM +, Ross Philipson wrote: > +static inline int tpm12_log_event(void *evtlog_base, u32 evtlog_size, > + u32 event_size, void *event) > +{ > + struct tpm12_event_log_header *evtlog = > + (struct

Re: [PATCH v6 04/14] x86: Secure Launch Resource Table header file

On Thu, May 04, 2023 at 02:50:13PM +, Ross Philipson wrote: > +#define SLR_TABLE_MAGIC 0x4452544d >From convention I'd expect this to be 0x534c5254, but not really an issue. > +/* SLR defined bootloaders */ > +#define SLR_BOOTLOADER_INVALID 0 > +#define

Re: [PATCH v6 02/14] Documentation/x86: Secure Launch kernel documentation

On Thu, May 04, 2023 at 02:50:11PM +, Ross Philipson wrote: > +Secure Launch does not interoperate with KASLR. If possible, the MLE should > be > +built with KASLR disabled:: Why does Secure Launch not interoperate with KASLR? Re: IOMMUs > +It is recommended that no other command line

Re: [PATCH] do not clean dummy variable in kexec path

On Fri, Sep 13, 2019 at 2:18 AM Ard Biesheuvel wrote: > > > - Remove the cleanup from the kexec path -- the cleanup logic from [4], > > > even if justified for the cold boot path, should have never modified > > > the kexec path. > > > > I agree that there's no benefit in it being called in

[PATCH V40 09/29] 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 Signed-off-by: Matthew Garrett cc: kexec@lists.infradead.org --- kernel/kexec_file.c | 2

[PATCH V40 06/29] 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 V40 08/29] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

. KEXEC_SIG_FORCE disallows images without a valid signature. Signed-off-by: Jiri Bohac Signed-off-by: David Howells Signed-off-by: Matthew Garrett cc: kexec@lists.infradead.org --- arch/arm64/Kconfig | 6 +-- arch/s390/Kconfig | 2 +- arch/s390/configs

[PATCH V40 07/29] lockdown: Copy secure_boot flag in boot params across kexec reboot

the secure_boot flag in original kernel. secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the stub. Fixing this issue by copying secure_boot flag across kexec reboot. Signed-off-by: Dave Young Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Kees Cook

Re: [PATCH 3/6] Avoid build warning when !CONFIG_KEXEC_SIG

On Tue, Aug 13, 2019 at 10:24 PM Dave Young wrote: > I can not get the whole thread, also not sure which tree it should > apply. This should be against -next. > Also I think it should be good to split the preparation piece of kexec > and send them separately. Since it is improve the signature

Re: [PATCH] do not clean dummy variable in kexec path

On Tue, Aug 13, 2019 at 4:28 AM Laszlo Ersek wrote: > (I verified yesterday, using the edk2 source code, that there is no > varstore reclaim after ExitBootServices(), indeed.) Some implementations do reclaim at runtime, in which case the create/delete dance will permit variable creation. > (a)

[PATCH 3/6] Avoid build warning when !CONFIG_KEXEC_SIG

Refactor the signature validation and lockdown integration a little in order to avoid an unused variable. Signed-off-by: Matthew Garrett Cc: Jiri Bohac Cc: Dave Young Cc: kexec@lists.infradead.org --- kernel/kexec_file.c | 72 - 1 file changed, 45

[PATCH V38 08/29] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

. KEXEC_SIG_FORCE disallows images without a valid signature. Signed-off-by: Jiri Bohac Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Jiri Bohac Reviewed-by: Dave Young cc: kexec@lists.infradead.org --- arch/x86/Kconfig | 20 + crypto

[PATCH V38 09/29] 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 Signed-off-by: Matthew Garrett Reviewed-by: Jiri Bohac Reviewed-by: Kees Cook cc: kexec

[PATCH V38 07/29] Copy secure_boot flag in boot params across kexec reboot

the secure_boot flag in original kernel. secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the stub. Fixing this issue by copying secure_boot flag across kexec reboot. Signed-off-by: Dave Young Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Kees Cook

[PATCH V38 06/29] 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

Re: [PATCH] do not clean dummy variable in kexec path

On Mon, Aug 5, 2019 at 1:36 AM Dave Young wrote: > > kexec reboot fails randomly in UEFI based kvm guest. The firmware > just reset while calling efi_delete_dummy_variable(); Unfortunately > I don't know how to debug the firmware, it is also possible a potential > problem on real hardware as

[PATCH V37 07/29] Copy secure_boot flag in boot params across kexec reboot

the secure_boot flag in original kernel. secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the stub. Fixing this issue by copying secure_boot flag across kexec reboot. Signed-off-by: Dave Young Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Kees Cook

[PATCH V37 08/29] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

. KEXEC_SIG_FORCE disallows images without a valid signature. Signed-off-by: Jiri Bohac Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Jiri Bohac Reviewed-by: Dave Young cc: kexec@lists.infradead.org --- arch/x86/Kconfig | 20 + crypto

[PATCH V37 06/29] 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 V37 09/29] 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 Signed-off-by: Matthew Garrett Reviewed-by: Jiri Bohac Reviewed-by: Kees Cook cc: kexec

[PATCH V36 09/29] 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 Signed-off-by: Matthew Garrett Reviewed-by: Jiri Bohac Reviewed-by: Kees Cook cc: kexec

[PATCH V36 07/29] Copy secure_boot flag in boot params across kexec reboot

the secure_boot flag in original kernel. secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the stub. Fixing this issue by copying secure_boot flag across kexec reboot. Signed-off-by: Dave Young Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Kees Cook

[PATCH V36 06/29] 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 V36 08/29] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

. KEXEC_SIG_FORCE disallows images without a valid signature. Signed-off-by: Jiri Bohac Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Jiri Bohac Reviewed-by: Dave Young cc: kexec@lists.infradead.org --- arch/x86/Kconfig | 20 + crypto

[PATCH V35 07/29] Copy secure_boot flag in boot params across kexec reboot

the secure_boot flag in original kernel. secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the stub. Fixing this issue by copying secure_boot flag across kexec reboot. Signed-off-by: Dave Young Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Kees Cook

[PATCH V35 06/29] 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 V35 08/29] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

. KEXEC_SIG_FORCE disallows images without a valid signature. Signed-off-by: Jiri Bohac Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Jiri Bohac Reviewed-by: Dave Young cc: kexec@lists.infradead.org --- arch/x86/Kconfig | 20 + crypto

[PATCH V35 09/29] 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 Signed-off-by: Matthew Garrett Reviewed-by: Jiri Bohac Reviewed-by: Kees Cook cc: kexec

Re: [PATCH V34 09/29] kexec_file: Restrict at runtime if the kernel is locked down

On Thu, Jun 27, 2019 at 11:14 AM James Morris wrote: > > On Thu, 27 Jun 2019, Matthew Garrett wrote: > > > By that metric, on a secure boot system how do we determine that code > > running in the firmware environment wasn't compromised before it > > launched the initia

Re: [PATCH V34 09/29] kexec_file: Restrict at runtime if the kernel is locked down

On Wed, Jun 26, 2019 at 9:59 PM James Morris wrote: > This is not a criticism of the patch but a related issue which I haven't > seen discussed (apologies if it has). > > If signed code is loaded into ring 0, verified by the kernel, then > executed, you still lose your secure/trusted/verified

Re: [PATCH V31 07/25] kexec_file: Restrict at runtime if the kernel is locked down

On Mon, Jun 24, 2019 at 2:27 PM Mimi Zohar wrote: > I agree with Dave. There should be a stub lockdown function to > prevent enforcing lockdown when it isn't enabled. Sorry, when what isn't enabled? If no LSMs are enforcing lockdown then the check will return 0. The goal here is for

Re: [PATCH V31 07/25] kexec_file: Restrict at runtime if the kernel is locked down

On Sun, Jun 23, 2019 at 6:52 PM Dave Young wrote: > > On 06/21/19 at 01:18pm, Matthew Garrett wrote: > > I don't think so - we want it to be possible to load images if they > > have a valid signature. > > I know it works like this way because of the previous patch. But fr

[PATCH V34 07/29] Copy secure_boot flag in boot params across kexec reboot

the secure_boot flag in original kernel. secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the stub. Fixing this issue by copying secure_boot flag across kexec reboot. Signed-off-by: Dave Young Signed-off-by: David Howells Signed-off-by: Matthew Garrett cc: kexec

[PATCH V34 06/29] 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 V34 08/29] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

if in non-forcing mode. ] Signed-off-by: Jiri Bohac Signed-off-by: David Howells Signed-off-by: Matthew Garrett Reviewed-by: Jiri Bohac cc: kexec@lists.infradead.org --- arch/x86/Kconfig | 20 --- crypto/asymmetric_keys/verify_pefile.c | 4 ++- include/linux/kexec.h

[PATCH V34 09/29] 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 Signed-off-by: Matthew Garrett Reviewed-by: Jiri Bohac cc: kexec@lists.infradead.org

Re: [PATCH V31 07/25] kexec_file: Restrict at runtime if the kernel is locked down

On Thu, Jun 20, 2019 at 11:43 PM Dave Young wrote: > > On 03/26/19 at 11:27am, Matthew Garrett wrote: > > From: Jiri Bohac > > > > When KEXEC_SIG is not enabled, kernel should not load images through > > kexec_file systemcall if the kernel is locked down. >

Re: [PATCH V31 06/25] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

On Fri, Jun 21, 2019 at 1:13 PM Matthew Garrett wrote: > > On Thu, Jun 20, 2019 at 11:34 PM Dave Young wrote: > > Force use -EKEYREJECTED is odd, why not just use original "ret"? > > Fair question. Jiri, any feelings here? Actually, looks like this cha

Re: [PATCH V31 06/25] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

On Thu, Jun 20, 2019 at 11:34 PM Dave Young wrote: > Force use -EKEYREJECTED is odd, why not just use original "ret"? Fair question. Jiri, any feelings here?

[PATCH V33 07/30] Copy secure_boot flag in boot params across kexec reboot

the secure_boot flag in original kernel. secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the stub. Fixing this issue by copying secure_boot flag across kexec reboot. Signed-off-by: Dave Young Signed-off-by: David Howells Signed-off-by: Matthew Garrett cc: kexec

[PATCH V33 06/30] 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 V33 08/30] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

error if there is a signature which cannot be parsed - even if in non-forcing mode. (5) kexec fails with ELIBBAD if the PE file cannot be parsed to extract the signature - even if in non-forcing mode. ] Signed-off-by: Jiri Bohac Signed-off-by: David Howells Signed-off-by: Matthew Garrett

[PATCH V33 09/30] 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 Signed-off-by: Matthew Garrett Reviewed-by: Jiri Bohac cc: kexec@lists.infradead.org

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

error if there is a signature which cannot be parsed - even if in non-forcing mode. (5) kexec fails with ELIBBAD if the PE file cannot be parsed to extract the signature - even if in non-forcing mode. ] Signed-off-by: Jiri Bohac Signed-off-by: David Howells Signed-off-by: Matthew Garrett

[PATCH V32 04/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 V32 07/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 Signed-off-by: Matthew Garrett Reviewed-by: Jiri Bohac cc: kexec@lists.infradead.org

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

the secure_boot flag in original kernel. secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the stub. Fixing this issue by copying secure_boot flag across kexec reboot. Signed-off-by: Dave Young Signed-off-by: David Howells Signed-off-by: Matthew Garrett cc: kexec

[PATCH V31 05/25] Copy secure_boot flag in boot params across kexec reboot

the secure_boot flag in original kernel. secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the stub. Fixing this issue by copying secure_boot flag across kexec reboot. Signed-off-by: Dave Young Signed-off-by: David Howells Signed-off-by: Matthew Garrett cc: kexec

[PATCH V31 06/25] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

error if there is a signature which cannot be parsed - even if in non-forcing mode. (5) kexec fails with ELIBBAD if the PE file cannot be parsed to extract the signature - even if in non-forcing mode. ] Signed-off-by: Jiri Bohac Signed-off-by: David Howells Signed-off-by: Matthew Garrett

[PATCH V31 07/25] 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 Signed-off-by: Matthew Garrett Reviewed-by: Jiri Bohac cc: kexec@lists.infradead.org

[PATCH V31 04/25] 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 05/27] Copy secure_boot flag in boot params across kexec reboot

the secure_boot flag in original kernel. secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the stub. Fixing this issue by copying secure_boot flag across kexec reboot. Signed-off-by: Dave Young Signed-off-by: David Howells cc: kexec@lists.infradead.org Signed-off-by: Matthew

[PATCH 07/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: kexec@lists.infradead.org Signed-off-by: Matthew Garrett

[PATCH 04/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 06/27] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

: kexec@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 ++ 4 files

[PATCH] kexec: Allow kexec_file() with appropriate IMA policy when locked down

-by: Matthew Garrett --- Mimi, this relies on the lockdown patchset but I /think/ is independent of the arch policy code - as a result I think it's possible to include this in lockdown PR if that works for you, otherwise it can go through your tree once the lockdown code is merged? include/linux

[RFC] kexec: Allow kexec_file() with appropriate IMA policy when locked down

-by: Matthew Garrett --- include/linux/ima.h | 9 + kernel/kexec_file.c | 9 +++-- security/integrity/ima/ima.h| 3 ++ security/integrity/ima/ima_main.c | 2 +- security/integrity/ima/ima_policy.c | 52 + 5 files changed

Re: [PATCH 3/3] x86/ima: retry detecting secure boot mode

On Mon, Mar 11, 2019 at 9:55 AM Mimi Zohar wrote: > > On Fri, 2019-03-08 at 09:51 -0800, Matthew Garrett wrote: > > Hm. And this only happens on certain firmware versions? If something's > > stepping on boot_params then we have bigger problems. > > I was seeing this

Re: [PATCH 3/3] x86/ima: retry detecting secure boot mode

On Fri, Mar 8, 2019 at 10:43 AM Mimi Zohar wrote: > FYI, efi_printk() works before exit_boot(), but not afterwards. The > system hangs. efi_printk() uses boot services to print, so that's not unexpected :) It would probably be sensible to return an error rather than crash, though…

Re: [PATCH 3/3] x86/ima: retry detecting secure boot mode

On Fri, Mar 8, 2019 at 5:40 AM Mimi Zohar wrote: > > On Thu, 2019-03-07 at 14:50 -0800, Matthew Garrett wrote: > > Is the issue that it gives incorrect results on the first read, or is > > the issue that it gives incorrect results before ExitBootServices() is > > calle

Re: [PATCH 3/3] x86/ima: retry detecting secure boot mode

On Thu, Mar 7, 2019 at 2:48 PM Mimi Zohar wrote: > I added this last attempt because I'm seeing this on my laptop, with > some older, buggy firmware. Is the issue that it gives incorrect results on the first read, or is the issue that it gives incorrect results before ExitBootServices() is

Re: [PATCH 3/3] x86/ima: retry detecting secure boot mode

On Thu, Mar 7, 2019 at 2:38 PM Justin Forbes wrote: > On Thu, Mar 7, 2019 at 4:29 PM Matthew Garrett wrote: >> >> On Mon, Nov 19, 2018 at 11:57 AM Mimi Zohar wrote: >> > >> > The secure boot mode may not be detected on boot for some reason (eg. >> >

Re: [PATCH 3/3] x86/ima: retry detecting secure boot mode

On Mon, Nov 19, 2018 at 11:57 AM Mimi Zohar wrote: > > The secure boot mode may not be detected on boot for some reason (eg. > buggy firmware). This patch attempts one more time to detect the > secure boot mode. Do we have cases where this has actually been seen? I'm not sure what the

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 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] PCI: Clear Bus Master bit only on kexec reboot

On Wed, Nov 27, 2013 at 12:18:28PM -0700, Khalid Aziz wrote: +/* flag to track if kexec reboot is in progress */ +extern unsigned long kexec_in_progress; Adding this to pci.h seems a little odd. We may want to use it somewhere else at some point. Add it to kexec.h instead? -- Matthew

Re: [PATCH] PCI: Clear Bus Master bit only on kexec reboot

will fail. I should add #ifdef CONFIG_KEXEC to the code in pci-driver.c as well. Time for v2. You're making the behaviour of the pci code conditional on whether we're in kexec or not, so I think adding kexec.h is perfectly reasonable. -- Matthew Garrett | mj...@srcf.ucam.org

Re: [PATCH] PCI: Clear Bus Master bit only on kexec reboot

. -- Matthew Garrett | mj...@srcf.ucam.org ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] PCI: Clear Bus Master bit only on kexec reboot

On Wed, Nov 27, 2013 at 02:01:06PM -0800, Greg KH wrote: On Wed, Nov 27, 2013 at 09:53:09PM +, Matthew Garrett wrote: On Wed, Nov 27, 2013 at 01:22:27PM -0800, Greg KH wrote: Then fix the drivers please. It's not as if you don't have access to the source for them all

Re: [PATCH 4/6] kexec: A new system call, kexec_file_load, for in kernel kexec

On Thu, Nov 21, 2013 at 02:13:05PM -0500, Vivek Goyal wrote: On Thu, Nov 21, 2013 at 07:06:20PM +, Matthew Garrett wrote: That would require a certain degree of massaging from userspace if we want to be able to use the existing Authenticode signatures. Otherwise we need to sign

Re: [PATCH 4/6] kexec: A new system call, kexec_file_load, for in kernel kexec

in the syscall. That would require a certain degree of massaging from userspace if we want to be able to use the existing Authenticode signatures. Otherwise we need to sign kernels twice. -- Matthew Garrett | mj...@srcf.ucam.org ___ kexec mailing list kexec

Re: [patch 2/4] remove extra acpi_rsdp command line for efi

the new UEFI setup code? -- Matthew Garrett | mj...@srcf.ucam.org ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Re: [patch 2/4] remove extra acpi_rsdp command line for efi

On Mon, Oct 28, 2013 at 05:54:59PM +0800, Dave Young wrote: Hi, Thanks for review. On 10/28/13 at 09:42am, Matthew Garrett wrote: On Sun, Oct 27, 2013 at 12:04:39PM +0800, dyo...@redhat.com wrote: Removing code to pass acpi_rsdp because this patch series will support efi runtime, it's

Re: [patch 2/4] remove extra acpi_rsdp command line for efi

On Mon, Oct 28, 2013 at 06:34:12PM +0800, Dave Young wrote: On 10/28/13 at 10:12am, Matthew Garrett wrote: Right, but previously acpi_rsdp was passed automatically and now it won't be? Yes, it was. I'm removing them in kexec-tools patches for efi runtime support. If I upgrade kexec-tools

Re: [patch 2/4] remove extra acpi_rsdp command line for efi

On Mon, Oct 28, 2013 at 06:45:32PM +0800, Dave Young wrote: On 10/28/13 at 10:39am, Matthew Garrett wrote: On Mon, Oct 28, 2013 at 06:34:12PM +0800, Dave Young wrote: On 10/28/13 at 10:12am, Matthew Garrett wrote: Right, but previously acpi_rsdp was passed automatically and now

Re: kexec: Clearing registers just before jumping into purgatory

uptake. I think that this is nice idea too. However, I have not seen its usage in real. Even once there was an idea to remove that stuff from Linux Kernel. I have not seen anybody using it. I don't even know if it works or not. It works. I'm using it. -- Matthew Garrett | mj

Re: kexec: Clearing registers just before jumping into purgatory

On Fri, Oct 11, 2013 at 11:44:50AM -0400, Vivek Goyal wrote: Just Curious. How is it useful. IOW, what's your use case of booting a new kernel and then jumping back. I'm kexecing into a kernel with a modified /dev/mem, modifying the original kernel and then jumping back into it. -- Matthew

Re: kexec: Clearing registers just before jumping into purgatory

On Fri, Oct 11, 2013 at 06:33:23PM +0200, Richard Weinberger wrote: On Fri, Oct 11, 2013 at 5:48 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Fri, Oct 11, 2013 at 11:44:50AM -0400, Vivek Goyal wrote: Just Curious. How is it useful. IOW, what's your use case of booting a new kernel

Re: kexec: Clearing registers just before jumping into purgatory

On Fri, Oct 11, 2013 at 06:42:36PM +0200, Richard Weinberger wrote: On Fri, Oct 11, 2013 at 6:39 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Fri, Oct 11, 2013 at 06:33:23PM +0200, Richard Weinberger wrote: On Fri, Oct 11, 2013 at 5:48 PM, Matthew Garrett mj...@srcf.ucam.org wrote

Re: kexec: Clearing registers just before jumping into purgatory

On Fri, Oct 11, 2013 at 12:53:51PM -0400, Vivek Goyal wrote: On Fri, Oct 11, 2013 at 05:44:00PM +0100, Matthew Garrett wrote: I have /dev/mem and a list of addresses I want to modify. Why to boot in a second kernel to modify first kernel's RAM. Why not do it directly from the first kernel

Re: kexec: Clearing registers just before jumping into purgatory

that ksplice? -- Matthew Garrett | mj...@srcf.ucam.org ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec: Clearing registers just before jumping into purgatory

On Fri, Oct 11, 2013 at 06:59:41PM +0200, Richard Weinberger wrote: Am 11.10.2013 18:55, schrieb Matthew Garrett: On Fri, Oct 11, 2013 at 06:47:19PM +0200, Richard Weinberger wrote: But you still need a magic tool which create you this list. I just read /proc/kallsyms. I'm really

Re: kexec: Clearing registers just before jumping into purgatory

On Fri, Oct 11, 2013 at 01:44:19PM -0700, Eric W. Biederman wrote: Matthew Garrett mj...@srcf.ucam.org writes: No, I manually look up some addresses from /proc/kallsyms and then modify them in the second kernel. An interesting approach I think most of the rest of us would have just built

Re: [PATCH 15/16] bootparam: Pass acpi_rsdp pointer in bootparam

address and go downwards and the mappings will have the same addresses per UEFI implementation. The second kernel still needs to be passed a pointer to the EFI tables and memory map. -- Matthew Garrett matthew.garr...@nebula.com ___ kexec mailing list

Re: [PATCH V3 08/11] kexec: Disable at runtime if the kernel enforces module loading restrictions

On Wed, 2013-09-04 at 14:09 -0600, jerry.hoem...@hp.com wrote: On Tue, Sep 03, 2013 at 07:50:15PM -0400, Matthew Garrett wrote: 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

Re: [PATCH 01/12] Security: Add CAP_COMPROMISE_KERNEL

. Are you suggesting that removing the CAP_SYS_RAWIO check there would be reasonable? -- Matthew Garrett | mj...@srcf.ucam.org ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec

  1   2   >