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
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:
>
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
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:
> >
> > When loading certificates list from UEFI variable, the original error
> > message direct shows the efi status code from UEFI firmware. It looks
> > ugly:
> >
> > [
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.
>
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. U
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.
> >
>
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
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 va
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 Co
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:
> >
> > WARNING: CPU: 0 PID:
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.
>
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 early_iorema
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 ../mm/e
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
> > &
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 Lutomirski wrote:
> >>> >
> >>> >> "bpf: Restrict kern
s
KMK 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 a
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 names right now.)
> >
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 write to arbitrary ke
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.)
> Choi
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
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:
> > > >
>
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:
> > >
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 is the only trusted key.
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 exampl
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 to
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 patches
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 is
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
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 kexec_file systemcall if securele
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 whitelist can be built over time ?
>
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 open
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 built over time ?
>
[...snip]
>
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 specification 5.0 and later
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 BIOS with an
>
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 down.
>
> Signed-off
On Thu, Oct 19, 2017 at 03:52:19PM +0100, David Howells wrote:
> From: Matthew Garrett
>
> custom_method effectively allows arbitrary access to system memory, making
> it possible for an attacker to circumvent restrictions on module loading.
> Disable it if the kernel is locked down.
>
> Signed-
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 that arbitrary code can be ex
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.
>
> Signed-off-by: Matthew Garrett
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 potentially permit root to trigger ar
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 disabled module loading or mod
On Thu, Oct 19, 2017 at 03:51:42PM +0100, David Howells wrote:
> From: Matthew Garrett
>
> uswsusp allows a user process to dump and then restore kernel state, which
> makes it possible to modify the running kernel. Disable this if the kernel
> is locked down.
>
> Signed-off-by: Matthew Garrett
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 hibernate images we disable it when
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 missing the protect
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 situation.
>
> This does not affect k
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 restrictions. Prevent this when the
> k
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 this patch. Please feel
Hi Alexei,
Thanks for your review!
On Thu, Oct 19, 2017 at 03:18:30PM -0700, Alexei Starovoitov wrote:
> On Thu, Oct 19, 2017 at 03:52:49PM +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_wr
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 tri
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
> Signed-off-by: David Howells
> cc
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 - and I'm not sure the r
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
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 that
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 by the SysRq+x handler, regi
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
I reviewed the context for this patch.
Re
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 88007fe78070
> [0.001000] IP: virt_e
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 88007fe78070
> [0.001000] IP
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. These allow
> priva
ry and I'm not 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,
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
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
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
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
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 separate EFI memory map entr
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.
> >
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
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 er
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-SHA
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 = _
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
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 code
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, t
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.
> >
> > Revie
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 b/a
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 pa
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?
> > >
> >
> &
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
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 mem
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-o
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
> > ---
> > drivers/firmware/efi/vars.c | 3
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
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
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 for accessing EFI RNG
> > (random number generator) prot
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'
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 onl
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
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
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 th
Hi Matt,
Thanks for your review!
On Thu, Jul 30, 2015 at 04:37:42PM +0100, Matt Fleming wrote:
> On Thu, 2015-07-16 at 22:25 +0800, 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.
> >
> > The origin
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
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
> > w
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
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/f
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 c
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 exp
Hi Jiri,
On Fri, Jul 24, 2015 at 07:08:18PM +0200, Jiri Kosina wrote:
> On Thu, 16 Jul 2015, Lee, Chun-Yi wrote:
>
> > This patchset is the implementation of signature verification of hibernate
> > snapshot image. The origin idea is from Jiri Kosina: Let EFI bootloader
> > generate key-pair in UE
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
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 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
> > is a r
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 @@
> > > #incl
於 二，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();
> > >
> > > -
1 - 100 of 216 matches
Mail list logo
