Re: [PATCH v2] efi/efi_test: lock down /dev/efi_test and require CAP_SYS_ADMIN

On Tue, Oct 8, 2019 at 9:55 PM Javier Martinez Canillas wrote: > Signed-off-by: Javier Martinez Canillas > Acked-by: Laszlo Ersek Acked-by: Matthew Garrett

Re: [PATCH 1/2] efi+tpm: Don't access event->count when it isn't mapped.

On Tue, Aug 27, 2019 at 6:42 AM Jarkko Sakkinen wrote: > > On Tue, Aug 27, 2019 at 02:03:44PM +0300, Jarkko Sakkinen wrote: > > > Jarkko, these two should probably go to 5.3 if possible - I > > > independently had a report of a system hitting this issue last week > > > (Intel apparently put a

Re: [PATCH 2/2] efi+tpm: don't traverse an event log with no events

events); > > + tbl_size = tpm2_calc_event_log_size(events, > > + final_tbl->nr_events, > > + log_tbl->log); > > + } > > Reviewed-by: Jarkko Sakkinen Acked-by: Matthew Garrett

Re: [PATCH 1/2] efi+tpm: Don't access event->count when it isn't mapped.

off-by: Peter Jones > > Tested-by: Lyude Paul > > Reviewed-by: Jarkko Sakkinen Acked-by: Matthew Garrett Jarkko, these two should probably go to 5.3 if possible - I independently had a report of a system hitting this issue last week (Intel apparently put a surprising amount of data in the event logs on the NUCs).

[PATCH V40 28/29] efi: Restrict efivar_ssdt_load when the kernel is locked down

efivar_ssdt_load allows the kernel to import arbitrary ACPI code from an EFI variable, which gives arbitrary code execution in ring 0. Prevent that when the kernel is locked down. Signed-off-by: Matthew Garrett Acked-by: Ard Biesheuvel Reviewed-by: Kees Cook Cc: Ard Biesheuvel Cc: linux-efi

[PATCH V38 28/29] efi: Restrict efivar_ssdt_load when the kernel is locked down

efivar_ssdt_load allows the kernel to import arbitrary ACPI code from an EFI variable, which gives arbitrary code execution in ring 0. Prevent that when the kernel is locked down. Signed-off-by: Matthew Garrett Acked-by: Ard Biesheuvel Reviewed-by: Kees Cook Cc: Ard Biesheuvel Cc: linux-efi

Re: [PATCH 5.3 regression fix] efi-stub: Fix get_efi_config_table on mixed-mode setups

On Wed, Aug 7, 2019 at 2:59 PM Hans de Goede wrote: > > Fix get_efi_config_table using the wrong structs when booting a > 64 bit kernel on 32 bit firmware. > > Cc: Matthew Garrett > Cc: Ard Biesheuvel > Cc: Jarkko Sakkinen > Fixes: 82d736ac56d7 ("Abstract out suppo

[PATCH V37 28/29] efi: Restrict efivar_ssdt_load when the kernel is locked down

efivar_ssdt_load allows the kernel to import arbitrary ACPI code from an EFI variable, which gives arbitrary code execution in ring 0. Prevent that when the kernel is locked down. Signed-off-by: Matthew Garrett Acked-by: Ard Biesheuvel Reviewed-by: Kees Cook Cc: Ard Biesheuvel Cc: linux-efi

[PATCH V36 28/29] efi: Restrict efivar_ssdt_load when the kernel is locked down

efivar_ssdt_load allows the kernel to import arbitrary ACPI code from an EFI variable, which gives arbitrary code execution in ring 0. Prevent that when the kernel is locked down. Signed-off-by: Matthew Garrett Acked-by: Ard Biesheuvel Reviewed-by: Kees Cook Cc: Ard Biesheuvel Cc: linux-efi

[PATCH V35 28/29] efi: Restrict efivar_ssdt_load when the kernel is locked down

efivar_ssdt_load allows the kernel to import arbitrary ACPI code from an EFI variable, which gives arbitrary code execution in ring 0. Prevent that when the kernel is locked down. Signed-off-by: Matthew Garrett Acked-by: Ard Biesheuvel Reviewed-by: Kees Cook Cc: Ard Biesheuvel Cc: linux-efi

[PATCH V34 28/29] efi: Restrict efivar_ssdt_load when the kernel is locked down

efivar_ssdt_load allows the kernel to import arbitrary ACPI code from an EFI variable, which gives arbitrary code execution in ring 0. Prevent that when the kernel is locked down. Signed-off-by: Matthew Garrett Cc: Ard Biesheuvel Cc: linux-efi@vger.kernel.org --- drivers/firmware/efi/efi.c | 6

[PATCH V33 30/30] efi: Restrict efivar_ssdt_load when the kernel is locked down

efivar_ssdt_load allows the kernel to import arbitrary ACPI code from an EFI variable, which gives arbitrary code execution in ring 0. Prevent that when the kernel is locked down. Signed-off-by: Matthew Garrett Cc: Ard Biesheuvel Cc: linux-efi@vger.kernel.org --- drivers/firmware/efi/efi.c | 4

Re: [PATCH] drivers: firmware: efi: fix gcc warning -Wint-conversion

On Thu, Jun 20, 2019 at 2:37 PM Jarkko Sakkinen wrote: > Right! OK, I squashed just the fix to the earlier patch. Master and > next are updated. Can you take a peek of [1] and see if it looks > legit given all the fuzz around these changes? Then I'm confident > enough to do the 5.3 PR. All looks

Re: [PATCH] drivers: firmware: efi: fix gcc warning -Wint-conversion

On Wed, Jun 19, 2019 at 2:55 AM Ard Biesheuvel wrote: > > (+ Jarkko, tpmdd, Matthew) > > On Sat, 15 Jun 2019 at 06:02, Hariprasad Kelam > wrote: > > > > This patch fixes below warning > > > > drivers/firmware/efi/tpm.c:78:38: warning: passing argument 1 of > > ‘tpm2_calc_event_log_size’ makes

Re: [PATCH V2 1/2] Abstract out support for locating an EFI config table

On Mon, Jun 10, 2019 at 9:58 AM Jarkko Sakkinen wrote: > > On Fri, Jun 07, 2019 at 01:51:46PM -0700, Matthew Garrett wrote: > > We want to grab a pointer to the TPM final events table, so abstract out > > the existing code for finding an FDT table and make it generic.

[PATCH V2 1/2] Abstract out support for locating an EFI config table

We want to grab a pointer to the TPM final events table, so abstract out the existing code for finding an FDT table and make it generic. Signed-off-by: Matthew Garrett --- .../firmware/efi/libstub/efi-stub-helper.c| 15 +++ drivers/firmware/efi/libstub/efistub.h| 2

Re: [PATCH] efi: Fix TPM code build failure on ARM

On Thu, Jun 6, 2019 at 4:39 AM Ard Biesheuvel wrote: > > On Wed, 5 Jun 2019 at 20:11, Matthew Garrett > wrote: > > > > asm/early_ioremap.h needs to be #included before tpm_eventlog.h in order > > to ensure that early_memremap is available. > > > > Do

[PATCH] efi: Fix TPM code build failure on ARM

asm/early_ioremap.h needs to be #included before tpm_eventlog.h in order to ensure that early_memremap is available. Signed-off-by: Matthew Garrett --- drivers/firmware/efi/tpm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware

[PATCH V2] tpm: Don't duplicate events from the final event log in the TCG2 log

this problem by looking at the size of the Final Event Log just before we call ExitBootServices() and exporting this to the main kernel. The kernel can then skip over all events that occured before ExitBootServices() and only append events that were not also logged to the main log. Signed-off-by: Matthew

[PATCH] tpm: Don't duplicate events from the final event log in the TCG2 log

this problem by looking at the size of the Final Event Log just before we call ExitBootServices() and exporting this to the main kernel. The kernel can then skip over all events that occured before ExitBootServices() and only append events that were not also logged to the main log. Signed-off-by: Matthew

Re: [Bug 203761] New: efivar_ssdt_iter is subject to stack corruption when the input name_size is 0

On Fri, May 31, 2019 at 2:03 AM Ard Biesheuvel wrote: > > The input of name_size is signed long, gets compared against an unsigned > > long > > of a fixed size, then stored as a signed int (this is mostly okay because of > > the known max size), but it then gets passed to a function takes

[PATCH V7 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 V7 0/4] Add support for crypto agile logs

Identical to previous version except without the KSAN workaround - Ard has a better solution for that.

[PATCH V7 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 V7 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 V7 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 V6 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 V6 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 V6 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 V6 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 V6 0/4] Add support for crypto agile TPM event logs

Updated with the fixes from Bartosz and the header fixes folded in. Bartosz, my machine still doesn't generate any final event log entries - are you able to give this a test and make sure it's good?

Re: [PATCH 0/4] Enabling secure boot on PowerNV systems

On Fri, May 10, 2019 at 2:31 PM Claudio Carvalho wrote: > On 4/10/19 2:36 PM, Matthew Garrett wrote: > > I don't see the benefit in attempting to maintain compatibility with > > existing tooling unless you're going to be *completely* compatible > > with existing tooling. That

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

Sorry, how about this one? I was confused by why I wasn't hitting this, but on closer examination it turns out that my system populates the final event log with 0 events which means we never hit this codepath :( diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware/efi/tpm.c index

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

On Thu, May 2, 2019 at 12:15 AM Ard Biesheuvel wrote: > > (+ Ingo) > > On Tue, 30 Apr 2019 at 21:52, Matthew Garrett wrote: > > > > On Tue, Apr 30, 2019 at 6:07 AM Bartosz Szczepanek > > wrote: > > > > > > I may be a little late with this c

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

On Thu, May 2, 2019 at 1:32 AM Jarkko Sakkinen wrote: > > On Tue, Apr 30, 2019 at 03:07:09PM +0200, Bartosz Szczepanek wrote: > > I may be a little late with this comment, but I've just tested these > > patches on aarch64 platform (from the top of jjs/master) and got > > kernel panic ("Unable to

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

On Tue, Apr 30, 2019 at 12:51 PM Matthew Garrett wrote: > Yes, it looks like this is just broken. Can you try with the attached patch? Actually, please try this one. diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware/efi/tpm.c index 2ccaa6661aaf..db0fdaa9c666 100644 --- a/driv

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

On Tue, Apr 30, 2019 at 6:07 AM Bartosz Szczepanek wrote: > > I may be a little late with this comment, but I've just tested these > patches on aarch64 platform (from the top of jjs/master) and got > kernel panic ("Unable to handle kernel read", full log at the end of > mail). I think there's

Re: kexec reboot reset with efi_delete_dummy_variable

On Wed, Apr 17, 2019 at 8:44 PM Dave Young wrote: > So why we still need delete/cleanup the dummy var after entering virt > mode? Am I missing something? I can't think of any reason why you'd need to do this on kexec, but it's vital to do so in the real enter_virtual_mode() path. It should be

Re: [PATCH 0/4] Enabling secure boot on PowerNV systems

(Cc:ing Peter Jones) On Tue, Apr 9, 2019 at 3:55 PM Claudio Carvalho wrote: > > > On 4/5/19 7:19 PM, Matthew Garrett wrote: > > Based on our experience doing this in UEFI, that's insufficient - you > > want to be able to block individual binaries or leaf certificates >

Re: [PATCH 0/4] Enabling secure boot on PowerNV systems

On Fri, Apr 5, 2019 at 2:11 PM Claudio Carvalho wrote: > > > On 4/3/19 7:27 PM, Matthew Garrett wrote: > > Not supporting dbx seems like a pretty significant shortcoming. How > > are signatures meant to be revoked? > > > We began by focusing on certificates for keys

Re: [PATCH] TCG2 log support build fixes for non-x86_64

On Thu, Apr 4, 2019 at 5:41 AM Jarkko Sakkinen wrote: > > On Tue, Apr 02, 2019 at 02:55:54PM -0700, Matthew Garrett wrote: > > Couple of patches to fix ktest reported issues with the crypto-agile log > > format support. > > I guess I squash these to your earlier commits? Works for me.

Re: [PATCH 1/2] efi: Fix cast to pointer from integer of different size in TPM log code

On Thu, Apr 4, 2019 at 5:54 AM Ard Biesheuvel wrote: > > On Wed, 3 Apr 2019 at 04:56, Matthew Garrett > wrote: > > > > 8bfcff4a6a1d9d7226bb63a7da758b82d9ab4373 > > Which tree is this commit in? Sorry, these are in the tpmdd-next tree.

Re: [PATCH 0/4] Enabling secure boot on PowerNV systems

On Tue, Apr 2, 2019 at 4:31 PM Claudio Carvalho wrote: > > > On 4/2/19 6:51 PM, Matthew Garrett wrote: > > So you implement the full PK/KEK/db/dbx/dbt infrastructure, and > > updates are signed in the same way? > > For the first version, our firmware will implement a

[PATCH] efi: Include tpm_eventlog.h after asm/efi.h to avoid memcpy breakage

-by: Matthew Garrett --- drivers/firmware/efi/libstub/tpm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/firmware/efi/libstub/tpm.c b/drivers/firmware/efi/libstub/tpm.c index b6e93e14fcf1..777c1e82495a 100644 --- a/drivers/firmware/efi/libstub/tpm.c +++ b/drivers

Re: [PATCH 1/2] efi: Fix cast to pointer from integer of different size in TPM log code

On Wed, Apr 3, 2019 at 6:41 AM David Laight wrote: > > From: Matthew Garrett > > Sent: 02 April 2019 22:56 > > > > 8bfcff4a6a1d9d7226bb63a7da758b82d9ab4373 introduced a cast from > > efi_physical_address_t to (void *), which are different sizes on 32-bit. > >

[PATCH] TCG2 log support build fixes for non-x86_64

Couple of patches to fix ktest reported issues with the crypto-agile log format support.

[PATCH 1/2] efi: Fix cast to pointer from integer of different size in TPM log code

8bfcff4a6a1d9d7226bb63a7da758b82d9ab4373 introduced a cast from efi_physical_address_t to (void *), which are different sizes on 32-bit. Fix that. Caught by the 0-day test bot. Signed-off-by: Matthew Garrett --- drivers/firmware/efi/libstub/tpm.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[PATCH 2/2] tpm: Fix builds on platforms that lack early_memremap()

for obtaining crypto-agile logs. Abstract this away so we can avoid the need for two implementations while still avoiding breakage on architectures that don't require remapping of the table. Signed-off-by: Matthew Garrett --- drivers/firmware/efi/tpm.c | 3 +++ include/linux/tpm_eventlog.h | 32

Re: [PATCH 0/4] Enabling secure boot on PowerNV systems

On Tue, Apr 2, 2019 at 2:11 PM Claudio Carvalho wrote: > We want to use the efivarfs for compatibility with existing userspace > tools. We will track and match any EFI changes that affect us. So you implement the full PK/KEK/db/dbx/dbt infrastructure, and updates are signed in the same way? >

Re: [PATCH 0/4] Enabling secure boot on PowerNV systems

On Tue, Apr 2, 2019 at 11:15 AM Claudio Carvalho wrote: > 1. Enable efivarfs by selecting CONFIG_EFI in the CONFIG_OPAL_SECVAR >introduced in this patch set. With CONFIG_EFIVAR_FS, userspace tools can >be used to manage the secure variables. efivarfs has some pretty significant

Re: Add support for TCG2 log format on UEFI systems

On Tue, Apr 2, 2019 at 6:07 AM Jarkko Sakkinen wrote: > Reviewed-by: Jarkko Sakkinen > Tested-by: Jarkko Sakkinen > > I'll apply all patches soonish and include them to the next PR. Thanks! Looks like I need some fixes to deal with non-x86 architectures, I'll get on that today.

Re: Add support for TCG2 log format on UEFI systems

On Mon, Apr 1, 2019 at 4:52 PM Jarkko Sakkinen wrote: > > On Wed, Feb 27, 2019 at 12:26:54PM -0800, Matthew Garrett wrote: > > Identical to V4, but based on tpmdd-next > > OK, so on my GLK NUC I get valid final log and invalid event log > after adding some

Re: Add support for TCG2 log format on UEFI systems

On Thu, Mar 14, 2019 at 2:35 AM Jarkko Sakkinen wrote: > > On Wed, Feb 27, 2019 at 12:26:54PM -0800, Matthew Garrett wrote: > > Identical to V4, but based on tpmdd-next > > This is not found /sys/kernel/security/tpm0/ascii_bios_measurements That's expected - the existing ke

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

[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

[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 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

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 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 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 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 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

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: 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. -- To unsubscribe from this list: send the line "unsubscribe

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 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 9:39 AM Andy Lutomirski <l...@kernel.org> wrote: > On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett <mj...@google.com> wrote: > > If you don't have secure boot then an attacker with root can modify your > > bootloader or kernel, and on next bo

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 11:56 PM Peter Dolding <oia...@gmail.com> wrote: > On Wed, Apr 4, 2018 at 11:13 AM, Matthew Garrett <mj...@google.com> wrote: > > There are four cases: > > > > Verified Boot off, lockdown off: Status quo in distro and mainline kernel

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 6:52 AM Theodore Y. Ts'o wrote: > On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote: > > Theodore Y. Ts'o wrote: > > > > > Whoa. Why doesn't lockdown prevent kexec? Put another away, why > > > isn't this a problem for people who

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 5:57 AM Theodore Y. Ts'o <ty...@mit.edu> wrote: > On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote: > > What I'm afraid of is this turning into a "security" feature that ends up > > being circumvented in most scenarios whe

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 9:09 AM Linus Torvalds <torva...@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 9:30 PM, Matthew Garrett <mj...@google.com> wrote: > > > > Bear in mind that I'm talking about defaults here > Mattyhew, I really want you to look yo

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 7:34 PM Alexei Starovoitov < alexei.starovoi...@gmail.com> wrote: > If the only thing that folks are paranoid about is reading > arbitrary kernel memory with bpf_probe_read() helper > then preferred patch would be to disable it during verification > when in lockdown mode. >

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 6:43 PM Linus Torvalds <torva...@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 6:13 PM, Matthew Garrett <mj...@google.com> wrote: > > > > There are four cases: > No. > Matthew., stop with the agenda already. > This shit is w

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 5:56 PM Linus Torvalds <torva...@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 5:46 PM, Matthew Garrett <mj...@google.com> wrote: > > > > The generic distros have been shipping this policy for the past 5 years. > .. so apparently it

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 5:18 PM Andy Lutomirski wrote: > if your secure boot-enabled bootloader can't prevent a bad guy from > using malicious kernel command line parameters, then fix it. How is a bootloader supposed to know what the set of malicious kernel command line

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 5:15 PM Linus Torvalds <torva...@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 5:10 PM, Matthew Garrett <mj...@google.com> wrote: > > > >> Exactly like EVERY OTHER KERNEL CONFIG OPTION. > > > > So your argument is tha

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 5:08 PM Linus Torvalds wrote: > Still better than telling them to disable/enable secure boot, which > they may or may not even be able to to. Users who can boot a non-vendor Linux distribution on their platform can disable Secure Boot 100% of

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 5:06 PM Linus Torvalds <torva...@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 4:59 PM, Matthew Garrett <mj...@google.com> wrote: > > > > Ok. So we can build distribution kernels that *always* have this on, and to > > turn it of

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 5:02 PM Linus Torvalds <torva...@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 4:47 PM, Matthew Garrett <mj...@google.com> wrote: > >> Another way of looking at this: if lockdown is a good idea to enable > >> when you booted

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:55 PM Linus Torvalds <torva...@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 4:45 PM, Matthew Garrett <mj...@google.com> wrote: > >> Be honest now. It wasn't generally users who clamored for it. > > > > If you ask a user

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:39 PM Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 4:26 PM, Linus Torvalds > wrote: > > > > Magically changing kernel behavior depending on some subtle and often > > unintentional bootup behavior detail is

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:26 PM Linus Torvalds <torva...@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 4:17 PM, Matthew Garrett <mj...@google.com> wrote: > > > > 1) Secure Boot is intended to permit the construction of a boot chain that > > only runs ri

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:08 PM Linus Torvalds wrote: > That's not the right approach to begin with, Matthew. The onus is on > *you* to explain why you tied them together, not on others to explain > to you - over and over - that they have nothing to do with each

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 3:53 PM Andy Lutomirski <l...@kernel.org> wrote: > On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett <mj...@google.com> wrote: > > Lockdown is clearly useful without Secure Boot (and I intend to deploy it > > that way for various things), but I sti

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 3:46 PM Linus Torvalds wrote: > For example, I love signed kernel modules. The fact that I love them > has absolutely zero to do with secure boot, though. There is > absolutely no linkage between the two issues: I use (self-)signed > kernel

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 2:21 PM Al Viro <v...@zeniv.linux.org.uk> wrote: > On Tue, Apr 03, 2018 at 09:08:54PM +, Matthew Garrett wrote: > > If you don't want Secure Boot, turn it off. If you want Secure Boot, use a > > kernel that behaves in a way that actually in

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 2:26 PM Linus Torvalds <torva...@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 2:08 PM, Matthew Garrett <mj...@google.com> wrote: > > > > Secure Boot ensures that the firmware will only load signed bootloaders. If > > a signed

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 2:01 PM Linus Torvalds <torva...@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 1:54 PM, Matthew Garrett <mj...@google.com> wrote: > > > >> .. maybe you don't *want* secure boot, but it's been pushed in your > >> face by p

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 1:53 PM Linus Torvalds <torva...@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett <mj...@google.com> wrote: > > On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski <l...@kernel.org> wrote: > >> Can you explain tha

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski wrote: > Can you explain that much more clearly? I'm asking why booting via > UEFI Secure Boot should enable lockdown, and I don't see what this has > to do with kexec. And "someone blacklist[ing] your key in the > bootloader"

Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions

On Tue, Feb 20, 2018 at 3:30 PM Luck, Tony wrote: > [1] I didn't dig through the Linux code to check whether we manage to > get those four SMIs from a single EFI call, or whether we make multiple > EFI calls to open/read/close one file. It is possible that we stink a > bit

Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions

On Tue, Feb 20, 2018 at 1:18 PM Luck, Tony wrote: > Does this rate an exception to the "don't break userspace" for a security issue? To be clear, when you say "security" is this in reference to it being a denial of service, or are you worried about other interactions that

  1   2   3   4   >