Re: [GIT PULL] Kernel lockdown for secure boot

Hi! > > What I'm afraid of is this turning into a "security" feature that ends up > > being circumvented in most scenarios where it's currently deployed - eg, > > module signatures are mostly worthless in the non-lockdown case because you > > can just grab the sig_enforce symbol address and then

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed 2018-04-04 00:39:05, David Howells wrote: > Linus Torvalds wrote: > > > The same thing is true of some lockdown patch. Maybe it's a good thing > > in general. But whether it's a good thing is _entirely_ independent of > > any secure boot issue. I can see

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

Hi! > > Our ability to determine that userland hasn't been tampered with > > depends on the kernel being trustworthy. If userland can upload > > arbitrary firmware to DMA-capable devices then we can no longer trust > > the kernel. So yes, firmware is special. > > You're ignoring the whole

Re: Draft manpage explaining kernel lockdown

Hi! > Attached is a draft for a manual page (kernel_lockdown.7) that I intend to > point at from messages emitted when the kernel prohibits something because the > kernel is in 'lockdown' mode, typically triggered by EFI secure > boot. What about livepatching? It allows kernel modifications..

Re: [PATCH v7 3/3] x86: Make the GDT remapping read-only on 64-bit

On Tue 2017-03-14 10:05:08, Thomas Garnier wrote: > This patch makes the GDT remapped pages read-only to prevent corruption. > This change is done only on 64-bit. > > The native_load_tr_desc function was adapted to correctly handle a > read-only GDT. The LTR instruction always writes to the GDT

Re: [PATCH v2 08/16] x86/efi: Carrying hibernation key by setup data

On Tue 2015-08-11 14:16:28, Lee, Chun-Yi wrote: For forwarding hibernation key from EFI stub to boot kernel, this patch allocates setup data for carrying hibernation key, size and the status of efi operating. Reviewed-by: Jiri Kosina jkos...@suse.com Jiri, are you sure you reviewed these?

Re: [RFC PATCH 03/16] x86/boot: Public getting random boot function

On Fri 2015-07-31 18:52:09, joeyli wrote: On Tue, Jul 28, 2015 at 02:21:33PM +0200, Pavel Machek wrote: Hi! int cmdline_find_option_bool(const char *option); #endif +#if CONFIG_RANDOMIZE_BASE Not ifdef? +extern u16 i8254(void); That's rather poor name

Re: [RFC PATCH 01/16] PM / hibernate: define HMAC algorithm and digest size of swsusp

On Fri 2015-07-31 18:08:12, joeyli wrote: On Tue, Jul 28, 2015 at 02:01:56PM +0200, Pavel Machek wrote: On Thu 2015-07-16 22:25:15, Lee, Chun-Yi wrote: Using HMAC-SHA1 to be the HMAC algorithm of signing hibernate snapshot image. The digest size of HMAC-SHA1 is 160 bits (20 bytes

Re: [RFC PATCH 04/16] x86/efi: Generating random number in EFI stub

Hi! This patch adds the codes for generating random number array as the HMAC key that will used by later EFI stub codes. The original codes in efi_random copied from aslr and add the codes to accept input entropy and EFI debugging. In later patch will add the codes to get random number by

Re: [RFC PATCH 09/16] PM / hibernate: Reserve swsusp key and earse footprints

Typo in patch subject. And for earsing footbprints, the codes in this patch remove setup And two typos here. data that carried swsusp key, and clean the memory space that And don't call it swsusp. Please fix globally. +++

Re: [RFC PATCH 01/16] PM / hibernate: define HMAC algorithm and digest size of swsusp

On Thu 2015-07-16 22:25:15, Lee, Chun-Yi wrote: Using HMAC-SHA1 to be the HMAC algorithm of signing hibernate snapshot image. The digest size of HMAC-SHA1 is 160 bits (20 bytes), this size will be also applied to the length of HMAC key. In addition, add HIBERNATE_VERIFICATION kernel config.

Re: [RFC PATCH 03/16] x86/boot: Public getting random boot function

Hi! int cmdline_find_option_bool(const char *option); #endif +#if CONFIG_RANDOMIZE_BASE Not ifdef? +extern u16 i8254(void); That's rather poor name for global function... #if CONFIG_RANDOMIZE_BASE Ok, maybe not, but I'm confused.

Re: [RFC PATCH 06/16] x86/efi: Generating random HMAC key for siging hibernate image

For generating a messy number as a 20 bytes key, the codes in EFI stub gets u32 random number five time and every random number is rolling that last u32 random number as entropy. Parse error here. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures)

Re: [RFC PATCH 05/16] x86/efi: Get entropy through EFI random number generator protocol

On Thu 2015-07-16 22:25:19, Lee, Chun-Yi wrote: To grab random numbers through EFI protocol as one of the entropies source of swsusp key, this patch adds the logic for accessing EFI RNG (random number generator) protocol that's introduced since UEFI 2.4. Signed-off-by: Lee, Chun-Yi

Re: [PATCH 01/44] kernel: Add support for poweroff handler call chain

Hi! +/** + * register_poweroff_handler_simple - Register function to be called to power off + * the system + * @handler: Function to be called to power off the system + * @priority: Handler priority. For priority guidelines see + *

Re: [PATCH 01/12] Add support for indicating that the booted kernel is externally trusted

On Wed 2014-02-26 15:11:02, Matthew Garrett wrote: Provide a boolean runtime configuration option for restricting userspace's ability to modify the running kernel. This can be used when some external validation of the kernel's state has been performed. I still don't like the idea, but...

Re: [PATCH V4 13/15] Hibernate: introduced SNAPSHOT_SIG_HASH config for select hash algorithm

Hi! On Sun 2013-09-15 08:56:59, Lee, Chun-Yi wrote: This patch introduced SNAPSHOT_SIG_HASH config for user to select which hash algorithm will be used during signature generation of snapshot. This series is big enough already... and who is going to test it? The hash config not

Re: [PATCH V4 13/15] Hibernate: introduced SNAPSHOT_SIG_HASH config for select hash algorithm

On Sun 2013-09-15 08:56:59, Lee, Chun-Yi wrote: This patch introduced SNAPSHOT_SIG_HASH config for user to select which hash algorithm will be used during signature generation of snapshot. This series is big enough already... and who is going to test it? There's no need to make hash

Re: [PATCH 17/18] Hibernate: introduced SNAPSHOT_SIG_HASH config for select hash algorithm

On Tue 2013-08-27 18:22:17, joeyli wrote: 於 日，2013-08-25 於 18:43 +0200，Pavel Machek 提到： On Thu 2013-08-22 19:01:56, Lee, Chun-Yi wrote: This patch introduced SNAPSHOT_SIG_HASH config for user to select which hash algorithm will be used during signature generation of snapshot. v2

Re: [PATCH 11/18] Hibernate: introduced RSA key-pair to verify signature of snapshot

On Tue 2013-08-27 14:01:42, Manfred Hollstein wrote: On Tue, 27 Aug 2013, 13:29:43 +0200, Pavel Machek wrote: @@ -1205,6 +1290,10 @@ struct boot_params *efi_main(void *handle, efi_system_table_t *_table, setup_efi_pci(boot_params); +#ifdef

Re: [PATCH 03/18] asymmetric keys: separate the length checking of octet string from RSA_I2OSP

Hi! Due to RSA_I2OSP is not only used by signature verification path but also used in signature generation path. So, separate the length checking of octet string because it's not for generate 0x00 0x01 leading string when used in signature generation. Reviewed-by:

Re: [PATCH 03/18] asymmetric keys: separate the length checking of octet string from RSA_I2OSP

On Thu 2013-08-22 19:01:42, Lee, Chun-Yi wrote: Due to RSA_I2OSP is not only used by signature verification path but also used in signature generation path. So, separate the length checking of octet string because it's not for generate 0x00 0x01 leading string when used in signature

Re: [PATCH 07/18] asymmetric keys: explicitly add the leading zero byte to encoded message

On Thu 2013-08-22 19:01:46, Lee, Chun-Yi wrote: Per PKCS1 spec, the EMSA-PKCS1-v1_5 encoded message is leading by 0x00 0x01 in its first 2 bytes. The leading zero byte is suppressed by MPI so we pass a pointer to the _preceding_ byte to RSA_verify() in original code, but it has risk for the

Re: [PATCH 08/18] Secure boot: Add new capability

On Thu 2013-08-22 19:01:47, Lee, Chun-Yi wrote: From: Matthew Garrett m...@redhat.com Secure boot adds certain policy requirements, including that root must not be able to do anything that could cause the kernel to execute arbitrary code. The simplest way to handle this would seem to be to

Re: [PATCH 09/18] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode

You may want to check subject. If it does something, it is not dummy. --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2784,6 +2784,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted. Note: increases power

Re: [PATCH 10/18] efi: Enable secure boot lockdown automatically when enabled in firmware

On Thu 2013-08-22 19:01:49, Lee, Chun-Yi wrote: From: Matthew Garrett m...@redhat.com The firmware has a set of flags that indicate whether secure boot is enabled and enforcing. Use them to indicate whether the kernel should lock itself down. We also indicate the machine is in secure boot

Re: [PATCH 11/18] Hibernate: introduced RSA key-pair to verify signature of snapshot

On Thu 2013-08-22 19:01:50, Lee, Chun-Yi wrote: Introduced a hibernate_key.c file to query the key pair from EFI variables and maintain key pair for check signature of S4 snapshot image. We loaded the private key when snapshot image stored success. This patch introduced 2 EFI variables for

Re: [PATCH 12/18] Hibernate: generate and verify signature of snapshot

On Thu 2013-08-22 19:01:51, Lee, Chun-Yi wrote: This patch add the code for generate/verify signature of snapshot, it put the signature to snapshot header. This approach can support both on userspace hibernate and in-kernel hibernate. v2: - Due to loaded S4 sign key before ExitBootServices,

Re: [PATCH 13/18] Hibernate: Avoid S4 sign key data included in snapshot image

On Thu 2013-08-22 19:01:52, Lee, Chun-Yi wrote: This patch add swsusp_page_is_sign_key() method to hibernate_key.c and check the page is S4 sign key data when collect saveable page in snapshot.c to avoid sign key data included in snapshot image. Reviewed-by: Jiri Kosina jkos...@suse.cz

Re: [PATCH 15/18] Hibernate: adapt to UEFI secure boot with signature check

On Thu 2013-08-22 19:01:54, Lee, Chun-Yi wrote: In current solution, the snapshot signature check used the RSA key-pair that are generated by bootloader(e.g. shim) and pass the key-pair to kernel through EFI variables. I choice to binding the snapshot signature check mechanism with UEFI secure

Re: [PATCH 17/18] Hibernate: introduced SNAPSHOT_SIG_HASH config for select hash algorithm

On Thu 2013-08-22 19:01:56, Lee, Chun-Yi wrote: This patch introduced SNAPSHOT_SIG_HASH config for user to select which hash algorithm will be used during signature generation of snapshot. v2: Add define check of oCONFIG_SNAPSHOT_VERIFICATION in snapshot.c before declare pkey_hash().

Re: [RFC] Second attempt at kernel secure boot support

On Sun 2012-11-04 04:28:02, Matthew Garrett wrote: On Sat, Nov 03, 2012 at 10:56:40PM +, James Bottomley wrote: On Sat, 2012-11-03 at 13:46 +, Matthew Garrett wrote: I... what? Our signed bootloader will boot our signed kernel without any physically present end-user involvement.