Re: [PATCH 00/24] Kernel lockdown

[Justin Forbes]

On Wed, Apr 5, 2017 at 12:07 PM, David Howells  wrote:
>
> These patches provide a facility by which a variety of avenues by which
> userspace can feasibly modify the running kernel image can be locked down.
> These include:
>
>  (*) No unsigned modules and no modules for which can't validate the
>  signature.
>
>  (*) No use of ioperm(), iopl() and no writing to /dev/port.
>
>  (*) No writing to /dev/mem or /dev/kmem.
>
>  (*) No hibernation.
>
>  (*) Restrict PCI BAR access.
>
>  (*) Restrict MSR access.
>
>  (*) No kexec_load().
>
>  (*) Certain ACPI restrictions.
>
>  (*) Restrict debugfs interface to ASUS WMI.
>
> The lock-down can be configured to be triggered by the EFI secure boot
> status, provided the shim isn't insecure.  The lock-down can be lifted by
> typing SysRq+x on a keyboard attached to the system.
>
>
> The patches can be found here also:
>
> 
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lockdown
>
> They are dependent on the hwparam branch, which I posted separately.
>
> David
> ---
> Dave Young (1):
>   Copy secure_boot flag in boot params across kexec reboot
>
> David Howells (7):
>   Add the ability to lock down access to the running kernel image
>   efi: Lock down the kernel if booted in secure boot mode
>   Enforce module signatures if the kernel is locked down
>   scsi: Lock down the eata driver
>   Prohibit PCMCIA CIS storage when the kernel is locked down
>   Lock down TIOCSSERIAL
>   Lock down module params that specify hardware parameters (eg. ioport)
>
> Josh Boyer (3):
>   efi: Add EFI_SECURE_BOOT bit
>   hibernate: Disable when the kernel is locked down
>   acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down
>
> Kyle McMartin (1):
>   Add a sysrq option to exit secure boot mode
>
> Lee, Chun-Yi (2):
>   kexec_file: Disable at runtime if securelevel has been set
>   bpf: Restrict kernel image access functions when the kernel is locked 
> down
>
> Linn Crosetto (2):
>   acpi: Disable ACPI table override if the kernel is locked down
>   acpi: Disable APEI error injection if the kernel is locked down
>
> Matthew Garrett (8):
>   Restrict /dev/mem and /dev/kmem when the kernel is locked down
>   kexec: Disable at runtime if the kernel is locked down
>   uswsusp: Disable when the kernel is locked down
>   PCI: Lock down BAR access when the kernel is locked down
>   x86: Lock down IO port access when the kernel is locked down
>   x86: Restrict MSR access when the kernel is locked down
>   asus-wmi: Restrict debugfs interface when the kernel is locked down
>   ACPI: Limit access to custom_method when the kernel is locked down
>
>
>  arch/x86/Kconfig  |   22 
>  arch/x86/kernel/ioport.c  |4 ++--
>  arch/x86/kernel/kexec-bzimage64.c |1 +
>  arch/x86/kernel/msr.c |7 ++
>  arch/x86/kernel/setup.c   |   40 
> -
>  drivers/acpi/apei/einj.c  |3 +++
>  drivers/acpi/custom_method.c  |3 +++
>  drivers/acpi/osl.c|2 +-
>  drivers/acpi/tables.c |5 +
>  drivers/char/mem.c|8 +++
>  drivers/input/misc/uinput.c   |1 +
>  drivers/pci/pci-sysfs.c   |9 
>  drivers/pci/proc.c|8 ++-
>  drivers/pci/syscall.c |2 +-
>  drivers/pcmcia/cistpl.c   |5 +
>  drivers/platform/x86/asus-wmi.c   |9 
>  drivers/scsi/eata.c   |7 ++
>  drivers/tty/serial/serial_core.c  |6 ++
>  drivers/tty/sysrq.c   |   19 --
>  include/linux/efi.h   |1 +
>  include/linux/input.h |5 +
>  include/linux/kernel.h|9 
>  include/linux/security.h  |   11 ++
>  include/linux/sysrq.h |8 ++-
>  kernel/debug/kdb/kdb_main.c   |2 +-
>  kernel/kexec.c|7 ++
>  kernel/kexec_file.c   |6 ++
>  kernel/module.c   |2 +-
>  kernel/params.c   |   27 -
>  kernel/power/hibernate.c  |2 +-
>  kernel/power/user.c   |3 +++
>  kernel/trace/bpf_trace.c  |   11 ++
>  security/Kconfig  |   15 ++
>  security/Makefile |3 +++
>  security/lock_down.c  |   40 
> +
>  35 files changed, 291 insertions(+), 22 deletions(-)
>  create mode 100644 security/lock_down.c
>

Tested-by: Justin Forbes 

Re: [PATCH 00/24] Kernel lockdown

[Justin Forbes]

On Wed, Apr 5, 2017 at 12:07 PM, David Howells  wrote:
>
> These patches provide a facility by which a variety of avenues by which
> userspace can feasibly modify the running kernel image can be locked down.
> These include:
>
>  (*) No unsigned modules and no modules for which can't validate the
>  signature.
>
>  (*) No use of ioperm(), iopl() and no writing to /dev/port.
>
>  (*) No writing to /dev/mem or /dev/kmem.
>
>  (*) No hibernation.
>
>  (*) Restrict PCI BAR access.
>
>  (*) Restrict MSR access.
>
>  (*) No kexec_load().
>
>  (*) Certain ACPI restrictions.
>
>  (*) Restrict debugfs interface to ASUS WMI.
>
> The lock-down can be configured to be triggered by the EFI secure boot
> status, provided the shim isn't insecure.  The lock-down can be lifted by
> typing SysRq+x on a keyboard attached to the system.
>
>
> The patches can be found here also:
>
> 
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lockdown
>
> They are dependent on the hwparam branch, which I posted separately.
>
> David
> ---
> Dave Young (1):
>   Copy secure_boot flag in boot params across kexec reboot
>
> David Howells (7):
>   Add the ability to lock down access to the running kernel image
>   efi: Lock down the kernel if booted in secure boot mode
>   Enforce module signatures if the kernel is locked down
>   scsi: Lock down the eata driver
>   Prohibit PCMCIA CIS storage when the kernel is locked down
>   Lock down TIOCSSERIAL
>   Lock down module params that specify hardware parameters (eg. ioport)
>
> Josh Boyer (3):
>   efi: Add EFI_SECURE_BOOT bit
>   hibernate: Disable when the kernel is locked down
>   acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down
>
> Kyle McMartin (1):
>   Add a sysrq option to exit secure boot mode
>
> Lee, Chun-Yi (2):
>   kexec_file: Disable at runtime if securelevel has been set
>   bpf: Restrict kernel image access functions when the kernel is locked 
> down
>
> Linn Crosetto (2):
>   acpi: Disable ACPI table override if the kernel is locked down
>   acpi: Disable APEI error injection if the kernel is locked down
>
> Matthew Garrett (8):
>   Restrict /dev/mem and /dev/kmem when the kernel is locked down
>   kexec: Disable at runtime if the kernel is locked down
>   uswsusp: Disable when the kernel is locked down
>   PCI: Lock down BAR access when the kernel is locked down
>   x86: Lock down IO port access when the kernel is locked down
>   x86: Restrict MSR access when the kernel is locked down
>   asus-wmi: Restrict debugfs interface when the kernel is locked down
>   ACPI: Limit access to custom_method when the kernel is locked down
>
>
>  arch/x86/Kconfig  |   22 
>  arch/x86/kernel/ioport.c  |4 ++--
>  arch/x86/kernel/kexec-bzimage64.c |1 +
>  arch/x86/kernel/msr.c |7 ++
>  arch/x86/kernel/setup.c   |   40 
> -
>  drivers/acpi/apei/einj.c  |3 +++
>  drivers/acpi/custom_method.c  |3 +++
>  drivers/acpi/osl.c|2 +-
>  drivers/acpi/tables.c |5 +
>  drivers/char/mem.c|8 +++
>  drivers/input/misc/uinput.c   |1 +
>  drivers/pci/pci-sysfs.c   |9 
>  drivers/pci/proc.c|8 ++-
>  drivers/pci/syscall.c |2 +-
>  drivers/pcmcia/cistpl.c   |5 +
>  drivers/platform/x86/asus-wmi.c   |9 
>  drivers/scsi/eata.c   |7 ++
>  drivers/tty/serial/serial_core.c  |6 ++
>  drivers/tty/sysrq.c   |   19 --
>  include/linux/efi.h   |1 +
>  include/linux/input.h |5 +
>  include/linux/kernel.h|9 
>  include/linux/security.h  |   11 ++
>  include/linux/sysrq.h |8 ++-
>  kernel/debug/kdb/kdb_main.c   |2 +-
>  kernel/kexec.c|7 ++
>  kernel/kexec_file.c   |6 ++
>  kernel/module.c   |2 +-
>  kernel/params.c   |   27 -
>  kernel/power/hibernate.c  |2 +-
>  kernel/power/user.c   |3 +++
>  kernel/trace/bpf_trace.c  |   11 ++
>  security/Kconfig  |   15 ++
>  security/Makefile |3 +++
>  security/lock_down.c  |   40 
> +
>  35 files changed, 291 insertions(+), 22 deletions(-)
>  create mode 100644 security/lock_down.c
>

Tested-by: Justin Forbes 

Re: [PATCH 00/24] Kernel lockdown

[Justin Forbes]

On Fri, Apr 7, 2017 at 10:59 AM, Austin S. Hemmelgarn
 wrote:
> On 2017-04-05 16:14, David Howells wrote:
>>
>>
>> These patches provide a facility by which a variety of avenues by which
>> userspace can feasibly modify the running kernel image can be locked down.
>> These include:
>>
>>  (*) No unsigned modules and no modules for which can't validate the
>>  signature.
>>
>>  (*) No use of ioperm(), iopl() and no writing to /dev/port.
>>
>>  (*) No writing to /dev/mem or /dev/kmem.
>>
>>  (*) No hibernation.
>>
>>  (*) Restrict PCI BAR access.
>>
>>  (*) Restrict MSR access.
>>
>>  (*) No kexec_load().
>>
>>  (*) Certain ACPI restrictions.
>>
>>  (*) Restrict debugfs interface to ASUS WMI.
>>
>> The lock-down can be configured to be triggered by the EFI secure boot
>> status, provided the shim isn't insecure.  The lock-down can be lifted by
>> typing SysRq+x on a keyboard attached to the system.
>
> This has already been mentioned both in response to previous versions of
> this patch set, and by at least 2 people in response to a specific patch in
> this posting, but for any kind of proper security analysis, you need to
> better clarify your threat model.  'Prevent modification to the running
> kernel image' is a decent start on this, but at least some of the patches
> don't explain very well _how_ what you're disabling could be used to modify
> the running kernel image.  Clarifying how something is a threat will help
> with verifying that you're correctly blocking the threat.

It is more than just preventing modification to the running kernel
image.  The idea is that everything is verified, from UEFI through the
bootloader, and into the kernel.

> Furthermore, why is the only way to enable this to boot in UEFI Secure Boot
> mode?  Almost all of the hardening done here has general utility in
> hardening regular systems, and as such I'd suggest adding a command line
> option to enable kernel lock-down (which would greatly simplify testing),
> and a kconfig option to enforce it at build-time.

The problem is, if the hand off doesn't happen from a secure firmware,
there is no guarantee the system has not been compromised. UEFI Secure
Boot mode attempts to give that promise, and an appropriate hand off.
That doesn't mean that there is no value in turning some of this on,
it is just of more limited effectiveness.

> In addition to all that, it would be nice to be able to disable all of the
> following at build time independent of the kernel lock-down state
> * The acpi_rsdp kernel parameter (I could easily see many distros building
> kernels with this disabled, it's insanely use-case specific).
> * IO port and resource reservation module parameters (this would actually be
> easier than having runtime blacklisting, and I could also easily see this
> being turned on by default by a number of distros).
> * TOICSERIAL (this one is more likely than the above two to break systems).
>
> And these would probably be useful as lockable sysctls that would be
> automatically locked disabled when the kernel is locked down:
> * ioperm/iopl (these can technically be blocked by seccomp or other means,
> but that is non-trivial to do).
> * Most of the other ACPI stuff (some of this is useful for troubleshooting,
> but is not normally used during regular operation).
> * PCI BAR access.

There are more patches to do some of these things.   Baby steps.

Re: [PATCH 00/24] Kernel lockdown

[Justin Forbes]

On Fri, Apr 7, 2017 at 10:59 AM, Austin S. Hemmelgarn
 wrote:
> On 2017-04-05 16:14, David Howells wrote:
>>
>>
>> These patches provide a facility by which a variety of avenues by which
>> userspace can feasibly modify the running kernel image can be locked down.
>> These include:
>>
>>  (*) No unsigned modules and no modules for which can't validate the
>>  signature.
>>
>>  (*) No use of ioperm(), iopl() and no writing to /dev/port.
>>
>>  (*) No writing to /dev/mem or /dev/kmem.
>>
>>  (*) No hibernation.
>>
>>  (*) Restrict PCI BAR access.
>>
>>  (*) Restrict MSR access.
>>
>>  (*) No kexec_load().
>>
>>  (*) Certain ACPI restrictions.
>>
>>  (*) Restrict debugfs interface to ASUS WMI.
>>
>> The lock-down can be configured to be triggered by the EFI secure boot
>> status, provided the shim isn't insecure.  The lock-down can be lifted by
>> typing SysRq+x on a keyboard attached to the system.
>
> This has already been mentioned both in response to previous versions of
> this patch set, and by at least 2 people in response to a specific patch in
> this posting, but for any kind of proper security analysis, you need to
> better clarify your threat model.  'Prevent modification to the running
> kernel image' is a decent start on this, but at least some of the patches
> don't explain very well _how_ what you're disabling could be used to modify
> the running kernel image.  Clarifying how something is a threat will help
> with verifying that you're correctly blocking the threat.

It is more than just preventing modification to the running kernel
image.  The idea is that everything is verified, from UEFI through the
bootloader, and into the kernel.

> Furthermore, why is the only way to enable this to boot in UEFI Secure Boot
> mode?  Almost all of the hardening done here has general utility in
> hardening regular systems, and as such I'd suggest adding a command line
> option to enable kernel lock-down (which would greatly simplify testing),
> and a kconfig option to enforce it at build-time.

The problem is, if the hand off doesn't happen from a secure firmware,
there is no guarantee the system has not been compromised. UEFI Secure
Boot mode attempts to give that promise, and an appropriate hand off.
That doesn't mean that there is no value in turning some of this on,
it is just of more limited effectiveness.

> In addition to all that, it would be nice to be able to disable all of the
> following at build time independent of the kernel lock-down state
> * The acpi_rsdp kernel parameter (I could easily see many distros building
> kernels with this disabled, it's insanely use-case specific).
> * IO port and resource reservation module parameters (this would actually be
> easier than having runtime blacklisting, and I could also easily see this
> being turned on by default by a number of distros).
> * TOICSERIAL (this one is more likely than the above two to break systems).
>
> And these would probably be useful as lockable sysctls that would be
> automatically locked disabled when the kernel is locked down:
> * ioperm/iopl (these can technically be blocked by seccomp or other means,
> but that is non-trivial to do).
> * Most of the other ACPI stuff (some of this is useful for troubleshooting,
> but is not normally used during regular operation).
> * PCI BAR access.

There are more patches to do some of these things.   Baby steps.

Re: [PATCH 00/24] Kernel lockdown

[Austin S. Hemmelgarn]

On 2017-04-05 16:14, David Howells wrote:


These patches provide a facility by which a variety of avenues by which
userspace can feasibly modify the running kernel image can be locked down.
These include:

 (*) No unsigned modules and no modules for which can't validate the
 signature.

 (*) No use of ioperm(), iopl() and no writing to /dev/port.

 (*) No writing to /dev/mem or /dev/kmem.

 (*) No hibernation.

 (*) Restrict PCI BAR access.

 (*) Restrict MSR access.

 (*) No kexec_load().

 (*) Certain ACPI restrictions.

 (*) Restrict debugfs interface to ASUS WMI.

The lock-down can be configured to be triggered by the EFI secure boot
status, provided the shim isn't insecure.  The lock-down can be lifted by
typing SysRq+x on a keyboard attached to the system.
This has already been mentioned both in response to previous versions of 
this patch set, and by at least 2 people in response to a specific patch 
in this posting, but for any kind of proper security analysis, you need 
to better clarify your threat model.  'Prevent modification to the 
running kernel image' is a decent start on this, but at least some of 
the patches don't explain very well _how_ what you're disabling could be 
used to modify the running kernel image.  Clarifying how something is a 
threat will help with verifying that you're correctly blocking the threat.


Furthermore, why is the only way to enable this to boot in UEFI Secure 
Boot mode?  Almost all of the hardening done here has general utility in 
hardening regular systems, and as such I'd suggest adding a command line 
option to enable kernel lock-down (which would greatly simplify 
testing), and a kconfig option to enforce it at build-time.


In addition to all that, it would be nice to be able to disable all of 
the following at build time independent of the kernel lock-down state
* The acpi_rsdp kernel parameter (I could easily see many distros 
building kernels with this disabled, it's insanely use-case specific).
* IO port and resource reservation module parameters (this would 
actually be easier than having runtime blacklisting, and I could also 
easily see this being turned on by default by a number of distros).

* TOICSERIAL (this one is more likely than the above two to break systems).

And these would probably be useful as lockable sysctls that would be 
automatically locked disabled when the kernel is locked down:
* ioperm/iopl (these can technically be blocked by seccomp or other 
means, but that is non-trivial to do).
* Most of the other ACPI stuff (some of this is useful for 
troubleshooting, but is not normally used during regular operation).

* PCI BAR access.

Re: [PATCH 00/24] Kernel lockdown

[Austin S. Hemmelgarn]

On 2017-04-05 16:14, David Howells wrote:


These patches provide a facility by which a variety of avenues by which
userspace can feasibly modify the running kernel image can be locked down.
These include:

 (*) No unsigned modules and no modules for which can't validate the
 signature.

 (*) No use of ioperm(), iopl() and no writing to /dev/port.

 (*) No writing to /dev/mem or /dev/kmem.

 (*) No hibernation.

 (*) Restrict PCI BAR access.

 (*) Restrict MSR access.

 (*) No kexec_load().

 (*) Certain ACPI restrictions.

 (*) Restrict debugfs interface to ASUS WMI.

The lock-down can be configured to be triggered by the EFI secure boot
status, provided the shim isn't insecure.  The lock-down can be lifted by
typing SysRq+x on a keyboard attached to the system.
This has already been mentioned both in response to previous versions of 
this patch set, and by at least 2 people in response to a specific patch 
in this posting, but for any kind of proper security analysis, you need 
to better clarify your threat model.  'Prevent modification to the 
running kernel image' is a decent start on this, but at least some of 
the patches don't explain very well _how_ what you're disabling could be 
used to modify the running kernel image.  Clarifying how something is a 
threat will help with verifying that you're correctly blocking the threat.


Furthermore, why is the only way to enable this to boot in UEFI Secure 
Boot mode?  Almost all of the hardening done here has general utility in 
hardening regular systems, and as such I'd suggest adding a command line 
option to enable kernel lock-down (which would greatly simplify 
testing), and a kconfig option to enforce it at build-time.


In addition to all that, it would be nice to be able to disable all of 
the following at build time independent of the kernel lock-down state
* The acpi_rsdp kernel parameter (I could easily see many distros 
building kernels with this disabled, it's insanely use-case specific).
* IO port and resource reservation module parameters (this would 
actually be easier than having runtime blacklisting, and I could also 
easily see this being turned on by default by a number of distros).

* TOICSERIAL (this one is more likely than the above two to break systems).

And these would probably be useful as lockable sysctls that would be 
automatically locked disabled when the kernel is locked down:
* ioperm/iopl (these can technically be blocked by seccomp or other 
means, but that is non-trivial to do).
* Most of the other ACPI stuff (some of this is useful for 
troubleshooting, but is not normally used during regular operation).

* PCI BAR access.

Re: [PATCH 00/24] Kernel lockdown

[David Howells]

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

Re: [PATCH 00/24] Kernel lockdown

[David Howells]

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

Re: [PATCH 00/24] Kernel lockdown

[James Morris]

On Wed, 5 Apr 2017, David Howells 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' ?


-- 
James Morris

Re: [PATCH 00/24] Kernel lockdown

[James Morris]

On Wed, 5 Apr 2017, David Howells 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' ?


-- 
James Morris

[PATCH 00/24] Kernel lockdown

[David Howells]

These patches provide a facility by which a variety of avenues by which
userspace can feasibly modify the running kernel image can be locked down.
These include:

 (*) No unsigned modules and no modules for which can't validate the
 signature.

 (*) No use of ioperm(), iopl() and no writing to /dev/port.

 (*) No writing to /dev/mem or /dev/kmem.

 (*) No hibernation.

 (*) Restrict PCI BAR access.

 (*) Restrict MSR access.

 (*) No kexec_load().

 (*) Certain ACPI restrictions.

 (*) Restrict debugfs interface to ASUS WMI.

The lock-down can be configured to be triggered by the EFI secure boot
status, provided the shim isn't insecure.  The lock-down can be lifted by
typing SysRq+x on a keyboard attached to the system.


The patches can be found here also:


http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lockdown

They are dependent on the hwparam branch, which I posted separately.

David
---
Chun-Yi Lee (2):
  kexec_file: Disable at runtime if securelevel has been set
  bpf: Restrict kernel image access functions when the kernel is locked down

Dave Young (1):
  Copy secure_boot flag in boot params across kexec reboot

David Howells (7):
  Add the ability to lock down access to the running kernel image
  efi: Lock down the kernel if booted in secure boot mode
  Enforce module signatures if the kernel is locked down
  scsi: Lock down the eata driver
  Prohibit PCMCIA CIS storage when the kernel is locked down
  Lock down TIOCSSERIAL
  Lock down module params that specify hardware parameters (eg. ioport)

Josh Boyer (3):
  efi: Add EFI_SECURE_BOOT bit
  hibernate: Disable when the kernel is locked down
  acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

Kyle McMartin (1):
  Add a sysrq option to exit secure boot mode

Linn Crosetto (2):
  acpi: Disable ACPI table override if the kernel is locked down
  acpi: Disable APEI error injection if the kernel is locked down

Matthew Garrett (8):
  Restrict /dev/mem and /dev/kmem when the kernel is locked down
  kexec: Disable at runtime if the kernel is locked down
  uswsusp: Disable when the kernel is locked down
  PCI: Lock down BAR access when the kernel is locked down
  x86: Lock down IO port access when the kernel is locked down
  x86: Restrict MSR access when the kernel is locked down
  asus-wmi: Restrict debugfs interface when the kernel is locked down
  ACPI: Limit access to custom_method when the kernel is locked down


 arch/x86/Kconfig  |   22 
 arch/x86/kernel/ioport.c  |4 ++--
 arch/x86/kernel/kexec-bzimage64.c |1 +
 arch/x86/kernel/msr.c |7 ++
 arch/x86/kernel/setup.c   |   40 -
 drivers/acpi/apei/einj.c  |3 +++
 drivers/acpi/custom_method.c  |3 +++
 drivers/acpi/osl.c|2 +-
 drivers/acpi/tables.c |5 +
 drivers/char/mem.c|8 +++
 drivers/input/misc/uinput.c   |1 +
 drivers/pci/pci-sysfs.c   |9 
 drivers/pci/proc.c|8 ++-
 drivers/pci/syscall.c |2 +-
 drivers/pcmcia/cistpl.c   |5 +
 drivers/platform/x86/asus-wmi.c   |9 
 drivers/scsi/eata.c   |7 ++
 drivers/tty/serial/serial_core.c  |6 ++
 drivers/tty/sysrq.c   |   19 --
 include/linux/efi.h   |1 +
 include/linux/input.h |5 +
 include/linux/kernel.h|9 
 include/linux/security.h  |   11 ++
 include/linux/sysrq.h |8 ++-
 kernel/debug/kdb/kdb_main.c   |2 +-
 kernel/kexec.c|7 ++
 kernel/kexec_file.c   |6 ++
 kernel/module.c   |2 +-
 kernel/params.c   |   27 -
 kernel/power/hibernate.c  |2 +-
 kernel/power/user.c   |3 +++
 kernel/trace/bpf_trace.c  |   11 ++
 security/Kconfig  |   15 ++
 security/Makefile |3 +++
 security/lock_down.c  |   40 +
 35 files changed, 291 insertions(+), 22 deletions(-)
 create mode 100644 security/lock_down.c

[PATCH 00/24] Kernel lockdown

[David Howells]

These patches provide a facility by which a variety of avenues by which
userspace can feasibly modify the running kernel image can be locked down.
These include:

 (*) No unsigned modules and no modules for which can't validate the
 signature.

 (*) No use of ioperm(), iopl() and no writing to /dev/port.

 (*) No writing to /dev/mem or /dev/kmem.

 (*) No hibernation.

 (*) Restrict PCI BAR access.

 (*) Restrict MSR access.

 (*) No kexec_load().

 (*) Certain ACPI restrictions.

 (*) Restrict debugfs interface to ASUS WMI.

The lock-down can be configured to be triggered by the EFI secure boot
status, provided the shim isn't insecure.  The lock-down can be lifted by
typing SysRq+x on a keyboard attached to the system.


The patches can be found here also:


http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lockdown

They are dependent on the hwparam branch, which I posted separately.

David
---
Chun-Yi Lee (2):
  kexec_file: Disable at runtime if securelevel has been set
  bpf: Restrict kernel image access functions when the kernel is locked down

Dave Young (1):
  Copy secure_boot flag in boot params across kexec reboot

David Howells (7):
  Add the ability to lock down access to the running kernel image
  efi: Lock down the kernel if booted in secure boot mode
  Enforce module signatures if the kernel is locked down
  scsi: Lock down the eata driver
  Prohibit PCMCIA CIS storage when the kernel is locked down
  Lock down TIOCSSERIAL
  Lock down module params that specify hardware parameters (eg. ioport)

Josh Boyer (3):
  efi: Add EFI_SECURE_BOOT bit
  hibernate: Disable when the kernel is locked down
  acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

Kyle McMartin (1):
  Add a sysrq option to exit secure boot mode

Linn Crosetto (2):
  acpi: Disable ACPI table override if the kernel is locked down
  acpi: Disable APEI error injection if the kernel is locked down

Matthew Garrett (8):
  Restrict /dev/mem and /dev/kmem when the kernel is locked down
  kexec: Disable at runtime if the kernel is locked down
  uswsusp: Disable when the kernel is locked down
  PCI: Lock down BAR access when the kernel is locked down
  x86: Lock down IO port access when the kernel is locked down
  x86: Restrict MSR access when the kernel is locked down
  asus-wmi: Restrict debugfs interface when the kernel is locked down
  ACPI: Limit access to custom_method when the kernel is locked down


 arch/x86/Kconfig  |   22 
 arch/x86/kernel/ioport.c  |4 ++--
 arch/x86/kernel/kexec-bzimage64.c |1 +
 arch/x86/kernel/msr.c |7 ++
 arch/x86/kernel/setup.c   |   40 -
 drivers/acpi/apei/einj.c  |3 +++
 drivers/acpi/custom_method.c  |3 +++
 drivers/acpi/osl.c|2 +-
 drivers/acpi/tables.c |5 +
 drivers/char/mem.c|8 +++
 drivers/input/misc/uinput.c   |1 +
 drivers/pci/pci-sysfs.c   |9 
 drivers/pci/proc.c|8 ++-
 drivers/pci/syscall.c |2 +-
 drivers/pcmcia/cistpl.c   |5 +
 drivers/platform/x86/asus-wmi.c   |9 
 drivers/scsi/eata.c   |7 ++
 drivers/tty/serial/serial_core.c  |6 ++
 drivers/tty/sysrq.c   |   19 --
 include/linux/efi.h   |1 +
 include/linux/input.h |5 +
 include/linux/kernel.h|9 
 include/linux/security.h  |   11 ++
 include/linux/sysrq.h |8 ++-
 kernel/debug/kdb/kdb_main.c   |2 +-
 kernel/kexec.c|7 ++
 kernel/kexec_file.c   |6 ++
 kernel/module.c   |2 +-
 kernel/params.c   |   27 -
 kernel/power/hibernate.c  |2 +-
 kernel/power/user.c   |3 +++
 kernel/trace/bpf_trace.c  |   11 ++
 security/Kconfig  |   15 ++
 security/Makefile |3 +++
 security/lock_down.c  |   40 +
 35 files changed, 291 insertions(+), 22 deletions(-)
 create mode 100644 security/lock_down.c

Re: [PATCH 00/24] Kernel lockdown

[David Howells]

Let me try sending this again again.  Lee, Chun-Yi as a name causes the mail
dispatcher to break :-/

David

Re: [PATCH 00/24] Kernel lockdown

[David Howells]

Let me try sending this again again.  Lee, Chun-Yi as a name causes the mail
dispatcher to break :-/

David

[PATCH 00/24] Kernel lockdown

[David Howells]

These patches provide a facility by which a variety of avenues by which
userspace can feasibly modify the running kernel image can be locked down.
These include:

 (*) No unsigned modules and no modules for which can't validate the
 signature.

 (*) No use of ioperm(), iopl() and no writing to /dev/port.

 (*) No writing to /dev/mem or /dev/kmem.

 (*) No hibernation.

 (*) Restrict PCI BAR access.

 (*) Restrict MSR access.

 (*) No kexec_load().

 (*) Certain ACPI restrictions.

 (*) Restrict debugfs interface to ASUS WMI.

The lock-down can be configured to be triggered by the EFI secure boot
status, provided the shim isn't insecure.  The lock-down can be lifted by
typing SysRq+x on a keyboard attached to the system.


The patches can be found here also:


http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lockdown

They are dependent on the hwparam branch, which I posted separately.

David
---
Chun-Yi Lee (1):
  kexec_file: Disable at runtime if securelevel has been set

Dave Young (1):
  Copy secure_boot flag in boot params across kexec reboot

David Howells (7):
  Add the ability to lock down access to the running kernel image
  efi: Lock down the kernel if booted in secure boot mode
  Enforce module signatures if the kernel is locked down
  scsi: Lock down the eata driver
  Prohibit PCMCIA CIS storage when the kernel is locked down
  Lock down TIOCSSERIAL
  Lock down module params that specify hardware parameters (eg. ioport)

Josh Boyer (3):
  efi: Add EFI_SECURE_BOOT bit
  hibernate: Disable when the kernel is locked down
  acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

Kyle McMartin (1):
  Add a sysrq option to exit secure boot mode

Lee, Chun-Yi (1):
  bpf: Restrict kernel image access functions when the kernel is locked down

Linn Crosetto (2):
  acpi: Disable ACPI table override if the kernel is locked down
  acpi: Disable APEI error injection if the kernel is locked down

Matthew Garrett (8):
  Restrict /dev/mem and /dev/kmem when the kernel is locked down
  kexec: Disable at runtime if the kernel is locked down
  uswsusp: Disable when the kernel is locked down
  PCI: Lock down BAR access when the kernel is locked down
  x86: Lock down IO port access when the kernel is locked down
  x86: Restrict MSR access when the kernel is locked down
  asus-wmi: Restrict debugfs interface when the kernel is locked down
  ACPI: Limit access to custom_method when the kernel is locked down


 arch/x86/Kconfig  |   22 
 arch/x86/kernel/ioport.c  |4 ++--
 arch/x86/kernel/kexec-bzimage64.c |1 +
 arch/x86/kernel/msr.c |7 ++
 arch/x86/kernel/setup.c   |   40 -
 drivers/acpi/apei/einj.c  |3 +++
 drivers/acpi/custom_method.c  |3 +++
 drivers/acpi/osl.c|2 +-
 drivers/acpi/tables.c |5 +
 drivers/char/mem.c|8 +++
 drivers/input/misc/uinput.c   |1 +
 drivers/pci/pci-sysfs.c   |9 
 drivers/pci/proc.c|8 ++-
 drivers/pci/syscall.c |2 +-
 drivers/pcmcia/cistpl.c   |5 +
 drivers/platform/x86/asus-wmi.c   |9 
 drivers/scsi/eata.c   |7 ++
 drivers/tty/serial/serial_core.c  |6 ++
 drivers/tty/sysrq.c   |   19 --
 include/linux/efi.h   |1 +
 include/linux/input.h |5 +
 include/linux/kernel.h|9 
 include/linux/security.h  |   11 ++
 include/linux/sysrq.h |8 ++-
 kernel/debug/kdb/kdb_main.c   |2 +-
 kernel/kexec.c|7 ++
 kernel/kexec_file.c   |6 ++
 kernel/module.c   |2 +-
 kernel/params.c   |   27 -
 kernel/power/hibernate.c  |2 +-
 kernel/power/user.c   |3 +++
 kernel/trace/bpf_trace.c  |   11 ++
 security/Kconfig  |   15 ++
 security/Makefile |3 +++
 security/lock_down.c  |   40 +
 35 files changed, 291 insertions(+), 22 deletions(-)
 create mode 100644 security/lock_down.c

[PATCH 00/24] Kernel lockdown

[David Howells]

These patches provide a facility by which a variety of avenues by which
userspace can feasibly modify the running kernel image can be locked down.
These include:

 (*) No unsigned modules and no modules for which can't validate the
 signature.

 (*) No use of ioperm(), iopl() and no writing to /dev/port.

 (*) No writing to /dev/mem or /dev/kmem.

 (*) No hibernation.

 (*) Restrict PCI BAR access.

 (*) Restrict MSR access.

 (*) No kexec_load().

 (*) Certain ACPI restrictions.

 (*) Restrict debugfs interface to ASUS WMI.

The lock-down can be configured to be triggered by the EFI secure boot
status, provided the shim isn't insecure.  The lock-down can be lifted by
typing SysRq+x on a keyboard attached to the system.


The patches can be found here also:


http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lockdown

They are dependent on the hwparam branch, which I posted separately.

David
---
Chun-Yi Lee (1):
  kexec_file: Disable at runtime if securelevel has been set

Dave Young (1):
  Copy secure_boot flag in boot params across kexec reboot

David Howells (7):
  Add the ability to lock down access to the running kernel image
  efi: Lock down the kernel if booted in secure boot mode
  Enforce module signatures if the kernel is locked down
  scsi: Lock down the eata driver
  Prohibit PCMCIA CIS storage when the kernel is locked down
  Lock down TIOCSSERIAL
  Lock down module params that specify hardware parameters (eg. ioport)

Josh Boyer (3):
  efi: Add EFI_SECURE_BOOT bit
  hibernate: Disable when the kernel is locked down
  acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

Kyle McMartin (1):
  Add a sysrq option to exit secure boot mode

Lee, Chun-Yi (1):
  bpf: Restrict kernel image access functions when the kernel is locked down

Linn Crosetto (2):
  acpi: Disable ACPI table override if the kernel is locked down
  acpi: Disable APEI error injection if the kernel is locked down

Matthew Garrett (8):
  Restrict /dev/mem and /dev/kmem when the kernel is locked down
  kexec: Disable at runtime if the kernel is locked down
  uswsusp: Disable when the kernel is locked down
  PCI: Lock down BAR access when the kernel is locked down
  x86: Lock down IO port access when the kernel is locked down
  x86: Restrict MSR access when the kernel is locked down
  asus-wmi: Restrict debugfs interface when the kernel is locked down
  ACPI: Limit access to custom_method when the kernel is locked down


 arch/x86/Kconfig  |   22 
 arch/x86/kernel/ioport.c  |4 ++--
 arch/x86/kernel/kexec-bzimage64.c |1 +
 arch/x86/kernel/msr.c |7 ++
 arch/x86/kernel/setup.c   |   40 -
 drivers/acpi/apei/einj.c  |3 +++
 drivers/acpi/custom_method.c  |3 +++
 drivers/acpi/osl.c|2 +-
 drivers/acpi/tables.c |5 +
 drivers/char/mem.c|8 +++
 drivers/input/misc/uinput.c   |1 +
 drivers/pci/pci-sysfs.c   |9 
 drivers/pci/proc.c|8 ++-
 drivers/pci/syscall.c |2 +-
 drivers/pcmcia/cistpl.c   |5 +
 drivers/platform/x86/asus-wmi.c   |9 
 drivers/scsi/eata.c   |7 ++
 drivers/tty/serial/serial_core.c  |6 ++
 drivers/tty/sysrq.c   |   19 --
 include/linux/efi.h   |1 +
 include/linux/input.h |5 +
 include/linux/kernel.h|9 
 include/linux/security.h  |   11 ++
 include/linux/sysrq.h |8 ++-
 kernel/debug/kdb/kdb_main.c   |2 +-
 kernel/kexec.c|7 ++
 kernel/kexec_file.c   |6 ++
 kernel/module.c   |2 +-
 kernel/params.c   |   27 -
 kernel/power/hibernate.c  |2 +-
 kernel/power/user.c   |3 +++
 kernel/trace/bpf_trace.c  |   11 ++
 security/Kconfig  |   15 ++
 security/Makefile |3 +++
 security/lock_down.c  |   40 +
 35 files changed, 291 insertions(+), 22 deletions(-)
 create mode 100644 security/lock_down.c

[PATCH 00/24] Kernel lockdown

[David Howells]

These patches provide a facility by which a variety of avenues by which
userspace can feasibly modify the running kernel image can be locked down.
These include:

 (*) No unsigned modules and no modules for which can't validate the
 signature.

 (*) No use of ioperm(), iopl() and no writing to /dev/port.

 (*) No writing to /dev/mem or /dev/kmem.

 (*) No hibernation.

 (*) Restrict PCI BAR access.

 (*) Restrict MSR access.

 (*) No kexec_load().

 (*) Certain ACPI restrictions.

 (*) Restrict debugfs interface to ASUS WMI.

The lock-down can be configured to be triggered by the EFI secure boot
status, provided the shim isn't insecure.  The lock-down can be lifted by
typing SysRq+x on a keyboard attached to the system.


The patches can be found here also:


http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lockdown

They are dependent on the hwparam branch, which I posted separately.

David
---
Dave Young (1):
  Copy secure_boot flag in boot params across kexec reboot

David Howells (7):
  Add the ability to lock down access to the running kernel image
  efi: Lock down the kernel if booted in secure boot mode
  Enforce module signatures if the kernel is locked down
  scsi: Lock down the eata driver
  Prohibit PCMCIA CIS storage when the kernel is locked down
  Lock down TIOCSSERIAL
  Lock down module params that specify hardware parameters (eg. ioport)

Josh Boyer (3):
  efi: Add EFI_SECURE_BOOT bit
  hibernate: Disable when the kernel is locked down
  acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

Kyle McMartin (1):
  Add a sysrq option to exit secure boot mode

Lee, Chun-Yi (2):
  kexec_file: Disable at runtime if securelevel has been set
  bpf: Restrict kernel image access functions when the kernel is locked down

Linn Crosetto (2):
  acpi: Disable ACPI table override if the kernel is locked down
  acpi: Disable APEI error injection if the kernel is locked down

Matthew Garrett (8):
  Restrict /dev/mem and /dev/kmem when the kernel is locked down
  kexec: Disable at runtime if the kernel is locked down
  uswsusp: Disable when the kernel is locked down
  PCI: Lock down BAR access when the kernel is locked down
  x86: Lock down IO port access when the kernel is locked down
  x86: Restrict MSR access when the kernel is locked down
  asus-wmi: Restrict debugfs interface when the kernel is locked down
  ACPI: Limit access to custom_method when the kernel is locked down


 arch/x86/Kconfig  |   22 
 arch/x86/kernel/ioport.c  |4 ++--
 arch/x86/kernel/kexec-bzimage64.c |1 +
 arch/x86/kernel/msr.c |7 ++
 arch/x86/kernel/setup.c   |   40 -
 drivers/acpi/apei/einj.c  |3 +++
 drivers/acpi/custom_method.c  |3 +++
 drivers/acpi/osl.c|2 +-
 drivers/acpi/tables.c |5 +
 drivers/char/mem.c|8 +++
 drivers/input/misc/uinput.c   |1 +
 drivers/pci/pci-sysfs.c   |9 
 drivers/pci/proc.c|8 ++-
 drivers/pci/syscall.c |2 +-
 drivers/pcmcia/cistpl.c   |5 +
 drivers/platform/x86/asus-wmi.c   |9 
 drivers/scsi/eata.c   |7 ++
 drivers/tty/serial/serial_core.c  |6 ++
 drivers/tty/sysrq.c   |   19 --
 include/linux/efi.h   |1 +
 include/linux/input.h |5 +
 include/linux/kernel.h|9 
 include/linux/security.h  |   11 ++
 include/linux/sysrq.h |8 ++-
 kernel/debug/kdb/kdb_main.c   |2 +-
 kernel/kexec.c|7 ++
 kernel/kexec_file.c   |6 ++
 kernel/module.c   |2 +-
 kernel/params.c   |   27 -
 kernel/power/hibernate.c  |2 +-
 kernel/power/user.c   |3 +++
 kernel/trace/bpf_trace.c  |   11 ++
 security/Kconfig  |   15 ++
 security/Makefile |3 +++
 security/lock_down.c  |   40 +
 35 files changed, 291 insertions(+), 22 deletions(-)
 create mode 100644 security/lock_down.c

[PATCH 00/24] Kernel lockdown

[David Howells]

These patches provide a facility by which a variety of avenues by which
userspace can feasibly modify the running kernel image can be locked down.
These include:

 (*) No unsigned modules and no modules for which can't validate the
 signature.

 (*) No use of ioperm(), iopl() and no writing to /dev/port.

 (*) No writing to /dev/mem or /dev/kmem.

 (*) No hibernation.

 (*) Restrict PCI BAR access.

 (*) Restrict MSR access.

 (*) No kexec_load().

 (*) Certain ACPI restrictions.

 (*) Restrict debugfs interface to ASUS WMI.

The lock-down can be configured to be triggered by the EFI secure boot
status, provided the shim isn't insecure.  The lock-down can be lifted by
typing SysRq+x on a keyboard attached to the system.


The patches can be found here also:


http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lockdown

They are dependent on the hwparam branch, which I posted separately.

David
---
Dave Young (1):
  Copy secure_boot flag in boot params across kexec reboot

David Howells (7):
  Add the ability to lock down access to the running kernel image
  efi: Lock down the kernel if booted in secure boot mode
  Enforce module signatures if the kernel is locked down
  scsi: Lock down the eata driver
  Prohibit PCMCIA CIS storage when the kernel is locked down
  Lock down TIOCSSERIAL
  Lock down module params that specify hardware parameters (eg. ioport)

Josh Boyer (3):
  efi: Add EFI_SECURE_BOOT bit
  hibernate: Disable when the kernel is locked down
  acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

Kyle McMartin (1):
  Add a sysrq option to exit secure boot mode

Lee, Chun-Yi (2):
  kexec_file: Disable at runtime if securelevel has been set
  bpf: Restrict kernel image access functions when the kernel is locked down

Linn Crosetto (2):
  acpi: Disable ACPI table override if the kernel is locked down
  acpi: Disable APEI error injection if the kernel is locked down

Matthew Garrett (8):
  Restrict /dev/mem and /dev/kmem when the kernel is locked down
  kexec: Disable at runtime if the kernel is locked down
  uswsusp: Disable when the kernel is locked down
  PCI: Lock down BAR access when the kernel is locked down
  x86: Lock down IO port access when the kernel is locked down
  x86: Restrict MSR access when the kernel is locked down
  asus-wmi: Restrict debugfs interface when the kernel is locked down
  ACPI: Limit access to custom_method when the kernel is locked down


 arch/x86/Kconfig  |   22 
 arch/x86/kernel/ioport.c  |4 ++--
 arch/x86/kernel/kexec-bzimage64.c |1 +
 arch/x86/kernel/msr.c |7 ++
 arch/x86/kernel/setup.c   |   40 -
 drivers/acpi/apei/einj.c  |3 +++
 drivers/acpi/custom_method.c  |3 +++
 drivers/acpi/osl.c|2 +-
 drivers/acpi/tables.c |5 +
 drivers/char/mem.c|8 +++
 drivers/input/misc/uinput.c   |1 +
 drivers/pci/pci-sysfs.c   |9 
 drivers/pci/proc.c|8 ++-
 drivers/pci/syscall.c |2 +-
 drivers/pcmcia/cistpl.c   |5 +
 drivers/platform/x86/asus-wmi.c   |9 
 drivers/scsi/eata.c   |7 ++
 drivers/tty/serial/serial_core.c  |6 ++
 drivers/tty/sysrq.c   |   19 --
 include/linux/efi.h   |1 +
 include/linux/input.h |5 +
 include/linux/kernel.h|9 
 include/linux/security.h  |   11 ++
 include/linux/sysrq.h |8 ++-
 kernel/debug/kdb/kdb_main.c   |2 +-
 kernel/kexec.c|7 ++
 kernel/kexec_file.c   |6 ++
 kernel/module.c   |2 +-
 kernel/params.c   |   27 -
 kernel/power/hibernate.c  |2 +-
 kernel/power/user.c   |3 +++
 kernel/trace/bpf_trace.c  |   11 ++
 security/Kconfig  |   15 ++
 security/Makefile |3 +++
 security/lock_down.c  |   40 +
 35 files changed, 291 insertions(+), 22 deletions(-)
 create mode 100644 security/lock_down.c