Re: [PATCH 2/2 v3] efi: print appropriate status message when loading certificates

On Fri, May 03, 2019 at 04:23:51PM +0200, Ard Biesheuvel wrote: > On Fri, 3 May 2019 at 10:59, joeyli wrote: > > > > On Fri, May 03, 2019 at 10:07:59AM +0200, Ard Biesheuvel wrote: > > > On Fri, 3 May 2019 at 09:18, joeyli wrote: > > > > > > > > Hi

Re: [PATCH 2/2 v3] efi: print appropriate status message when loading certificates

On Fri, May 03, 2019 at 10:07:59AM +0200, Ard Biesheuvel wrote: > On Fri, 3 May 2019 at 09:18, joeyli wrote: > > > > Hi Ard, > > > > On Thu, May 02, 2019 at 11:04:34AM +0200, Ard Biesheuvel wrote: > > > On Thu, 2 May 2019 at 06:04, Lee, Chun-Yi wrote: >

Re: [PATCH 1/2 v2] efi: add a function to convert the status value to string

On Fri, May 03, 2019 at 08:16:42AM +0200, Ard Biesheuvel wrote: > On Fri, 3 May 2019 at 08:15, joeyli wrote: > > > > On Thu, May 02, 2019 at 10:53:31AM +0200, Ard Biesheuvel wrote: > > > On Thu, 2 May 2019 at 06:04, Lee, Chun-Yi wrote: > > > > > > &g

Re: [PATCH 1/2 v2] efi: add a function to convert the status value to string

On Thu, May 02, 2019 at 10:53:31AM +0200, Ard Biesheuvel wrote: > On Thu, 2 May 2019 at 06:04, Lee, Chun-Yi wrote: > > > > This function can be used to convert EFI status value to string > > for printing out debug message. Using this function can improve > > the readability of log. > > > > v2. >

Re: [PATCH 1/2] efi: add a function for transferring status to string

Hi Mimi, On Wed, Mar 27, 2019 at 03:04:02PM -0400, Mimi Zohar wrote: > On Wed, 2019-03-27 at 19:58 +0100, Ard Biesheuvel wrote: > > On Sun, 24 Mar 2019 at 01:26, Lee, Chun-Yi wrote: > > > > > > This function can be used to transfer EFI status code to string > > > for printing out debug message.

Re: [PATCH 1/2] efi: add a function for transferring status to string

Hi Ard, On Wed, Mar 27, 2019 at 07:58:03PM +0100, Ard Biesheuvel wrote: > On Sun, 24 Mar 2019 at 01:26, Lee, Chun-Yi wrote: > > > > This function can be used to transfer EFI status code to string > > for printing out debug message. Using this function can improve > > the readability of log. > >

Re: [PATCH 0/6][RFC] Add EFI secure key to key retention service

Hi James, On Sun, Aug 05, 2018 at 10:47:26AM -0700, James Bottomley wrote: > On Sun, 2018-08-05 at 09:25 +0200, Ard Biesheuvel wrote: > > Hello Chun,yi, > > > > On 5 August 2018 at 05:21, Lee, Chun-Yi > > wrote: > > > When secure boot is enabled, only signed EFI binary can access > > > EFI boot

Re: [PATCH 0/6][RFC] Add EFI secure key to key retention service

On Sun, Aug 05, 2018 at 09:25:56AM +0200, Ard Biesheuvel wrote: > Hello Chun,yi, > > On 5 August 2018 at 05:21, Lee, Chun-Yi wrote: > > When secure boot is enabled, only signed EFI binary can access > > EFI boot service variable before ExitBootService. Which means that > > the EFI boot service

Re: [PATCH 1/6] x86/KASLR: make getting random long number function public

Hi Ard, On Sun, Aug 05, 2018 at 10:16:03AM +0200, Ard Biesheuvel wrote: > On 5 August 2018 at 05:21, Lee, Chun-Yi wrote: > > Separating the functions for getting random long number from KASLR > > to x86 library, then it can be used to generate random long for > > EFI root key. > > > > Cc: Kees

Re: [PATCH] efi: Fix the size not consistent issue when unmapping memory map

Hi Ard, On Thu, May 03, 2018 at 02:05:51PM +0200, Ard Biesheuvel wrote: > On 2 May 2018 at 08:17, Lee, Chun-Yi wrote: > > When using kdump, SOMETIMES the "size not consistent" warning message > > shows up when the crash kernel boots with early_ioremap_debug parameter: >

Re: [PATCH] efi: Fix the size not consistent issue when unmapping memory map

On Mon, Apr 16, 2018 at 06:35:22PM -0600, Randy Wright wrote: > On Mon, Apr 16, 2018 at 02:37:38PM +0800, joeyli wrote: > > Hi Randy, > > ... > > Randy, do you want to try Dave's kexec patch on your environment? Please > > remove > > my patch first. > >

Re: [PATCH] efi: Fix the size not consistent issue when unmapping memory map

Hi Randy, On Mon, Apr 16, 2018 at 11:09:04AM +0800, Dave Young wrote: > On 04/16/18 at 10:57am, Dave Young wrote: > > On 04/13/18 at 02:27pm, Lee, Chun-Yi wrote: > > > When using kdump, SOMETIMES the "size not consistent" warning message > > > shows up when the crash kernel boots with

Re: [PATCH] efi: Fix the size not consistent issue when unmapping memory map

On Mon, Apr 16, 2018 at 10:57:34AM +0800, Dave Young wrote: > On 04/13/18 at 02:27pm, Lee, Chun-Yi wrote: > > When using kdump, SOMETIMES the "size not consistent" warning message > > shows up when the crash kernel boots with early_ioremap_debug parameter: > > > > WARNING: CPU: 0 PID: 0 at

Re: [GIT PULL] Kernel lockdown for secure boot

On Sun, Apr 08, 2018 at 08:40:10PM -0700, Alexei Starovoitov wrote: > On Sun, Apr 08, 2018 at 04:07:42PM +0800, joeyli wrote: > > > > > If the only thing that folks are paranoid about is reading > > > arbitrary kernel memory with bpf_probe_read() helper >

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 03, 2018 at 07:34:25PM -0700, Alexei Starovoitov wrote: > On Tue, Apr 3, 2018 at 9:26 AM, Andy Lutomirski wrote: > > On Tue, Apr 3, 2018 at 8:41 AM, Alexei Starovoitov > > wrote: > >> On Tue, Apr 03, 2018 at 08:11:07AM -0700, Andy

Re: [GIT PULL] Kernel lockdown for secure boot

and EVM. There have another idea is using a tree to register all sensitive data then blanking them when reading. Here is a very early developing version: https://github.com/joeyli/linux-sensitive_data/commits/sensitive-data-tree-v0.1-v4.15 But this approach causes runtime overhead and all sensiti

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

Hi David, On Wed, Apr 04, 2018 at 05:17:24PM +0100, David Howells wrote: > Andy Lutomirski wrote: > > > Since this thread has devolved horribly, I'm going to propose a solution. > > > > 1. Split the "lockdown" state into three levels: (please don't > > bikeshed about the

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

On Wed, Apr 04, 2018 at 11:19:27PM +0100, David Howells wrote: > Jann Horn wrote: > > > > Uh, no. bpf, for example, can be used to modify kernel memory. > > > > I'm pretty sure bpf isn't supposed to be able to modify arbitrary > > kernel memory. AFAIU if you can use BPF to

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

Hi Andy, On Wed, Apr 04, 2018 at 07:49:12AM -0700, Andy Lutomirski wrote: > Since this thread has devolved horribly, I'm going to propose a solution. ... > 6. There's a way to *decrease* the lockdown level below the configured > value. (This ability itself may be gated by a config option.) >

Re: [PATCH 0/9] KEYS: Blacklisting & UEFI database load

Hi Mimi, On Mon, Mar 19, 2018 at 10:12:03AM -0400, Mimi Zohar wrote: > On Sun, 2018-03-11 at 11:20 +0800, joeyli wrote: > > On Wed, Mar 07, 2018 at 07:28:37AM -0800, James Bottomley wrote: > > > On Wed, 2018-03-07 at 08:18 -0500, Mimi Zohar wrote: > > > > On Tue, 2

Re: [PATCH 4/5] MODSIGN: checking the blacklisted hash before loading a kernel module

On Thu, Mar 15, 2018 at 07:30:26AM -0700, James Bottomley wrote: > On Thu, 2018-03-15 at 14:16 +0800, joeyli wrote: > > On Wed, Mar 14, 2018 at 07:19:25AM -0700, James Bottomley wrote: > > > > > > On Wed, 2018-03-14 at 14:08 +0800, joeyli wrote: > > > > >

Re: [PATCH 4/5] MODSIGN: checking the blacklisted hash before loading a kernel module

On Wed, Mar 14, 2018 at 07:19:25AM -0700, James Bottomley wrote: > On Wed, 2018-03-14 at 14:08 +0800, joeyli wrote: > > On Tue, Mar 13, 2018 at 10:18:35AM -0700, James Bottomley wrote: > > > > > > On Tue, 2018-03-13 at 18:38 +0800, Lee, Chun-Yi wrote: > > >

Re: [PATCH 1/5] MODSIGN: do not load mok when secure boot disabled

Hi Ard, First! Thanks for your review! On Tue, Mar 13, 2018 at 05:25:30PM +, Ard Biesheuvel wrote: > On 13 March 2018 at 10:37, Lee, Chun-Yi wrote: > > The mok can not be trusted when the secure boot is disabled. Which > > means that the kernel embedded certificate

Re: [PATCH 4/5] MODSIGN: checking the blacklisted hash before loading a kernel module

On Tue, Mar 13, 2018 at 10:18:35AM -0700, James Bottomley wrote: > On Tue, 2018-03-13 at 18:38 +0800, Lee, Chun-Yi wrote: > > This patch adds the logic for checking the kernel module's hash > > base on blacklist. The hash must be generated by sha256 and enrolled > > to dbx/mokx. > > > > For

Re: [PATCH 2/5] MODSIGN: print appropriate status message when getting UEFI certificates list

Hi James, Thanks for your review. On Tue, Mar 13, 2018 at 10:17:50AM -0700, James Bottomley wrote: > On Tue, 2018-03-13 at 18:35 +0800, Lee, Chun-Yi wrote: > > When getting certificates list from UEFI variable, the original error > > message shows the state number from UEFI firmware. It's hard

Re: [PATCH 0/9] KEYS: Blacklisting & UEFI database load

On Wed, Mar 07, 2018 at 07:28:37AM -0800, James Bottomley wrote: > On Wed, 2018-03-07 at 08:18 -0500, Mimi Zohar wrote: > > On Tue, 2018-03-06 at 15:05 +0100, Jiri Slaby wrote: > > > what's the status of this please? Distributors (I checked SUSE, > > > RedHat and Ubuntu) have to carry these

Re: [PATCH 1/4] MODSIGN: do not load mok when secure boot disabled

Hi James, First, thank you for reviewing and comment! On Thu, Nov 30, 2017 at 07:51:03AM -0800, James Bottomley wrote: > On Wed, 2017-11-29 at 22:11 +0800, Lee, Chun-Yi wrote: > > The mok can not be trusted when the secure boot is disabled. Which > > means that the kernel embedded certificate

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

On Fri, Oct 27, 2017 at 03:32:26PM -0400, Mimi Zohar wrote: > On Thu, 2017-10-26 at 10:17 -0400, Mimi Zohar wrote: > > On Thu, 2017-10-26 at 15:42 +0800, joeyli wrote: > > > Hi Mimi, > > > > > > Thank you for reviewing. > > > > > > On M

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

Hi Mimi, Thank you for reviewing. On Mon, Oct 23, 2017 at 11:54:43AM -0400, Mimi Zohar wrote: > On Thu, 2017-10-19 at 15:51 +0100, David Howells wrote: > > From: Chun-Yi Lee > > > > When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image > > through

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

Hi David, On Mon, Oct 23, 2017 at 03:49:44PM +0100, David Howells wrote: > Alan Cox wrote: > > > There are a load of standard tools that use this so I think you are going > > to need a whitelist. Can you at least log *which* MSR in the failing case > > so a

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

On Mon, Oct 23, 2017 at 03:53:00PM +0100, David Howells wrote: > j...@suse.com wrote: > > > hm... patch 4 only prevents write_mem() but not read_mem(). > > Or I missed anything? > > Actually, yes, as it happens, patch 11 prevents you from even opening /dev/mem > and /dev/kmem by locking down

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

On Fri, Oct 20, 2017 at 09:48:16PM +0100, David Howells wrote: > Alan Cox wrote: > > > There are a load of standard tools that use this so I think you are going > > to need a whitelist. Can you at least log *which* MSR in the failing case > > so a whitelist can be

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

On Thu, Oct 19, 2017 at 03:52:41PM +0100, David Howells wrote: > 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

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

On Thu, Oct 19, 2017 at 03:52:34PM +0100, David Howells wrote: > 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

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

On Thu, Oct 19, 2017 at 03:52:27PM +0100, David Howells wrote: > 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

Re: [PATCH 13/27] asus-wmi: Restrict debugfs interface when the kernel is locked down

On Thu, Oct 19, 2017 at 03:52:11PM +0100, David Howells wrote: > From: Matthew Garrett > > We have no way of validating what all of the Asus WMI methods do on a given > machine - and there's a risk that some will allow hardware state to be > manipulated in such a way

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

On Thu, Oct 19, 2017 at 03:52:04PM +0100, David Howells wrote: > 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. > >

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

On Thu, Oct 19, 2017 at 03:51:56PM +0100, David Howells wrote: > 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

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

On Thu, Oct 19, 2017 at 03:51:49PM +0100, David Howells wrote: > 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

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

On Thu, Oct 19, 2017 at 03:51:34PM +0100, David Howells wrote: > 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

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

On Thu, Oct 19, 2017 at 03:51:20PM +0100, David Howells wrote: > 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

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

On Thu, Oct 19, 2017 at 03:51:09PM +0100, David Howells wrote: > From: Matthew Garrett > > kexec 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 in this

Re: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down

Hi David, Thanks for you send out this series. On Thu, Oct 19, 2017 at 03:51:02PM +0100, David Howells wrote: > From: Matthew Garrett > > Allowing users to write to address space makes it possible for the kernel to > be subverted, avoiding module loading

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

Hi David, Thanks for you send our this series. On Thu, Oct 19, 2017 at 03:50:55PM +0100, David Howells wrote: > If the kernel is locked down, require that all modules have valid > signatures that we can verify. > > Signed-off-by: David Howells I have reviewed and tested

Re: Draft manpage explaining kernel lockdown

Hi David, On Thu, Oct 05, 2017 at 12:00:24PM +0100, David Howells wrote: > Hi Ard, Michael, > > 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

Re: [PATCH 5/5] Add a sysrq option to exit secure boot mode

Hi, On Wed, May 24, 2017 at 03:46:03PM +0100, David Howells wrote: > From: Kyle McMartin > > Make sysrq+x exit secure boot mode on x86_64, thereby allowing the running > kernel image to be modified. This lifts the lockdown. > > Signed-off-by: Kyle McMartin >

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

On Fri, May 26, 2017 at 01:43:12PM +0100, David Howells wrote: > Casey Schaufler wrote: > > > You called out five distinct features in 0/5, so how about > > a bit for each of those? > > Actually, there are more than five in that list - there are three in the first > item

Re: [PATCH 4/5] efi: Lock down the kernel if booted in secure boot mode

On Wed, May 24, 2017 at 03:45:56PM +0100, David Howells wrote: > UEFI Secure Boot provides a mechanism for ensuring that the firmware will > only load signed bootloaders and kernels. Certain use cases may also > require that all kernel modules also be signed. Add a configuration option > that to

Re: [PATCH 3/5] Add the ability to lock down access to the running kernel image

On Wed, May 24, 2017 at 03:45:45PM +0100, David Howells wrote: > 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

Re: [PATCH 2/5] efi: Add EFI_SECURE_BOOT bit

On Wed, May 24, 2017 at 03:45:32PM +0100, David Howells wrote: > From: Josh Boyer > > UEFI machines can be booted in Secure Boot mode. Add a EFI_SECURE_BOOT bit > that can be passed to efi_enabled() to find out whether secure boot is > enabled. > > This will be used

Re: [PATCH 1/5] efi: Move the x86 secure boot switch to generic code

Hi David, On Wed, May 24, 2017 at 03:45:25PM +0100, David Howells wrote: > Move the switch-statement in x86's setup_arch() that inteprets the > secure_boot boot parameter to generic code. > > Suggested-by: Ard Biesheuvel > Signed-off-by: David Howells

Re: [PATCH v2] x86/efi: Disable runtime services on kexec kernel if booted with efi=old_map

On Tue, May 16, 2017 at 06:14:23PM -0700, Sai Praneeth Prakhya wrote: > From: Sai Praneeth > > Booting kexec kernel with "efi=old_map" in kernel command line hits > kernel panic as shown below. > > [0.001000] BUG: unable to handle kernel paging request at

Re: [PATCH] x86/efi: Fix kexec kernel panic when efi=old_map is enabled

On Mon, May 08, 2017 at 12:25:23PM -0700, Sai Praneeth Prakhya wrote: > From: Sai Praneeth > > Booting kexec kernel with "efi=old_map" in kernel command line hits > kernel panic as shown below. > > [0.001000] BUG: unable to handle kernel paging request at

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

Hi David, First, thanks for your help to send out this series. On Wed, Apr 05, 2017 at 09:17:25PM +0100, David Howells wrote: > From: Chun-Yi Lee > > There are some bpf functions can be used to read kernel memory: > bpf_probe_read, bpf_probe_write_user and bpf_trace_printk.

Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down

sure how the hibernate > >>> code can verify whether or not it is in use. > >> > >> BTW, SUSE has patches adding secure boot support to the hibernate code > >> and Jiri promised me to post them last year even. :-) > > > > Oh, thanks for a friendly pin

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

On Wed, Sep 09, 2015 at 01:15:45PM +0100, Matt Fleming wrote: > On Thu, 27 Aug, at 05:04:52PM, joeyli wrote: > > > > The purpose of checking attribute of hibernation key variable is > > in case someone created a key variable on runtime environment _before_ > > this

Re: [PATCH v2 09/16] PM / hibernate: Reserve hibernation key and erase footprints

On Wed, Sep 09, 2015 at 01:24:08PM +0100, Matt Fleming wrote: > On Thu, 27 Aug, at 06:21:44PM, joeyli wrote: > > On Fri, Aug 21, 2015 at 02:27:53PM +0100, Matt Fleming wrote: > > > On Tue, 11 Aug, at 02:16:29PM, Lee, Chun-Yi wrote: > > > > +static int __i

Re: [PATCH] x86/efi: Map EFI memmap entries in-order at runtime

Hi, On Wed, Sep 09, 2015 at 12:21:23PM +0100, Matt Fleming wrote: > On Wed, 09 Sep, at 08:33:07AM, joeyli wrote: > > > > Yes, the machine on my hand has EFI_PROPERTIES_TABLE enabled, and it doesn't > > boot without your patch. > > Awesome. Could you test

Re: [PATCH] x86/efi: Map EFI memmap entries in-order at runtime

Hi Matt, On Tue, Sep 08, 2015 at 09:41:47PM +0100, Matt Fleming wrote: > On Mon, 07 Sep, at 12:07:52PM, joeyli wrote: > > > > This patch works to me on Intel S1200V3RPS to fix issue: > > DMI: Intel Corporation (uefidk.com) Intel Server Board S1200V3RPS UEFI > > Devel

Re: [PATCH] x86/efi: Map EFI memmap entries in-order at runtime

Hi, On Fri, Sep 04, 2015 at 02:14:07PM +0100, Matt Fleming wrote: > From: Matt Fleming > > Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced that > signals that the firmware PE/COFF loader supports splitting code and > data sections of PE/COFF images into

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

On Thu, Aug 20, 2015 at 09:26:20PM +0100, Matt Fleming wrote: On Tue, 11 Aug, at 02:16:25PM, Lee, Chun-Yi wrote: + +static unsigned long efi_get_rng64(efi_system_table_t *sys_table, + void **rng_handle) +{ + const struct efi_config *efi_early =

Re: [PATCH v2 09/16] PM / hibernate: Reserve hibernation key and erase footprints

On Fri, Aug 21, 2015 at 02:27:53PM +0100, Matt Fleming wrote: On Tue, 11 Aug, at 02:16:29PM, Lee, Chun-Yi wrote: Add handler to parse the setup data that carrying hibernation key, it reserves hibernation key by memblock then copies key to a allocated page in later initcall stage. And

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

On Thu, Aug 20, 2015 at 09:40:44PM +0100, Matt Fleming wrote: On Tue, 11 Aug, at 02:16:26PM, Lee, Chun-Yi wrote: This patch adds codes in EFI stub for generating and storing the HMAC key in EFI boot service variable for signing hibernate image. Per rcf2104, the length of HMAC-SHA1 hash

Re: [PATCH v2 07/16] efi: Make efi_status_to_err() public

On Thu, Aug 20, 2015 at 04:07:06PM +0100, Matt Fleming wrote: On Tue, 11 Aug, at 02:16:27PM, Lee, Chun-Yi wrote: Moved the function of transferring EFI status to kernel error for later used by EFI stub. Might I suggest: Move the function for converting EFI status to kernel error

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

On Fri, Aug 21, 2015 at 01:40:26PM +0100, Matt Fleming wrote: On Tue, 11 Aug, at 02:16:28PM, 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. This could do

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

On Thu, Aug 20, 2015 at 03:47:06PM +0100, Matt Fleming wrote: On Tue, 11 Aug, at 02:16:25PM, 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

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

Hi Matt, Thanks for your reviewing and sorry for my delay. On Thu, Aug 20, 2015 at 03:12:21PM +0100, Matt Fleming wrote: On Tue, 11 Aug, at 02:16:24PM, Lee, Chun-Yi wrote: This patch adds the codes for generating random number array as the HMAC key that will used by later EFI stub codes.

Re: [PATCH] x86_64/efi: Mapping Boot and Runtime EFI memory regions to different starting virtual address

On Wed, Aug 19, 2015 at 05:31:45PM +0100, Matt Fleming wrote: On Thu, 30 Jul, at 10:16:01PM, joeyli wrote: Thanks for your explanation. For my issue, I will check if rewriting the VA of runtime services can fix issue. If not, then I think need find a way to sync the mapping in EFI

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

On Sat, Aug 15, 2015 at 07:07:38PM +0200, Pavel Machek wrote: 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:

Re: [PATCH v2 09/16] PM / hibernate: Reserve hibernation key and erase footprints

On Tue, Aug 11, 2015 at 02:16:29PM +0800, Lee, Chun-Yi wrote: Add handler to parse the setup data that carrying hibernation key, it reserves hibernation key by memblock then copies key to a allocated page in later initcall stage. [...snip] diff --git a/arch/x86/power/hibernate_keys.c

Re: [PATCH v2 09/16] PM / hibernate: Reserve hibernation key and erase footprints

Hi Yu, Thanks for your reviewing. On Thu, Aug 13, 2015 at 02:45:32AM +, Chen, Yu C wrote: Hi Chun-yi, On Tue, 2015-08-11 at 14:16 +0800, Lee, Chun-Yi wrote: +/* A page used to keep hibernation keys */ +static struct hibernation_keys *hibernation_keys; + +void __init

Re: [RFC PATCH 07/16] efi: Public the function of transferring EFI status to kernel error

On Thu, Jul 30, 2015 at 05:23:22PM +0100, Matt Fleming wrote: On Thu, 2015-07-16 at 22:25 +0800, Lee, Chun-Yi wrote: Moved the function of transferring EFI status to kernel error for later used by EFI stub. Signed-off-by: Lee, Chun-Yi j...@suse.com --- drivers/firmware/efi/vars.c |

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

On Fri, Jul 31, 2015 at 10:59:12PM +0800, joeyli wrote: On Thu, Jul 30, 2015 at 05:11:44PM +0100, Matt Fleming wrote: On Thu, 2015-07-16 at 22:25 +0800, 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

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

On Fri, Jul 31, 2015 at 02:49:36PM +0200, Pavel Machek wrote: 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

Re: [RFC PATCH 08/16] x86/efi: Carrying swsusp key by setup data

On Thu, Jul 30, 2015 at 05:30:09PM +0100, Matt Fleming wrote: On Thu, 2015-07-16 at 22:25 +0800, Lee, Chun-Yi wrote: For forwarding swsusp key from EFI stub to boot kernel, this patch allocates setup data for carrying swsusp key, size and the status of efi operating. Signed-off-by:

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

On Tue, Jul 28, 2015 at 02:35:23PM +0200, Pavel Machek wrote: Typo in patch subject. And for earsing footbprints, the codes in this patch remove setup And two typos here. Sorry for subject and above typos, I will fix it. Thanks. data that carried swsusp key, and clean the memory

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

On Fri, Jul 31, 2015 at 01:01:18PM +0100, Matt Fleming wrote: On Fri, 2015-07-31 at 17:58 +0800, joeyli wrote: Can you do something to avoid each function having two very similar versions of these functions? They are similar but I want follow the style in eboot.c. On the other

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

On Thu, Jul 30, 2015 at 05:20:46PM +0100, Matt Fleming wrote: On Thu, 2015-07-16 at 22:25 +0800, Lee, Chun-Yi wrote: This patch adds codes in EFI stub for generating and storing the HMAC key in EFI boot service variable for signing hibernate image. Per rcf2104, the length of HMAC-SHA1

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

Hi Pavel, Thanks for your review. On Tue, Jul 28, 2015 at 02:01:12PM +0200, Pavel Machek wrote: 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

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

On Tue, Jul 28, 2015 at 02:30:26PM +0200, Pavel Machek wrote: 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. Sorry for I didn't remove

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

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), this size will be also applied to the length of

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

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 for global function... This i8254 function only used by aslr

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

On Tue, Jul 28, 2015 at 02:28:53PM +0200, Pavel Machek wrote: 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

Re: [RFC PATCH 02/16] x86/efi: Add get and set variable to EFI services pointer table

On Thu, Jul 30, 2015 at 04:19:58PM +0100, Matt Fleming wrote: On Thu, 2015-07-16 at 22:25 +0800, Lee, Chun-Yi wrote: Add get variable and set variable function to EFI services pointer table for supporting later functions of hibernate signature verification to keep the HMAC key in efi boot

Re: [PATCH] x86_64/efi: Mapping Boot and Runtime EFI memory regions to different starting virtual address

On Thu, Jul 30, 2015 at 01:09:16PM +0100, Matt Fleming wrote: On Thu, 30 Jul, at 07:18:19PM, joeyli wrote: In the above case, just simply accessing EFI variable through efivars to reproduce issue: linux-aiip:~ # hexdump -C /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2

Re: [PATCH] x86_64/efi: Mapping Boot and Runtime EFI memory regions to different starting virtual address

On Thu, Jul 30, 2015 at 02:17:23PM +0100, Matt Fleming wrote: On Thu, 30 Jul, at 08:31:16PM, joeyli wrote: I think hibernate overwrite it. We absolutely must get a more detailed answer before going any further. Simply put, if we're remapping the EFI regions into the virtual address

Re: [PATCH] x86_64/efi: Mapping Boot and Runtime EFI memory regions to different starting virtual address

On Thu, Jul 30, 2015 at 03:05:42PM +0100, Matt Fleming wrote: On Thu, 30 Jul, at 09:39:47PM, joeyli wrote: OK, understood! Thanks for your suggestion! But, I have a question about mapping Boot Code/Data to -4G area. I understand we need Runtime regions, and 1:1 mapping

Re: [PATCH] x86_64/efi: Mapping Boot and Runtime EFI memory regions to different starting virtual address

On Thu, Jul 30, 2015 at 11:11:31AM +0100, Matt Fleming wrote: On Thu, 30 Jul, at 10:03:23AM, Borislav Petkov wrote: On Thu, Jul 30, 2015 at 12:53:42AM -0700, H. Peter Anvin wrote: This changelog is at least partially incomprehensive. It also seems more than a bit aggressive to expect that

Re: [PATCH] x86_64/efi: Mapping Boot and Runtime EFI memory regions to different starting virtual address

On Thu, Jul 30, 2015 at 07:09:59PM +0800, joeyli wrote: On Thu, Jul 30, 2015 at 11:11:31AM +0100, Matt Fleming wrote: On Thu, 30 Jul, at 10:03:23AM, Borislav Petkov wrote: On Thu, Jul 30, 2015 at 12:53:42AM -0700, H. Peter Anvin wrote: This changelog is at least partially incomprehensive

Re: [PATCH v3 1/8] x86: Kill E820_RESERVED_KERN

On Sat, Mar 07, 2015 at 05:59:14PM -0800, David Rientjes wrote: On Sat, 7 Mar 2015, Yinghai Lu wrote: Now we are using memblock to do early resource reserver/allocation instead of using e820 map directly, and setup_data is reserved in memblock early already. Also kexec generate

Re: [PATCH v2 04/15] x86, kaslr: get kaslr_enabled back correctly

Hi Yinghai, On Wed, Mar 04, 2015 at 10:12:58AM -0800, Yinghai Lu wrote: On Wed, Mar 4, 2015 at 7:54 AM, Jiri Kosina jkos...@suse.cz wrote: Also this 15-patch series needs to be separated into two patchsets. The whole series is not appropriate for -rc3, but this particular one at least

Re: [PATCH] x86/efi: autoload efivars

On Tue, Jul 08, 2014 at 01:19:42PM +0100, Ben Hutchings wrote: On Tue, 2014-07-08 at 11:14 +0100, Matt Fleming wrote: On Tue, 08 Jul, at 11:00:58AM, Lee, Chun-Yi wrote: [...] --- a/arch/x86/platform/efi/efi.c +++ b/arch/x86/platform/efi/efi.c @@ -44,6 +44,7 @@ #include linux/io.h

Re: [RFT][PATCH] ACPI / init: Run acpi_early_init() before efi_enter_virtual_mode()

於 二，2014-01-14 於 13:32 -0700，Toshi Kani 提到： + acpi_early_init(); timekeeping_init(); time_init(); sched_clock_postinit(); @@ -641,7 +642,6 @@ asmlinkage void __init start_kernel(void) check_bugs(); - acpi_early_init(); /*

Re: [RFC PATCH 04/14] ACPI: Add ACPI 5.0 Time and Alarm Device driver

於 三，2014-01-08 於 09:56 -0800，H. Peter Anvin 提到： [...] Document of Windows XP: http://www.freelists.org/post/windows_errors/what-error-messages-really-mean-WinXP-IO-Ports-Blocked-from-Bios-AML-on-Windows-XP If just for ACPI TAD testing, we can remove the port protection check of RTC

Re: [RFC PATCH 04/14] ACPI: Add ACPI 5.0 Time and Alarm Device driver

於 一，2014-01-06 於 21:37 -0800，H. Peter Anvin 提到： On 01/06/2014 12:58 AM, joeyli wrote: 於 二，2013-12-31 於 16:42 -0800，H. Peter Anvin 提到： On 12/19/2013 09:41 PM, joeyli wrote: What platform do you have that has TAD support? I am wondering how this was tested. It's a testing platform

Re: [RFC PATCH 04/14] ACPI: Add ACPI 5.0 Time and Alarm Device driver

於 二，2013-12-31 於 16:42 -0800，H. Peter Anvin 提到： On 12/19/2013 09:41 PM, joeyli wrote: What platform do you have that has TAD support? I am wondering how this was tested. It's a testing platform that's only support get/set time functions of ACPI TAD. It would be really

Re: [RFC PATCH 04/14] ACPI: Add ACPI 5.0 Time and Alarm Device driver

於 四，2014-01-02 於 16:09 +0800，Lan Tianyu 提到： diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index bba9b72..3f7a075 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -689,6 +689,9 @@ static int __init acpi_init(void) pci_mmcfg_late_init();

Re: [RFC PATCH 06/14] rtc-efi: register rtc-efi device when EFI enabled

於 五，2013-12-20 於 17:51 -0800，H. Peter Anvin 提到： On 12/20/2013 05:24 PM, joeyli wrote: 於 五，2013-12-20 於 13:04 -0800，H. Peter Anvin 提到： Actually, it doesn't have to reprogram the clock ... it just needs to know if another OS has already done so. All Linux needs to do is to be able

Re: [PATCH 03/14] rtc: block registration of rtc-cmos when CMOS RTC Not Present

Hi hpa, 於 四，2013-12-19 於 06:38 -0800，H. Peter Anvin 提到： Where did you find a platform with no CMOS set and a PNP RTC? I find the expect behavior in that case to be quite ambiguous and it is not at all clear to me that what you have here is the right thing. Actually there doesn't have the

Re: [RFC PATCH 06/14] rtc-efi: register rtc-efi device when EFI enabled

於 四，2013-12-19 於 14:09 +，Matt Fleming 提到： On Thu, 19 Dec, at 03:51:47PM, Lee, Chun-Yi wrote: UEFI time services, GetTime(), SetTime(), GetWakeupTime(), SetWakeupTime() are also supported by other non-IA64 architecutre with UEFI BIOS, e.g. x86. This patch changed RTC_DRV_EFI

  1   2   >