Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1523865 > unrolled thread

[PATCH 00/16] Kernel lockdown

Back to article view | Back to linux.kernel

Contents

  [PATCH 00/16] Kernel lockdown David Howells <dhowells@redhat.com> - 2016-11-16 22:50 +0100
    [PATCH 15/16] acpi: Ignore acpi_rsdp kernel param when the kernel  has been locked down David Howells <dhowells@redhat.com> - 2016-11-16 22:50 +0100
    [PATCH 05/16] efi: Add EFI_SECURE_BOOT bit David Howells <dhowells@redhat.com> - 2016-11-16 22:50 +0100
      Re: [PATCH 05/16] efi: Add EFI_SECURE_BOOT bit Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-11-17 23:00 +0100
        Re: [PATCH 05/16] efi: Add EFI_SECURE_BOOT bit Josh Boyer <jwboyer@fedoraproject.org> - 2016-11-18 13:00 +0100
          Re: [PATCH 05/16] efi: Add EFI_SECURE_BOOT bit Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-11-18 13:20 +0100
        Re: [PATCH 05/16] efi: Add EFI_SECURE_BOOT bit David Howells <dhowells@redhat.com> - 2016-11-18 18:30 +0100
    [PATCH 07/16] kexec: Disable at runtime if the kernel is locked down David Howells <dhowells@redhat.com> - 2016-11-16 22:50 +0100
    [PATCH 08/16] Copy secure_boot flag in boot params across kexec  reboot David Howells <dhowells@redhat.com> - 2016-11-16 22:50 +0100
    [PATCH 12/16] ACPI: Limit access to custom_method when the kernel  is locked down David Howells <dhowells@redhat.com> - 2016-11-16 22:50 +0100
    [PATCH 03/16] efi: Disable secure boot if shim is in insecure mode David Howells <dhowells@redhat.com> - 2016-11-16 23:00 +0100
    [PATCH 04/16] efi: Lock down the kernel if booted in secure boot  mode David Howells <dhowells@redhat.com> - 2016-11-16 23:00 +0100
    [PATCH 11/16] x86: Lock down IO port access when the kernel is  locked down David Howells <dhowells@redhat.com> - 2016-11-16 23:00 +0100
    [PATCH 06/16] Add a sysrq option to exit secure boot mode David Howells <dhowells@redhat.com> - 2016-11-16 23:00 +0100
    Re: [PATCH 00/16] Kernel lockdown One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-11-16 23:30 +0100
      Re: [PATCH 00/16] Kernel lockdown Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-11-21 21:00 +0100
    Re: [PATCH 00/16] Kernel lockdown Justin Forbes <jmforbes@linuxtx.org> - 2016-11-16 23:30 +0100
    Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs  and dma changed Dominik Brodowski <linux@dominikbrodowski.net> - 2016-11-22 07:30 +0100
      Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed David Howells <dhowells@redhat.com> - 2016-11-23 14:00 +0100
        Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs  and dma changed Dominik Brodowski <linux@dominikbrodowski.net> - 2016-11-23 20:30 +0100
          Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed David Howells <dhowells@redhat.com> - 2016-11-24 18:40 +0100
            Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs  and dma changed Dominik Brodowski <linux@dominikbrodowski.net> - 2016-11-24 21:30 +0100

Page 1 of 2  [1] 2  Next page →

#1523865 — [PATCH 00/16] Kernel lockdown

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=keys-lockdown

They are dependent for some EFI definitions on the keys-uefi branch.

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

David Howells (3):
      Add the ability to lock down access to the running kernel image
      efi: Get the secure boot status
      efi: Lock down the kernel if booted in secure boot mode

Josh Boyer (4):
      efi: Disable secure boot if shim is in insecure mode
      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

Matthew Garrett (7):
      kexec: Disable at runtime if 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
      ACPI: Limit access to custom_method when the kernel is locked down
      asus-wmi: Restrict debugfs interface when the kernel is locked down
      Restrict /dev/mem and /dev/kmem when the kernel is locked down
      x86: Restrict MSR access when the kernel is locked down


 Documentation/x86/zero-page.txt       |    2 +
 arch/x86/Kconfig                      |   22 ++++++++++++++
 arch/x86/boot/compressed/eboot.c      |   53 +++++++++++++++++++++++++++++++++
 arch/x86/include/uapi/asm/bootparam.h |    3 +-
 arch/x86/kernel/ioport.c              |    5 ++-
 arch/x86/kernel/kexec-bzimage64.c     |    1 +
 arch/x86/kernel/msr.c                 |    8 +++++
 arch/x86/kernel/setup.c               |   39 ++++++++++++++++++++++++
 drivers/acpi/custom_method.c          |    3 ++
 drivers/acpi/osl.c                    |    3 +-
 drivers/char/mem.c                    |   10 ++++++
 drivers/input/misc/uinput.c           |    1 +
 drivers/pci/pci-sysfs.c               |   10 ++++++
 drivers/pci/proc.c                    |    9 +++++-
 drivers/pci/syscall.c                 |    3 +-
 drivers/platform/x86/asus-wmi.c       |    9 ++++++
 drivers/tty/sysrq.c                   |   19 ++++++++----
 include/linux/efi.h                   |    1 +
 include/linux/input.h                 |    5 +++
 include/linux/security.h              |   16 ++++++++++
 include/linux/sysrq.h                 |    8 ++++-
 kernel/debug/kdb/kdb_main.c           |    2 +
 kernel/kexec.c                        |    8 +++++
 kernel/module.c                       |    2 +
 kernel/power/hibernate.c              |    3 +-
 security/Kconfig                      |   16 +++++++++-
 security/Makefile                     |    3 ++
 security/lock_down.c                  |   40 +++++++++++++++++++++++++
 28 files changed, 287 insertions(+), 17 deletions(-)
 create mode 100644 security/lock_down.c

[toc] | [next] | [standalone]

#1523866 — [PATCH 15/16] acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

From: Josh Boyer <jwboyer@redhat.com>

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 option when the kernel is locked down.

Signed-off-by: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
---

 drivers/acpi/osl.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 416953a42510..fb1dc79a7f1b 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -40,6 +40,7 @@
 #include <linux/list.h>
 #include <linux/jiffies.h>
 #include <linux/semaphore.h>
+#include <linux/security.h>
 
 #include <asm/io.h>
 #include <asm/uaccess.h>
@@ -191,7 +192,7 @@ early_param("acpi_rsdp", setup_acpi_rsdp);
 acpi_physical_address __init acpi_os_get_root_pointer(void)
 {
 #ifdef CONFIG_KEXEC
-	if (acpi_rsdp)
+	if (acpi_rsdp && !kernel_is_locked_down())
 		return acpi_rsdp;
 #endif
 

[toc] | [prev] | [next] | [standalone]

#1523868 — [PATCH 05/16] efi: Add EFI_SECURE_BOOT bit

From: Josh Boyer <jwboyer@fedoraproject.org>

UEFI machines can be booted in Secure Boot mode.  Add a EFI_SECURE_BOOT bit
for use with efi_enabled.

Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: David Howells <dhowells@redhat.com>
---

 arch/x86/kernel/setup.c |    1 +
 include/linux/efi.h     |    1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 9521acce8378..539f29587712 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1164,6 +1164,7 @@ void __init setup_arch(char **cmdline_p)
 	if (boot_params.secure_boot &&
 	    IS_ENABLED(CONFIG_EFI_SECURE_BOOT_LOCK_DOWN)) {
 		lock_kernel_down();
+		set_bit(EFI_SECURE_BOOT, &efi.flags);
 		pr_info("Secure boot enabled\n");
 	}
 
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 11372fb8784c..5d7fb3e3400b 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1079,6 +1079,7 @@ extern int __init efi_setup_pcdp_console(char *);
 #define EFI_ARCH_1		7	/* First arch-specific bit */
 #define EFI_DBG			8	/* Print additional debug info at runtime */
 #define EFI_NX_PE_DATA		9	/* Can runtime data regions be mapped non-executable? */
+#define EFI_SECURE_BOOT		10	/* Are we in Secure Boot mode? */
 
 #ifdef CONFIG_EFI
 /*

[toc] | [prev] | [next] | [standalone]

#1524839 — Re: [PATCH 05/16] efi: Add EFI_SECURE_BOOT bit

On 16 November 2016 at 21:47, David Howells <dhowells@redhat.com> wrote:
> From: Josh Boyer <jwboyer@fedoraproject.org>
>
> UEFI machines can be booted in Secure Boot mode.  Add a EFI_SECURE_BOOT bit
> for use with efi_enabled.
>
> Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
>
>  arch/x86/kernel/setup.c |    1 +
>  include/linux/efi.h     |    1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 9521acce8378..539f29587712 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -1164,6 +1164,7 @@ void __init setup_arch(char **cmdline_p)
>         if (boot_params.secure_boot &&
>             IS_ENABLED(CONFIG_EFI_SECURE_BOOT_LOCK_DOWN)) {
>                 lock_kernel_down();
> +               set_bit(EFI_SECURE_BOOT, &efi.flags);

Why is this x86 only? And why is this bit only set if
CONFIG_EFI_SECURE_BOOT_LOCK_DOWN is enabled?

>                 pr_info("Secure boot enabled\n");
>         }
>
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 11372fb8784c..5d7fb3e3400b 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -1079,6 +1079,7 @@ extern int __init efi_setup_pcdp_console(char *);
>  #define EFI_ARCH_1             7       /* First arch-specific bit */
>  #define EFI_DBG                        8       /* Print additional debug info at runtime */
>  #define EFI_NX_PE_DATA         9       /* Can runtime data regions be mapped non-executable? */
> +#define EFI_SECURE_BOOT                10      /* Are we in Secure Boot mode? */
>
>  #ifdef CONFIG_EFI
>  /*
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]

#1525227 — Re: [PATCH 05/16] efi: Add EFI_SECURE_BOOT bit

On Thu, Nov 17, 2016 at 4:58 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 16 November 2016 at 21:47, David Howells <dhowells@redhat.com> wrote:
>> From: Josh Boyer <jwboyer@fedoraproject.org>
>>
>> UEFI machines can be booted in Secure Boot mode.  Add a EFI_SECURE_BOOT bit
>> for use with efi_enabled.
>>
>> Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
>> Signed-off-by: David Howells <dhowells@redhat.com>
>> ---
>>
>>  arch/x86/kernel/setup.c |    1 +
>>  include/linux/efi.h     |    1 +
>>  2 files changed, 2 insertions(+)
>>
>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>> index 9521acce8378..539f29587712 100644
>> --- a/arch/x86/kernel/setup.c
>> +++ b/arch/x86/kernel/setup.c
>> @@ -1164,6 +1164,7 @@ void __init setup_arch(char **cmdline_p)
>>         if (boot_params.secure_boot &&
>>             IS_ENABLED(CONFIG_EFI_SECURE_BOOT_LOCK_DOWN)) {
>>                 lock_kernel_down();
>> +               set_bit(EFI_SECURE_BOOT, &efi.flags);
>
> Why is this x86 only? And why is this bit only set if

Because it was initially written like 3 years ago before ARM even had
UEFI.  Needs a refresh.

> CONFIG_EFI_SECURE_BOOT_LOCK_DOWN is enabled?

That part is new and something David added.  Probably not necessary.

josh

[toc] | [prev] | [next] | [standalone]

#1525250 — Re: [PATCH 05/16] efi: Add EFI_SECURE_BOOT bit

On 18 November 2016 at 11:58, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> On Thu, Nov 17, 2016 at 4:58 PM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> On 16 November 2016 at 21:47, David Howells <dhowells@redhat.com> wrote:
>>> From: Josh Boyer <jwboyer@fedoraproject.org>
>>>
>>> UEFI machines can be booted in Secure Boot mode.  Add a EFI_SECURE_BOOT bit
>>> for use with efi_enabled.
>>>
>>> Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
>>> Signed-off-by: David Howells <dhowells@redhat.com>
>>> ---
>>>
>>>  arch/x86/kernel/setup.c |    1 +
>>>  include/linux/efi.h     |    1 +
>>>  2 files changed, 2 insertions(+)
>>>
>>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>>> index 9521acce8378..539f29587712 100644
>>> --- a/arch/x86/kernel/setup.c
>>> +++ b/arch/x86/kernel/setup.c
>>> @@ -1164,6 +1164,7 @@ void __init setup_arch(char **cmdline_p)
>>>         if (boot_params.secure_boot &&
>>>             IS_ENABLED(CONFIG_EFI_SECURE_BOOT_LOCK_DOWN)) {
>>>                 lock_kernel_down();
>>> +               set_bit(EFI_SECURE_BOOT, &efi.flags);
>>
>> Why is this x86 only? And why is this bit only set if
>
> Because it was initially written like 3 years ago before ARM even had
> UEFI.  Needs a refresh.
>

Ah ok. I missed that part.

In any case, we have been working very hard over the past couple of
years to move all the UEFI stuff out of arch/x86, except for the
pieces that *really* belong there. For this series, that means that a
fair share of the changes will need to be reworked and moved under
drivers/firmware/efi. Note that that also means you cannot use L""
string literals anymore, since arm64's UEFI stub is linked into the
kernel proper, and the wide character formats are incompatible between
UEFI and the wide char handling that occurs under fs/. Please check
the existing secureboot_enabled() function Lukas referred to as an
example how to emit wide string literals instead.

>> CONFIG_EFI_SECURE_BOOT_LOCK_DOWN is enabled?
>
> That part is new and something David added.  Probably not necessary.
>

Regardless of anything else,  think is is useful to have a EFI_xx flag
that is always set when secure boot is enabled.

[toc] | [prev] | [next] | [standalone]

#1525571 — Re: [PATCH 05/16] efi: Add EFI_SECURE_BOOT bit

Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

> > @@ -1164,6 +1164,7 @@ void __init setup_arch(char **cmdline_p)
> >         if (boot_params.secure_boot &&
> >             IS_ENABLED(CONFIG_EFI_SECURE_BOOT_LOCK_DOWN)) {
> >                 lock_kernel_down();
> > +               set_bit(EFI_SECURE_BOOT, &efi.flags);
> 
> Why is this x86 only?

It probably doesn't really need to be, but that's what the patches I ported
do.

> And why is this bit only set if CONFIG_EFI_SECURE_BOOT_LOCK_DOWN is enabled?

Actually, the EFI_SECURE_BOOT bit should probably be set outside of that
portion of the if-condition.

David

[toc] | [prev] | [next] | [standalone]

#1523869 — [PATCH 07/16] kexec: Disable at runtime if the kernel is locked down

From: Matthew Garrett <matthew.garrett@nebula.com>

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 kexec_file_load() which can check for a signature on the
image to be booted.

Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
---

 kernel/kexec.c |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/kernel/kexec.c b/kernel/kexec.c
index 980936a90ee6..c6aa4620d1bf 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -12,6 +12,7 @@
 #include <linux/mm.h>
 #include <linux/file.h>
 #include <linux/kexec.h>
+#include <linux/security.h>
 #include <linux/mutex.h>
 #include <linux/list.h>
 #include <linux/syscalls.h>
@@ -194,6 +195,13 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
 		return -EPERM;
 
 	/*
+	 * kexec can be used to circumvent module loading restrictions, so
+	 * prevent loading in that case
+	 */
+	if (kernel_is_locked_down())
+		return -EPERM;
+
+	/*
 	 * Verify we have a legal set of flags
 	 * This leaves us room for future extensions.
 	 */

[toc] | [prev] | [next] | [standalone]

#1523870 — [PATCH 08/16] Copy secure_boot flag in boot params across kexec reboot

From: Dave Young <dyoung@redhat.com>

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 protections provided
by secure boot.

Adding a patch to fix this by retain the secure_boot flag in original
kernel.

secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the
stub.  Fixing this issue by copying secure_boot flag across kexec reboot.

Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
---

 arch/x86/kernel/kexec-bzimage64.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
index 3407b148c240..b843a4e57a9b 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -179,6 +179,7 @@ setup_efi_state(struct boot_params *params, unsigned long params_load_addr,
 	if (efi_enabled(EFI_OLD_MEMMAP))
 		return 0;
 
+	params->secure_boot = boot_params.secure_boot;
 	ei->efi_loader_signature = current_ei->efi_loader_signature;
 	ei->efi_systab = current_ei->efi_systab;
 	ei->efi_systab_hi = current_ei->efi_systab_hi;

[toc] | [prev] | [next] | [standalone]

#1523871 — [PATCH 12/16] ACPI: Limit access to custom_method when the kernel is locked down

From: Matthew Garrett <matthew.garrett@nebula.com>

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-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
---

 drivers/acpi/custom_method.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/acpi/custom_method.c b/drivers/acpi/custom_method.c
index c68e72414a67..e4d721c330c0 100644
--- a/drivers/acpi/custom_method.c
+++ b/drivers/acpi/custom_method.c
@@ -29,6 +29,9 @@ static ssize_t cm_write(struct file *file, const char __user * user_buf,
 	struct acpi_table_header table;
 	acpi_status status;
 
+	if (kernel_is_locked_down())
+		return -EPERM;
+
 	if (!(*ppos)) {
 		/* parse the table header to get the table length */
 		if (count <= sizeof(struct acpi_table_header))

[toc] | [prev] | [next] | [standalone]

#1523872 — [PATCH 03/16] efi: Disable secure boot if shim is in insecure mode

From: Josh Boyer <jwboyer@fedoraproject.org>

A user can manually tell the shim boot loader to disable validation of
images it loads.  When a user does this, it creates a UEFI variable called
MokSBState that does not have the runtime attribute set.  Given that the
user explicitly disabled validation, we can honor that and not enable
secure boot mode if that variable is set.

Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: David Howells <dhowells@redhat.com>
---

 arch/x86/boot/compressed/eboot.c |   20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 17b376596c96..2729a3844673 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -540,8 +540,9 @@ static void setup_efi_pci(struct boot_params *params)
 
 static int get_secure_boot(void)
 {
-	u8 sb, setup;
+	u8 sb, setup, moksbstate;
 	unsigned long datasize = sizeof(sb);
+	u32 attr;
 	efi_guid_t var_guid = EFI_GLOBAL_VARIABLE_GUID;
 	efi_status_t status;
 
@@ -565,6 +566,23 @@ static int get_secure_boot(void)
 	if (setup == 1)
 		return 0;
 
+	/* See if a user has put shim into insecure_mode.  If so, and the variable
+	 * doesn't have the runtime attribute set, we might as well honor that.
+	 */
+	var_guid = EFI_SHIM_LOCK_GUID;
+	status = efi_early->call((unsigned long)sys_table->runtime->get_variable,
+				L"MokSBState", &var_guid, &attr, &datasize,
+				&moksbstate);
+
+	/* If it fails, we don't care why.  Default to secure */
+	if (status != EFI_SUCCESS)
+		return 1;
+
+	if (!(attr & EFI_VARIABLE_RUNTIME_ACCESS)) {
+		if (moksbstate == 1)
+			return 0;
+	}
+
 	return 1;
 }
 

[toc] | [prev] | [next] | [standalone]

#1523873 — [PATCH 04/16] efi: Lock down the kernel if booted in secure boot mode

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 lock down the kernel - which includes requiring validly signed
modules - if the kernel is secure-booted.

Signed-off-by: David Howells <dhowells@redhat.com>
---

 arch/x86/Kconfig        |   12 ++++++++++++
 arch/x86/kernel/setup.c |    7 +++++++
 kernel/module.c         |    2 +-
 3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bada636d1065..5b19997d88d0 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1786,6 +1786,18 @@ config EFI_MIXED
 
 	   If unsure, say N.
 
+config EFI_SECURE_BOOT_LOCK_DOWN
+	def_bool n
+	depends on EFI
+	prompt "Lock down the kernel when UEFI Secure Boot is enabled"
+	---help---
+	  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 and that
+	  userspace is prevented from directly changing the running kernel
+	  image.  Say Y here to automatically lock down the kernel when a
+	  system boots with UEFI Secure Boot enabled.
+
 config SECCOMP
 	def_bool y
 	prompt "Enable seccomp to safely compute untrusted bytecode"
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 9c337b0e8ba7..9521acce8378 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -69,6 +69,7 @@
 #include <linux/crash_dump.h>
 #include <linux/tboot.h>
 #include <linux/jiffies.h>
+#include <linux/security.h>
 
 #include <video/edid.h>
 
@@ -1160,6 +1161,12 @@ void __init setup_arch(char **cmdline_p)
 
 	io_delay_init();
 
+	if (boot_params.secure_boot &&
+	    IS_ENABLED(CONFIG_EFI_SECURE_BOOT_LOCK_DOWN)) {
+		lock_kernel_down();
+		pr_info("Secure boot enabled\n");
+	}
+
 	/*
 	 * Parse the ACPI tables for possible boot-time SMP configuration.
 	 */
diff --git a/kernel/module.c b/kernel/module.c
index f57dd63186e6..2a021c340efd 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2744,7 +2744,7 @@ static int module_sig_check(struct load_info *info, int flags)
 	}
 
 	/* Not having a signature is only an error if we're strict. */
-	if (err == -ENOKEY && !sig_enforce)
+	if (err == -ENOKEY && !sig_enforce && !kernel_is_locked_down())
 		err = 0;
 
 	return err;

[toc] | [prev] | [next] | [standalone]

#1523874 — [PATCH 11/16] x86: Lock down IO port access when the kernel is locked down

From: Matthew Garrett <matthew.garrett@nebula.com>

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 arbitrary DMA, so lock
it down by default.

Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
---

 arch/x86/kernel/ioport.c |    5 +++--
 drivers/char/mem.c       |    4 ++++
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index 589b3193f102..2ee24e9ff6d8 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -15,6 +15,7 @@
 #include <linux/thread_info.h>
 #include <linux/syscalls.h>
 #include <linux/bitmap.h>
+#include <linux/security.h>
 #include <asm/syscalls.h>
 
 /*
@@ -28,7 +29,7 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int turn_on)
 
 	if ((from + num <= from) || (from + num > IO_BITMAP_BITS))
 		return -EINVAL;
-	if (turn_on && !capable(CAP_SYS_RAWIO))
+	if (turn_on && (!capable(CAP_SYS_RAWIO) || kernel_is_locked_down()))
 		return -EPERM;
 
 	/*
@@ -108,7 +109,7 @@ SYSCALL_DEFINE1(iopl, unsigned int, level)
 		return -EINVAL;
 	/* Trying to gain more privileges? */
 	if (level > old) {
-		if (!capable(CAP_SYS_RAWIO))
+		if (!capable(CAP_SYS_RAWIO) || kernel_is_locked_down())
 			return -EPERM;
 	}
 	regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) |
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 5bb1985ec484..17e22cb2db14 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -28,6 +28,7 @@
 #include <linux/export.h>
 #include <linux/io.h>
 #include <linux/uio.h>
+#include <linux/security.h>
 
 #include <linux/uaccess.h>
 
@@ -580,6 +581,9 @@ static ssize_t write_port(struct file *file, const char __user *buf,
 	unsigned long i = *ppos;
 	const char __user *tmp = buf;
 
+	if (kernel_is_locked_down())
+		return -EPERM;
+
 	if (!access_ok(VERIFY_READ, buf, count))
 		return -EFAULT;
 	while (count-- > 0 && i < 65536) {

[toc] | [prev] | [next] | [standalone]

#1523875 — [PATCH 06/16] Add a sysrq option to exit secure boot mode

From: Kyle McMartin <kyle@redhat.com>

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: David Howells <dhowells@redhat.com>
---

 arch/x86/Kconfig            |   10 ++++++++++
 arch/x86/kernel/setup.c     |   31 +++++++++++++++++++++++++++++++
 drivers/input/misc/uinput.c |    1 +
 drivers/tty/sysrq.c         |   19 +++++++++++++------
 include/linux/input.h       |    5 +++++
 include/linux/sysrq.h       |    8 +++++++-
 kernel/debug/kdb/kdb_main.c |    2 +-
 7 files changed, 68 insertions(+), 8 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5b19997d88d0..c2b481b59931 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1798,6 +1798,16 @@ config EFI_SECURE_BOOT_LOCK_DOWN
 	  image.  Say Y here to automatically lock down the kernel when a
 	  system boots with UEFI Secure Boot enabled.
 
+config EFI_ALLOW_SECURE_BOOT_EXIT
+	def_bool n
+	depends on EFI_SECURE_BOOT_LOCK_DOWN && MAGIC_SYSRQ
+	select ALLOW_LOCKDOWN_LIFT
+	prompt "Allow secure boot mode to be exited with SysRq+x on a keyboard"
+	---help---
+	  Allow secure boot mode to be exited and the kernel lockdown lifted by
+	  typing SysRq+x on a keyboard attached to the system (not permitted
+	  through procfs).
+
 config SECCOMP
 	def_bool y
 	prompt "Enable seccomp to safely compute untrusted bytecode"
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 539f29587712..89786c2270bd 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -71,6 +71,11 @@
 #include <linux/jiffies.h>
 #include <linux/security.h>
 
+#include <linux/fips.h>
+#include <linux/cred.h>
+#include <linux/sysrq.h>
+#include <linux/init_task.h>
+
 #include <video/edid.h>
 
 #include <asm/mtrr.h>
@@ -1291,6 +1296,32 @@ void __init i386_reserve_resources(void)
 
 #endif /* CONFIG_X86_32 */
 
+#ifdef CONFIG_EFI_ALLOW_SECURE_BOOT_EXIT
+
+static void sysrq_handle_secure_boot(int key)
+{
+	if (!efi_enabled(EFI_SECURE_BOOT))
+		return;
+
+	pr_info("Secure boot disabled\n");
+	lift_kernel_lockdown();
+}
+static struct sysrq_key_op secure_boot_sysrq_op = {
+	.handler	=	sysrq_handle_secure_boot,
+	.help_msg	=	"unSB(x)",
+	.action_msg	=	"Disabling Secure Boot restrictions",
+	.enable_mask	=	SYSRQ_DISABLE_USERSPACE,
+};
+static int __init secure_boot_sysrq(void)
+{
+	if (efi_enabled(EFI_SECURE_BOOT))
+		register_sysrq_key('x', &secure_boot_sysrq_op);
+	return 0;
+}
+late_initcall(secure_boot_sysrq);
+#endif /*CONFIG_EFI_ALLOW_SECURE_BOOT_EXIT*/
+
+
 static struct notifier_block kernel_offset_notifier = {
 	.notifier_call = dump_kernel_offset
 };
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index 92595b98e7ed..894ed3f74f04 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -379,6 +379,7 @@ static int uinput_allocate_device(struct uinput_device *udev)
 	if (!udev->dev)
 		return -ENOMEM;
 
+	udev->dev->flags |= INPUTDEV_FLAGS_SYNTHETIC;
 	udev->dev->event = uinput_dev_event;
 	input_set_drvdata(udev->dev, udev);
 
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 52bbd27e93ae..72f46a1a2ce7 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -479,6 +479,7 @@ static struct sysrq_key_op *sysrq_key_table[36] = {
 	/* x: May be registered on mips for TLB dump */
 	/* x: May be registered on ppc/powerpc for xmon */
 	/* x: May be registered on sparc64 for global PMU dump */
+	/* x: May be registered on x86_64 for disabling secure boot */
 	NULL,				/* x */
 	/* y: May be registered on sparc64 for global register dump */
 	NULL,				/* y */
@@ -522,7 +523,7 @@ static void __sysrq_put_key_op(int key, struct sysrq_key_op *op_p)
                 sysrq_key_table[i] = op_p;
 }
 
-void __handle_sysrq(int key, bool check_mask)
+void __handle_sysrq(int key, unsigned int from)
 {
 	struct sysrq_key_op *op_p;
 	int orig_log_level;
@@ -542,11 +543,15 @@ void __handle_sysrq(int key, bool check_mask)
 
         op_p = __sysrq_get_key_op(key);
         if (op_p) {
+		/* Ban synthetic events from some sysrq functionality */
+		if ((from == SYSRQ_FROM_PROC || from == SYSRQ_FROM_SYNTHETIC) &&
+		    op_p->enable_mask & SYSRQ_DISABLE_USERSPACE)
+			printk("This sysrq operation is disabled from userspace.\n");
 		/*
 		 * Should we check for enabled operations (/proc/sysrq-trigger
 		 * should not) and is the invoked operation enabled?
 		 */
-		if (!check_mask || sysrq_on_mask(op_p->enable_mask)) {
+		if (from == SYSRQ_FROM_KERNEL || sysrq_on_mask(op_p->enable_mask)) {
 			pr_cont("%s\n", op_p->action_msg);
 			console_loglevel = orig_log_level;
 			op_p->handler(key);
@@ -578,7 +583,7 @@ void __handle_sysrq(int key, bool check_mask)
 void handle_sysrq(int key)
 {
 	if (sysrq_on())
-		__handle_sysrq(key, true);
+		__handle_sysrq(key, SYSRQ_FROM_KERNEL);
 }
 EXPORT_SYMBOL(handle_sysrq);
 
@@ -659,7 +664,7 @@ static void sysrq_do_reset(unsigned long _state)
 static void sysrq_handle_reset_request(struct sysrq_state *state)
 {
 	if (state->reset_requested)
-		__handle_sysrq(sysrq_xlate[KEY_B], false);
+		__handle_sysrq(sysrq_xlate[KEY_B], SYSRQ_FROM_KERNEL);
 
 	if (sysrq_reset_downtime_ms)
 		mod_timer(&state->keyreset_timer,
@@ -810,8 +815,10 @@ static bool sysrq_handle_keypress(struct sysrq_state *sysrq,
 
 	default:
 		if (sysrq->active && value && value != 2) {
+			int from = sysrq->handle.dev->flags & INPUTDEV_FLAGS_SYNTHETIC ?
+					SYSRQ_FROM_SYNTHETIC : 0;
 			sysrq->need_reinject = false;
-			__handle_sysrq(sysrq_xlate[code], true);
+			__handle_sysrq(sysrq_xlate[code], from);
 		}
 		break;
 	}
@@ -1095,7 +1102,7 @@ static ssize_t write_sysrq_trigger(struct file *file, const char __user *buf,
 
 		if (get_user(c, buf))
 			return -EFAULT;
-		__handle_sysrq(c, false);
+		__handle_sysrq(c, SYSRQ_FROM_PROC);
 	}
 
 	return count;
diff --git a/include/linux/input.h b/include/linux/input.h
index a65e3b24fb18..8b0357175049 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -42,6 +42,7 @@ struct input_value {
  * @phys: physical path to the device in the system hierarchy
  * @uniq: unique identification code for the device (if device has it)
  * @id: id of the device (struct input_id)
+ * @flags: input device flags (SYNTHETIC, etc.)
  * @propbit: bitmap of device properties and quirks
  * @evbit: bitmap of types of events supported by the device (EV_KEY,
  *	EV_REL, etc.)
@@ -124,6 +125,8 @@ struct input_dev {
 	const char *uniq;
 	struct input_id id;
 
+	unsigned int flags;
+
 	unsigned long propbit[BITS_TO_LONGS(INPUT_PROP_CNT)];
 
 	unsigned long evbit[BITS_TO_LONGS(EV_CNT)];
@@ -190,6 +193,8 @@ struct input_dev {
 };
 #define to_input_dev(d) container_of(d, struct input_dev, dev)
 
+#define	INPUTDEV_FLAGS_SYNTHETIC	0x000000001
+
 /*
  * Verify that we are in sync with input_device_id mod_devicetable.h #defines
  */
diff --git a/include/linux/sysrq.h b/include/linux/sysrq.h
index 387fa7d05c98..f7c52a9ea394 100644
--- a/include/linux/sysrq.h
+++ b/include/linux/sysrq.h
@@ -28,6 +28,8 @@
 #define SYSRQ_ENABLE_BOOT	0x0080
 #define SYSRQ_ENABLE_RTNICE	0x0100
 
+#define SYSRQ_DISABLE_USERSPACE	0x00010000
+
 struct sysrq_key_op {
 	void (*handler)(int);
 	char *help_msg;
@@ -42,8 +44,12 @@ struct sysrq_key_op {
  * are available -- else NULL's).
  */
 
+#define SYSRQ_FROM_KERNEL	0x0001
+#define SYSRQ_FROM_PROC		0x0002
+#define SYSRQ_FROM_SYNTHETIC	0x0004
+
 void handle_sysrq(int key);
-void __handle_sysrq(int key, bool check_mask);
+void __handle_sysrq(int key, unsigned int from);
 int register_sysrq_key(int key, struct sysrq_key_op *op);
 int unregister_sysrq_key(int key, struct sysrq_key_op *op);
 struct sysrq_key_op *__sysrq_get_key_op(int key);
diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
index 2a20c0dfdafc..d46d2e18a889 100644
--- a/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -1968,7 +1968,7 @@ static int kdb_sr(int argc, const char **argv)
 		return KDB_ARGCOUNT;
 
 	kdb_trap_printk++;
-	__handle_sysrq(*argv[1], check_mask);
+	__handle_sysrq(*argv[1], check_mask ? SYSRQ_FROM_KERNEL : 0);
 	kdb_trap_printk--;
 
 	return 0;

[toc] | [prev] | [next] | [standalone]

#1523895

Whether it's a good idea aside

You need to filter or lock down kernel module options because a lot of
modules let you set the I/O port or similar (eg mmio) which means you can
hack the entire machine with say the 8250 driver just by using it with an
mmio of the right location to patch the secure state to zero just by
getting the ability to write to the modules conf file.

Without that at least fixed I don't see the point in merging this. Either
we don't do it (which given the level of security the current Linux
kernel provides, and also all the golden key messups from elsewhere might
be the honest approach), or at least try and do the job right.

Less security is better than fake security. If you've got less security
your take appropriate precautions. If you rely on fake security you don't.

The two other nasty cases you miss should be fine for x86 secure boot -
but maybe not for secure boot in general. That is firmware loading and
initial firewire state. Both should be fine on any 'secure' boot PC.


Alan

[toc] | [prev] | [next] | [standalone]

#1527008

On 16 November 2016 at 23:27, One Thousand Gnomes
<gnomes@lxorguk.ukuu.org.uk> wrote:
> Whether it's a good idea aside
>
> You need to filter or lock down kernel module options because a lot of
> modules let you set the I/O port or similar (eg mmio) which means you can
> hack the entire machine with say the 8250 driver just by using it with an
> mmio of the right location to patch the secure state to zero just by
> getting the ability to write to the modules conf file.
>

This applies equally to the kernel command line, and given that we
cannot authenticate it, we should whitelist params that we know to be
safe, and filter out all others. A similar concern exists for the
device tree on ARM/arm64, and we already disable the DTB loader in the
UEFI stub if secure boot is enabled.

> Without that at least fixed I don't see the point in merging this. Either
> we don't do it (which given the level of security the current Linux
> kernel provides, and also all the golden key messups from elsewhere might
> be the honest approach), or at least try and do the job right.
>
> Less security is better than fake security. If you've got less security
> your take appropriate precautions. If you rely on fake security you don't.
>

In general, I think kernel hardening is an important topic, and this
series covers many cases where userland APIs can be subverted to
manipulate the state of the kernel in ways that weren't intended.
However, it would be naive to think that the series covers all such
cases, and I don't think that is what the authors intend to convey.

[toc] | [prev] | [next] | [standalone]

#1523906

On Wed, Nov 16, 2016 at 3:47 PM, David Howells <dhowells@redhat.com> 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:
>

Bit surprised to see this.  Not that I am opposed to the patches
themselves.  These were pulled into my tree as the first step towards
consolidating the implementation used for secure boot, and I know
there is interest in using large parts outside of a secure boot
context as well, but there were a few changes to be made after our
discussions in Santa Fe. Those are going into
http://git.kernel.org/cgit/linux/kernel/git/jforbes/linux.git/log/?h=lockdown
I am completely happy to submit those changes as separate patches if
people want to take these.  They do actually work, and are being
shipped and supported by multiple distributions at this point.

Justin

[toc] | [prev] | [next] | [standalone]

#1527249 — Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

On Mon, Nov 21, 2016 at 11:10:52PM +0000, David Howells wrote:
> One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote:
> 
> > You need to filter or lock down kernel module options because a lot of
> > modules let you set the I/O port or similar (eg mmio) which means you can
> > hack the entire machine with say the 8250 driver just by using it with an
> > mmio of the right location to patch the secure state to zero just by
> > getting the ability to write to the modules conf file.
> 
> Is the attached patch the right sort of idea?  [Note that I haven't actually
> compiled most of these drivers to check my changes yet.]
> 
> David
> ---
> commit 8613a9655dad98c3358d82a9c4310cebdcb852ae
> Author: David Howells <dhowells@redhat.com>
> Date:   Mon Nov 21 22:43:27 2016 +0000
> 
>     Lock down drivers that can have io ports, io mem, irqs and dma changed
>     
>     Lock down drivers that can have io ports, io mem, irqs and dma channels
>     changed so that they can't be used to cause hardware to access the kernel
>     image.
>     
>     Notes:
>     
>      (1) module_isa_driver() gets an extra parameter that, if true, will cause
>          the module load to be rejected if the kernel is locked down.
>     
>      (2) module_driver() calls module_lockdown_check() to ask if the module
>          load should be rejected if the kernel is locked down.  This is a macro
>          that should be #undef'd and then redefined right before
>          module_driver() is called.
>     
>      (3) module_pci_driver() is a wrapper around module_driver(), so the same
>          macro is used as in (2).
>     
>      (4) A number of drivers use parport 'ports' - so I haven't touched those.

You might also need to disable CIS overrides and CIS firmware loading for PCMCIA
drivers, I presume. That needs two changes:

	- Abort in drivers/pcmcia/ds.c::pcmcia_load_firmware() or disable
	  the CONFIG_PCMCIA_LOAD_CIS config option permanently.

	- Abort in drivers/pcmcia/cistpl.c::pccard_store_cis() or remove
	  write access to the "cis" file in
	  drivers/pcmcia/cistpl.c::pccard_cis_attr

Best,
	Dominik

[toc] | [prev] | [next] | [standalone]

#1528378 — Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

Dominik Brodowski <linux@dominikbrodowski.net> wrote:

> You might also need to disable CIS overrides and CIS firmware loading for
> PCMCIA drivers, I presume. That needs two changes:
> 
> 	- Abort in drivers/pcmcia/ds.c::pcmcia_load_firmware() or disable
> 	  the CONFIG_PCMCIA_LOAD_CIS config option permanently.

This really ought to be handled through signature checking in
request_firmware().

> 	- Abort in drivers/pcmcia/cistpl.c::pccard_store_cis() or remove
> 	  write access to the "cis" file in
> 	  drivers/pcmcia/cistpl.c::pccard_cis_attr

What is that doing?  Allowing the device to be reconfigured?

David

[toc] | [prev] | [next] | [standalone]

#1528708 — Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

On Wed, Nov 23, 2016 at 12:58:26PM +0000, David Howells wrote:
> Dominik Brodowski <linux@dominikbrodowski.net> wrote:
> 
> > You might also need to disable CIS overrides and CIS firmware loading for
> > PCMCIA drivers, I presume. That needs two changes:
> > 
> > 	- Abort in drivers/pcmcia/ds.c::pcmcia_load_firmware() or disable
> > 	  the CONFIG_PCMCIA_LOAD_CIS config option permanently.
> 
> This really ought to be handled through signature checking in
> request_firmware().
> 
> > 	- Abort in drivers/pcmcia/cistpl.c::pccard_store_cis() or remove
> > 	  write access to the "cis" file in
> > 	  drivers/pcmcia/cistpl.c::pccard_cis_attr
> 
> What is that doing?  Allowing the device to be reconfigured?

Exactly. It is a different interface for updating the firmware -- which
includes ioports etc. In theory, any access should be limited to areas which
are registered to the bridge devices. But you never know...

Best
	Dominik

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web