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

On 6 April 2017 at 13:29, Alexei Starovoitov wrote: > 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

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

Sorry, I forgot to include a cover note. These five patches would replace 1-3 & 6 from my Kernel Lockdown series. The additional patch moves the secure boot switch from x86 to generic code. David -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

Hi Boris, On 03/17/2017 05:17 AM, Borislav Petkov wrote: On Thu, Mar 16, 2017 at 11:25:36PM +0100, Paolo Bonzini wrote: The kvmclock memory is initially zero so there is no need for the hypervisor to allocate anything; the point of these patches is just to access the data in a natural way from

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

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 --- arch/x86/kernel/setup.c| 14 +-

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

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 > private keys in kernel memory (e.g. the hibernation

[PATCH 2/5] efi: Add EFI_SECURE_BOOT bit

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, registered by the x86 arch, to find out whether

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

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 aren't validly signed with a key we recognise, fiddling with MSR

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

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: x...@kernel.org ---

Re: [PATCH V14 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64

Hi Rafael, On Tue, Mar 28, 2017 at 01:30:30PM -0600, Tyler Baicar wrote: > Tyler Baicar (9): > acpi: apei: read ack upon ghes record consumption > ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1 > efi: parse ARM processor error > arm64: exception: handle Synchronous

Re: [PATCH] arm64: xen: Implement EFI reset_system callback

[Adding the EFI maintainers] Tl;DR: Xen's EFI wrappery doesn't implement reset_system, so when invoked on arm64 we get a NULL dereference. On Thu, Apr 06, 2017 at 04:39:13PM +0100, Julien Grall wrote: > On 06/04/17 16:20, Daniel Kiper wrote: > >On Thu, Apr 06, 2017 at 04:38:24PM +0200, Juergen

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

Hi Brijesh, On Thu, Apr 06, 2017 at 09:05:03AM -0500, Brijesh Singh wrote: > I looked into arch/x86/mm/init_{32,64}.c and as you pointed the file contains > routines to do basic page splitting. I think it sufficient for our usage. Good :) > I should be able to drop the memblock patch from the

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

On 04/06/2017 12:25 PM, Borislav Petkov wrote: Hi Brijesh, On Thu, Apr 06, 2017 at 09:05:03AM -0500, Brijesh Singh wrote: I looked into arch/x86/mm/init_{32,64}.c and as you pointed the file contains routines to do basic page splitting. I think it sufficient for our usage. Good :) I

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

On Thu, 6 Apr 2017, Rafael J. Wysocki wrote: > >>> Your swap partition may be located on an NVDIMM or be encrypted. > >> > >> An NVDIMM should be considered the same as any other persistent storage. > >> > >> It may be encrypted, but where's the key stored, how easy is it to retrieve > >> and

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

On Wed, Apr 5, 2017 at 10:16 PM, 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 circumvent any restrictions imposed on > loading modules. Ignore the

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

On Thu, Apr 6, 2017 at 8:55 AM, David Howells wrote: > Rafael J. Wysocki wrote: > >> You probably want to disable hibernation altogether in this case. > > See patch 10. Does that mean patch 11 is superfluous? Yes, it does. You can't open /dev/snapshot

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

On Thu, Apr 6, 2017 at 10:09 PM, Rafael J. Wysocki wrote: > On Thu, Apr 6, 2017 at 10:41 AM, David Howells wrote: >> Oliver Neukum wrote: >> >>> Your swap partition may be located on an NVDIMM or be encrypted. >> >> An NVDIMM should be

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

On Thu, 6 Apr 2017, David Howells wrote: > James Morris wrote: > > > > +static __read_mostly bool kernel_locked_down; > > > > How about marking this __ro_after_init if ALLOW_LOCKDOWN_LIFT is not > > configured? > > I guess lock_kernel_down() would need to be __init also in

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

On Thu, 6 Apr 2017, 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 aren't validly

Re: [PATCH 00/24] Kernel lockdown

James Morris wrote: > > The patches can be found here also: > > > > > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lockdown > > > > Do you mean the branch 'efi-lock-down' ? Sorry, yes. David -- To unsubscribe from this list: send the

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

Rafael J. Wysocki wrote: > You probably want to disable hibernation altogether in this case. See patch 10. Does that mean patch 11 is superfluous? David -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to

Re: [PATCH 01/24] efi: Add EFI_SECURE_BOOT bit

Ard Biesheuvel wrote: > > @@ -1184,6 +1184,7 @@ void __init setup_arch(char **cmdline_p) > > pr_info("Secure boot disabled\n"); > > break; > > case efi_secureboot_mode_enabled: > > +

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

On Wed, 5 Apr 2017, David Howells wrote: > +#include > +#include > + > +static __read_mostly bool kernel_locked_down; How about marking this __ro_after_init if ALLOW_LOCKDOWN_LIFT is not configured? -- James Morris -- To unsubscribe from this list: send the line

[PATCH 4.9 58/72] x86/mm/KASLR: Exclude EFI region from KASLR VA space randomization

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Baoquan He commit a46f60d76004965e5669dbf3fc21ef3bc3632eb4 upstream. Currently KASLR is enabled on three regions: the direct mapping of physical memory, vamlloc and vmemmap.

[PATCH 4.10 65/81] x86/mm/KASLR: Exclude EFI region from KASLR VA space randomization

4.10-stable review patch. If anyone has any objections, please let me know. -- From: Baoquan He commit a46f60d76004965e5669dbf3fc21ef3bc3632eb4 upstream. Currently KASLR is enabled on three regions: the direct mapping of physical memory, vamlloc and vmemmap.

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

Oliver Neukum wrote: > Your swap partition may be located on an NVDIMM or be encrypted. An NVDIMM should be considered the same as any other persistent storage. It may be encrypted, but where's the key stored, how easy is it to retrieve and does the swapout code know this? >

Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

On 04/05/17 at 09:15pm, David Howells wrote: > From: Chun-Yi Lee > > When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image > through kexec_file systemcall if securelevel has been set. > > This code was showed in Matthew's patch but not in git: >

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

On 04/05/17 at 09:15pm, 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

Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set

On Fri, 2017-04-07 at 11:05 +0800, Dave Young wrote: > On 04/05/17 at 09:15pm, David Howells wrote: > > From: Chun-Yi Lee > > > > When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image > > through kexec_file systemcall if securelevel has been set. > > > >