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

2019-03-07 Thread Matthew Garrett
On Thu, Mar 7, 2019 at 6:55 AM Alan Cox  wrote:
>
> On Wed,  6 Mar 2019 15:58:55 -0800
> Matthew Garrett  wrote:
>
> > From: Josh Boyer 
> >
> > There is currently no way to verify the resume image when returning
> > from hibernate.  This might compromise the signed modules trust model,
> > so until we can work with signed hibernate images we disable it when the
> > kernel is locked down.
>
> That one is a bit worrying since whilst the other stuff may be useful in
> some business environments, mandatory hibernate not suspend to RAM is a
> common corporate IT policy because of concerns about theft and recovery
> of memory contents.

Suse have a solution for this that I'd like to see pushed again, but
from a practical perspective enterprise distributions have been
shipping this for some time without significant obvious customer
complaint.


Re: [PULL REQUEST] Kernel lockdown patches for 5.2

2019-03-06 Thread Matthew Garrett
On Wed, Mar 6, 2019 at 7:56 PM Mimi Zohar  wrote:
> The kexec and kernel modules patches in this patch set continues to
> ignore IMA.  This patch set should up front either provide an
> alternative solution to coordinate the different signature
> verification methods or rely on the architecture specific policy for
> that coordination.

Hi Mimi,

I'm working on a patch for this at the moment which can then be added
to either patchset. Is there a tree that contains the proposed Power
architecture policy? I want to make sure I don't accidentally end up
depending on anything x86.


Re: [PATCH 02/27] Add a SysRq option to lift kernel lockdown

2019-03-06 Thread Matthew Garrett
On Wed, Mar 6, 2019 at 4:10 PM Randy Dunlap  wrote:
>
> On 3/6/19 3:58 PM, Matthew Garrett wrote:
> > From: Kyle McMartin 
> >
> > Make an option to provide a sysrq key that will lift the kernel lockdown,
> > thereby allowing the running kernel image to be accessed and modified.
>
> You still need to document this in Documentation/admin-guide/sysrq.rst,
> like I mentioned last week.

Hm.. On reflection this patch doesn't make much sense without the
automatic lockdown enable functionality, so I'll just drop it from the
patchset instead. Thanks!


[PATCH 01/27] Add the ability to lock down access to the running kernel image

2019-03-06 Thread Matthew Garrett
From: David Howells 

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 registers and disallowing hibernation.

Signed-off-by: David Howells 
Acked-by: James Morris 
Signed-off-by: Matthew Garrett 
---
 include/linux/kernel.h   | 17 
 include/linux/security.h |  9 +-
 security/Kconfig | 15 ++
 security/Makefile|  3 ++
 security/lock_down.c | 59 
 5 files changed, 102 insertions(+), 1 deletion(-)
 create mode 100644 security/lock_down.c

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 8f0e68e250a7..833bf32ce4e6 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -340,6 +340,23 @@ static inline void refcount_error_report(struct pt_regs 
*regs, const char *err)
 { }
 #endif
 
+#ifdef CONFIG_LOCK_DOWN_KERNEL
+extern bool __kernel_is_locked_down(const char *what, bool first);
+#else
+static inline bool __kernel_is_locked_down(const char *what, bool first)
+{
+   return false;
+}
+#endif
+
+#define kernel_is_locked_down(what)\
+   ({  \
+   static bool message_given;  \
+   bool locked_down = __kernel_is_locked_down(what, 
!message_given); \
+   message_given = true;   \
+   locked_down;\
+   })
+
 /* Internal, do not use. */
 int __must_check _kstrtoul(const char *s, unsigned int base, unsigned long 
*res);
 int __must_check _kstrtol(const char *s, unsigned int base, long *res);
diff --git a/include/linux/security.h b/include/linux/security.h
index 13537a49ae97..b290946341a4 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -1798,5 +1798,12 @@ static inline void security_bpf_prog_free(struct 
bpf_prog_aux *aux)
 #endif /* CONFIG_SECURITY */
 #endif /* CONFIG_BPF_SYSCALL */
 
-#endif /* ! __LINUX_SECURITY_H */
+#ifdef CONFIG_LOCK_DOWN_KERNEL
+extern void __init init_lockdown(void);
+#else
+static inline void __init init_lockdown(void)
+{
+}
+#endif
 
+#endif /* ! __LINUX_SECURITY_H */
diff --git a/security/Kconfig b/security/Kconfig
index 1d6463fb1450..47dc3403b5af 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -229,6 +229,21 @@ config STATIC_USERMODEHELPER_PATH
  If you wish for all usermode helper programs to be disabled,
  specify an empty string here (i.e. "").
 
+config LOCK_DOWN_KERNEL
+   bool "Allow the kernel to be 'locked down'"
+   help
+ Allow the kernel to be locked down. If lockdown support is enabled
+ and activated, the kernel will impose additional restrictions
+ intended to prevent uid 0 from being able to modify the running
+ kernel. This may break userland applications that rely on low-level
+ access to hardware.
+
+config LOCK_DOWN_KERNEL_FORCE
+bool "Enable kernel lockdown mode automatically"
+depends on LOCK_DOWN_KERNEL
+help
+  Enable the kernel lock down functionality automatically at boot.
+
 source "security/selinux/Kconfig"
 source "security/smack/Kconfig"
 source "security/tomoyo/Kconfig"
diff --git a/security/Makefile b/security/Makefile
index c598b904938f..5ff090149c88 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -32,3 +32,6 @@ obj-$(CONFIG_CGROUP_DEVICE)   += device_cgroup.o
 # Object integrity file lists
 subdir-$(CONFIG_INTEGRITY) += integrity
 obj-$(CONFIG_INTEGRITY)+= integrity/
+
+# Allow the kernel to be locked down
+obj-$(CONFIG_LOCK_DOWN_KERNEL) += lock_down.o
diff --git a/security/lock_down.c b/security/lock_down.c
new file mode 100644
index ..13a8228c1034
--- /dev/null
+++ b/security/lock_down.c
@@ -0,0 +1,59 @@
+/* Lock down the kernel
+ *
+ * Copyright (C) 2016 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowe...@redhat.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public Licence
+ * as published by the Free Software Foundation; either version
+ * 2 of the Licence, or (at your option) any later version.
+ */
+
+#include 
+#include 
+
+static __ro_after_init bool kernel_locked_down;
+
+/*
+ * Put the kernel into lock-down mode.
+ */
+static void __init lock_kernel_down(const char *where)
+{
+   if (!kernel_locked_down) {
+   kernel_locked_down = true;
+   pr_notice("Kernel is locked down from %s; see man 
kernel_lockdown.7\n",
+ 

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

2019-03-06 Thread Matthew Garrett
From: Josh Boyer 

There is currently no way to verify the resume image when returning
from hibernate.  This might compromise the signed modules trust model,
so until we can work with signed hibernate images we disable it when the
kernel is locked down.

Signed-off-by: Josh Boyer 
Signed-off-by: David Howells 
Reviewed-by: "Lee, Chun-Yi" 
cc: linux...@vger.kernel.org
Signed-off-by: Matthew Garrett 
---
 kernel/power/hibernate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index abef759de7c8..802795becb88 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -70,7 +70,7 @@ static const struct platform_hibernation_ops *hibernation_ops;
 
 bool hibernation_available(void)
 {
-   return (nohibernate == 0);
+   return nohibernate == 0 && !kernel_is_locked_down("Hibernation");
 }
 
 /**
-- 
2.21.0.352.gf09ad66450-goog



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

2019-03-06 Thread Matthew Garrett
From: Linn Crosetto 

ACPI provides an error injection mechanism, EINJ, for debugging and testing
the ACPI Platform Error Interface (APEI) and other RAS features.  If
supported by the firmware, ACPI specification 5.0 and later provide for a
way to specify a physical memory address to which to inject the error.

Injecting errors through EINJ can produce errors which to the platform are
indistinguishable from real hardware errors.  This can have undesirable
side-effects, such as causing the platform to mark hardware as needing
replacement.

While it does not provide a method to load unauthenticated privileged code,
the effect of these errors may persist across reboots and affect trust in
the underlying hardware, so disable error injection through EINJ if
the kernel is locked down.

Signed-off-by: Linn Crosetto 
Signed-off-by: David Howells 
Reviewed-by: "Lee, Chun-Yi" 
cc: linux-a...@vger.kernel.org
Signed-off-by: Matthew Garrett 
---
 drivers/acpi/apei/einj.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c
index fcccbfdbdd1a..9fe6bbab2e7d 100644
--- a/drivers/acpi/apei/einj.c
+++ b/drivers/acpi/apei/einj.c
@@ -518,6 +518,9 @@ static int einj_error_inject(u32 type, u32 flags, u64 
param1, u64 param2,
int rc;
u64 base_addr, size;
 
+   if (kernel_is_locked_down("ACPI error injection"))
+   return -EPERM;
+
/* If user manually set "flags", make sure it is legal */
if (flags && (flags &
~(SETWA_FLAGS_APICID|SETWA_FLAGS_MEM|SETWA_FLAGS_PCIE_SBDF)))
-- 
2.21.0.352.gf09ad66450-goog



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

2019-03-06 Thread Matthew Garrett
From: Matthew Garrett 

IO port access would permit users to gain access to PCI configuration
registers, which in turn (on a lot of hardware) give access to MMIO
register space. This would potentially permit root to trigger arbitrary
DMA, so lock it down by default.

This also implicitly locks down the KDADDIO, KDDELIO, KDENABIO and
KDDISABIO console ioctls.

Signed-off-by: Matthew Garrett 
Signed-off-by: David Howells 
Reviewed-by: Thomas Gleixner 
Reviewed-by: "Lee, Chun-Yi" 
cc: x...@kernel.org
Signed-off-by: Matthew Garrett 
---
 arch/x86/kernel/ioport.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index 0fe1c8782208..abc702a6ae9c 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -31,7 +31,8 @@ long ksys_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("ioperm")))
return -EPERM;
 
/*
@@ -126,7 +127,8 @@ 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("iopl"))
return -EPERM;
}
regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) |
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 27/27] lockdown: Print current->comm in restriction messages

2019-03-06 Thread Matthew Garrett
From: David Howells 

Print the content of current->comm in messages generated by lockdown to
indicate a restriction that was hit.  This makes it a bit easier to find
out what caused the message.

The message now patterned something like:

Lockdown: :  is restricted; see man kernel_lockdown.7

Signed-off-by: David Howells 
Signed-off-by: Matthew Garrett 
---
 security/lock_down.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/security/lock_down.c b/security/lock_down.c
index cfbc2c39712b..5243b55b3c1f 100644
--- a/security/lock_down.c
+++ b/security/lock_down.c
@@ -58,8 +58,8 @@ void __init init_lockdown(void)
 bool __kernel_is_locked_down(const char *what, bool first)
 {
if (what && first && kernel_locked_down)
-   pr_notice("Lockdown: %s is restricted; see man 
kernel_lockdown.7\n",
- what);
+   pr_notice("Lockdown: %s: %s is restricted; see man 
kernel_lockdown.7\n",
+ current->comm, what);
return kernel_locked_down;
 }
 EXPORT_SYMBOL(__kernel_is_locked_down);
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 19/27] Lock down TIOCSSERIAL

2019-03-06 Thread Matthew Garrett
From: David Howells 

Lock down TIOCSSERIAL as that can be used to change the ioport and irq
settings on a serial port.  This only appears to be an issue for the serial
drivers that use the core serial code.  All other drivers seem to either
ignore attempts to change port/irq or give an error.

Reported-by: Greg Kroah-Hartman 
Signed-off-by: David Howells 
cc: Jiri Slaby 
Signed-off-by: Matthew Garrett 
---
 drivers/tty/serial/serial_core.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index d4cca5bdaf1c..04534877b575 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -842,6 +842,12 @@ static int uart_set_info(struct tty_struct *tty, struct 
tty_port *port,
new_flags = (__force upf_t)new_info->flags;
old_custom_divisor = uport->custom_divisor;
 
+   if ((change_port || change_irq) &&
+   kernel_is_locked_down("Using TIOCSSERIAL to change device 
addresses, irqs and dma channels")) {
+   retval = -EPERM;
+   goto exit;
+   }
+
if (!capable(CAP_SYS_ADMIN)) {
retval = -EPERM;
if (change_irq || change_port ||
-- 
2.21.0.352.gf09ad66450-goog



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

2019-03-06 Thread Matthew Garrett
From: Josh Boyer 

This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to modify the workings of hardware .  Reject
the option when the kernel is locked down.

Signed-off-by: Josh Boyer 
Signed-off-by: David Howells 
Reviewed-by: "Lee, Chun-Yi" 
cc: Dave Young 
cc: linux-a...@vger.kernel.org
Signed-off-by: Matthew Garrett 
---
 drivers/acpi/osl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index f29e427d0d1d..3e44cef7a0cd 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -194,7 +194,7 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
acpi_physical_address pa;
 
 #ifdef CONFIG_KEXEC
-   if (acpi_rsdp)
+   if (acpi_rsdp && !kernel_is_locked_down("ACPI RSDP specification"))
return acpi_rsdp;
 #endif
pa = acpi_arch_get_root_pointer();
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 26/27] debugfs: Restrict debugfs when the kernel is locked down

2019-03-06 Thread Matthew Garrett
From: David Howells 

Disallow opening of debugfs files that might be used to muck around when
the kernel is locked down as various drivers give raw access to hardware
through debugfs.  Given the effort of auditing all 2000 or so files and
manually fixing each one as necessary, I've chosen to apply a heuristic
instead.  The following changes are made:

 (1) chmod and chown are disallowed on debugfs objects (though the root dir
 can be modified by mount and remount, but I'm not worried about that).

 (2) When the kernel is locked down, only files with the following criteria
 are permitted to be opened:

- The file must have mode 00444
- The file must not have ioctl methods
- The file must not have mmap

 (3) When the kernel is locked down, files may only be opened for reading.

Normal device interaction should be done through configfs, sysfs or a
miscdev, not debugfs.

Note that this makes it unnecessary to specifically lock down show_dsts(),
show_devs() and show_call() in the asus-wmi driver.

I would actually prefer to lock down all files by default and have the
the files unlocked by the creator.  This is tricky to manage correctly,
though, as there are 19 creation functions and ~1600 call sites (some of
them in loops scanning tables).

Signed-off-by: David Howells 
cc: Andy Shevchenko 
cc: acpi4asus-u...@lists.sourceforge.net
cc: platform-driver-...@vger.kernel.org
cc: Matthew Garrett 
cc: Thomas Gleixner 
Signed-off-by: Matthew Garrett 
---
 fs/debugfs/file.c  | 28 
 fs/debugfs/inode.c | 30 --
 2 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 4fce1da7db23..c33042c1eff3 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -136,6 +136,25 @@ void debugfs_file_put(struct dentry *dentry)
 }
 EXPORT_SYMBOL_GPL(debugfs_file_put);
 
+/*
+ * Only permit access to world-readable files when the kernel is locked down.
+ * We also need to exclude any file that has ways to write or alter it as root
+ * can bypass the permissions check.
+ */
+static bool debugfs_is_locked_down(struct inode *inode,
+  struct file *filp,
+  const struct file_operations *real_fops)
+{
+   if ((inode->i_mode & 0) == 0444 &&
+   !(filp->f_mode & FMODE_WRITE) &&
+   !real_fops->unlocked_ioctl &&
+   !real_fops->compat_ioctl &&
+   !real_fops->mmap)
+   return false;
+
+   return kernel_is_locked_down("debugfs");
+}
+
 static int open_proxy_open(struct inode *inode, struct file *filp)
 {
struct dentry *dentry = F_DENTRY(filp);
@@ -147,6 +166,11 @@ static int open_proxy_open(struct inode *inode, struct 
file *filp)
return r == -EIO ? -ENOENT : r;
 
real_fops = debugfs_real_fops(filp);
+
+   r = -EPERM;
+   if (debugfs_is_locked_down(inode, filp, real_fops))
+   goto out;
+
real_fops = fops_get(real_fops);
if (!real_fops) {
/* Huh? Module did not clean up after itself at exit? */
@@ -272,6 +296,10 @@ static int full_proxy_open(struct inode *inode, struct 
file *filp)
return r == -EIO ? -ENOENT : r;
 
real_fops = debugfs_real_fops(filp);
+   r = -EPERM;
+   if (debugfs_is_locked_down(inode, filp, real_fops))
+   goto out;
+
real_fops = fops_get(real_fops);
if (!real_fops) {
/* Huh? Module did not cleanup after itself at exit? */
diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 13b01351dd1c..4daec17b8215 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -32,6 +32,31 @@ static struct vfsmount *debugfs_mount;
 static int debugfs_mount_count;
 static bool debugfs_registered;
 
+/*
+ * Don't allow access attributes to be changed whilst the kernel is locked down
+ * so that we can use the file mode as part of a heuristic to determine whether
+ * to lock down individual files.
+ */
+static int debugfs_setattr(struct dentry *dentry, struct iattr *ia)
+{
+   if ((ia->ia_valid & (ATTR_MODE | ATTR_UID | ATTR_GID)) &&
+   kernel_is_locked_down("debugfs"))
+   return -EPERM;
+   return simple_setattr(dentry, ia);
+}
+
+static const struct inode_operations debugfs_file_inode_operations = {
+   .setattr= debugfs_setattr,
+};
+static const struct inode_operations debugfs_dir_inode_operations = {
+   .lookup = simple_lookup,
+   .setattr= debugfs_setattr,
+};
+static const struct inode_operations debugfs_symlink_inode_operations = {
+   .get_link   = simple_get_link,
+   .setattr= debugfs_setattr,
+};
+
 static struct inode *debugfs_get_inode(struct super_block *sb)
 {
struct inode *inode = new_inode(sb);
@@ -356,6 +381,7 @@ static s

[PATCH 25/27] Lock down perf

2019-03-06 Thread Matthew Garrett
From: David Howells 

Disallow the use of certain perf facilities that might allow userspace to
access kernel data.

Signed-off-by: David Howells 

Signed-off-by: Matthew Garrett 
---
 kernel/events/core.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 3cd13a30f732..7748c6f39992 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -10461,6 +10461,11 @@ SYSCALL_DEFINE5(perf_event_open,
return -EINVAL;
}
 
+   if ((attr.sample_type & PERF_SAMPLE_REGS_INTR) &&
+   kernel_is_locked_down("PERF_SAMPLE_REGS_INTR"))
+   /* REGS_INTR can leak data, lockdown must prevent this */
+   return -EPERM;
+
/* Only privileged users can get physical addresses */
if ((attr.sample_type & PERF_SAMPLE_PHYS_ADDR) &&
perf_paranoid_kernel() && !capable(CAP_SYS_ADMIN))
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 23/27] Lock down kprobes

2019-03-06 Thread Matthew Garrett
From: David Howells 

Disallow the creation of kprobes when the kernel is locked down by
preventing their registration.  This prevents kprobes from being used to
access kernel memory, either to make modifications or to steal crypto data.

Reported-by: Alexei Starovoitov 
Signed-off-by: David Howells 
Signed-off-by: Matthew Garrett 
---
 kernel/kprobes.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index f4ddfdd2d07e..6f66cca8e2c6 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1552,6 +1552,9 @@ int register_kprobe(struct kprobe *p)
struct module *probed_mod;
kprobe_opcode_t *addr;
 
+   if (kernel_is_locked_down("Use of kprobes"))
+   return -EPERM;
+
/* Adjust probe address from symbol */
addr = kprobe_addr(p);
if (IS_ERR(addr))
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 18/27] Prohibit PCMCIA CIS storage when the kernel is locked down

2019-03-06 Thread Matthew Garrett
From: David Howells 

Prohibit replacement of the PCMCIA Card Information Structure when the
kernel is locked down.

Suggested-by: Dominik Brodowski 
Signed-off-by: David Howells 
cc: linux-pcm...@lists.infradead.org
Signed-off-by: Matthew Garrett 
---
 drivers/pcmcia/cistpl.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pcmcia/cistpl.c b/drivers/pcmcia/cistpl.c
index ac0672b8dfca..8adf092d0e18 100644
--- a/drivers/pcmcia/cistpl.c
+++ b/drivers/pcmcia/cistpl.c
@@ -1578,6 +1578,9 @@ static ssize_t pccard_store_cis(struct file *filp, struct 
kobject *kobj,
struct pcmcia_socket *s;
int error;
 
+   if (kernel_is_locked_down("Direct PCMCIA CIS storage"))
+   return -EPERM;
+
s = to_socket(container_of(kobj, struct device, kobj));
 
if (off)
-- 
2.21.0.352.gf09ad66450-goog



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

2019-03-06 Thread Matthew Garrett
From: David Howells 

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 image signing key) to
be read by an eBPF program and kernel memory to be altered without
restriction.

Completely prohibit the use of BPF when the kernel is locked down.

Suggested-by: Alexei Starovoitov 
Signed-off-by: David Howells 
cc: net...@vger.kernel.org
cc: Chun-Yi Lee 
cc: Alexei Starovoitov 
Signed-off-by: Matthew Garrett 
---
 kernel/bpf/syscall.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index b155cd17c1bd..2cde39a875aa 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -2585,6 +2585,9 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, 
uattr, unsigned int, siz
if (sysctl_unprivileged_bpf_disabled && !capable(CAP_SYS_ADMIN))
return -EPERM;
 
+   if (kernel_is_locked_down("BPF"))
+   return -EPERM;
+
err = bpf_check_uarg_tail_zero(uattr, sizeof(attr), size);
if (err)
return err;
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 21/27] x86/mmiotrace: Lock down the testmmiotrace module

2019-03-06 Thread Matthew Garrett
From: David Howells 

The testmmiotrace module shouldn't be permitted when the kernel is locked
down as it can be used to arbitrarily read and write MMIO space.

Suggested-by: Thomas Gleixner 
Signed-off-by: David Howells 
cc: Steven Rostedt 
cc: Ingo Molnar 
cc: "H. Peter Anvin" 
cc: x...@kernel.org
Signed-off-by: Matthew Garrett 
---
 arch/x86/mm/testmmiotrace.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/mm/testmmiotrace.c b/arch/x86/mm/testmmiotrace.c
index f6ae6830b341..bbaad357f5d7 100644
--- a/arch/x86/mm/testmmiotrace.c
+++ b/arch/x86/mm/testmmiotrace.c
@@ -115,6 +115,9 @@ static int __init init(void)
 {
unsigned long size = (read_far) ? (8 << 20) : (16 << 10);
 
+   if (kernel_is_locked_down("MMIO trace testing"))
+   return -EPERM;
+
if (mmio_address == 0) {
pr_err("you have to use the module argument mmio_address.\n");
pr_err("DO NOT LOAD THIS MODULE UNLESS YOU REALLY KNOW WHAT YOU 
ARE DOING!\n");
-- 
2.21.0.352.gf09ad66450-goog



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

2019-03-06 Thread Matthew Garrett
From: Matthew Garrett 

Any hardware that can potentially generate DMA has to be locked down in
order to avoid it being possible for an attacker to modify kernel code,
allowing them to circumvent disabled module loading or module signing.
Default to paranoid - in future we can potentially relax this for
sufficiently IOMMU-isolated devices.

Signed-off-by: Matthew Garrett 
Signed-off-by: David Howells 
Acked-by: Bjorn Helgaas 
Reviewed-by: "Lee, Chun-Yi" 
cc: linux-...@vger.kernel.org
Signed-off-by: Matthew Garrett 
---
 drivers/pci/pci-sysfs.c | 9 +
 drivers/pci/proc.c  | 9 -
 drivers/pci/syscall.c   | 3 ++-
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 9ecfe13157c0..40c14574fcf8 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -905,6 +905,9 @@ static ssize_t pci_write_config(struct file *filp, struct 
kobject *kobj,
loff_t init_off = off;
u8 *data = (u8 *) buf;
 
+   if (kernel_is_locked_down("Direct PCI access"))
+   return -EPERM;
+
if (off > dev->cfg_size)
return 0;
if (off + count > dev->cfg_size) {
@@ -1167,6 +1170,9 @@ static int pci_mmap_resource(struct kobject *kobj, struct 
bin_attribute *attr,
enum pci_mmap_state mmap_type;
struct resource *res = >resource[bar];
 
+   if (kernel_is_locked_down("Direct PCI access"))
+   return -EPERM;
+
if (res->flags & IORESOURCE_MEM && iomem_is_exclusive(res->start))
return -EINVAL;
 
@@ -1242,6 +1248,9 @@ static ssize_t pci_write_resource_io(struct file *filp, 
struct kobject *kobj,
 struct bin_attribute *attr, char *buf,
 loff_t off, size_t count)
 {
+   if (kernel_is_locked_down("Direct PCI access"))
+   return -EPERM;
+
return pci_resource_io(filp, kobj, attr, buf, off, count, true);
 }
 
diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index 6fa1627ce08d..1549cdd0710e 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -117,6 +117,9 @@ static ssize_t proc_bus_pci_write(struct file *file, const 
char __user *buf,
int size = dev->cfg_size;
int cnt;
 
+   if (kernel_is_locked_down("Direct PCI access"))
+   return -EPERM;
+
if (pos >= size)
return 0;
if (nbytes >= size)
@@ -196,6 +199,9 @@ static long proc_bus_pci_ioctl(struct file *file, unsigned 
int cmd,
 #endif /* HAVE_PCI_MMAP */
int ret = 0;
 
+   if (kernel_is_locked_down("Direct PCI access"))
+   return -EPERM;
+
switch (cmd) {
case PCIIOC_CONTROLLER:
ret = pci_domain_nr(dev->bus);
@@ -237,7 +243,8 @@ static int proc_bus_pci_mmap(struct file *file, struct 
vm_area_struct *vma)
struct pci_filp_private *fpriv = file->private_data;
int i, ret, write_combine = 0, res_bit = IORESOURCE_MEM;
 
-   if (!capable(CAP_SYS_RAWIO))
+   if (!capable(CAP_SYS_RAWIO) ||
+   kernel_is_locked_down("Direct PCI access"))
return -EPERM;
 
if (fpriv->mmap_state == pci_mmap_io) {
diff --git a/drivers/pci/syscall.c b/drivers/pci/syscall.c
index d96626c614f5..b8a08d3166a1 100644
--- a/drivers/pci/syscall.c
+++ b/drivers/pci/syscall.c
@@ -90,7 +90,8 @@ SYSCALL_DEFINE5(pciconfig_write, unsigned long, bus, unsigned 
long, dfn,
u32 dword;
int err = 0;
 
-   if (!capable(CAP_SYS_ADMIN))
+   if (!capable(CAP_SYS_ADMIN) ||
+   kernel_is_locked_down("Direct PCI access"))
return -EPERM;
 
dev = pci_get_domain_bus_and_slot(0, bus, dfn);
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 20/27] Lock down module params that specify hardware parameters (eg. ioport)

2019-03-06 Thread Matthew Garrett
From: David Howells 

Provided an annotation for module parameters that specify hardware
parameters (such as io ports, iomem addresses, irqs, dma channels, fixed
dma buffers and other types).

Suggested-by: Alan Cox 
Signed-off-by: David Howells 
Signed-off-by: Matthew Garrett 
---
 kernel/params.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/kernel/params.c b/kernel/params.c
index ce89f757e6da..8ac751c938f8 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -108,13 +108,19 @@ bool parameq(const char *a, const char *b)
return parameqn(a, b, strlen(a)+1);
 }
 
-static void param_check_unsafe(const struct kernel_param *kp)
+static bool param_check_unsafe(const struct kernel_param *kp,
+  const char *doing)
 {
if (kp->flags & KERNEL_PARAM_FL_UNSAFE) {
pr_notice("Setting dangerous option %s - tainting kernel\n",
  kp->name);
add_taint(TAINT_USER, LOCKDEP_STILL_OK);
}
+
+   if (kp->flags & KERNEL_PARAM_FL_HWPARAM &&
+   kernel_is_locked_down("Command line-specified device addresses, 
irqs and dma channels"))
+   return false;
+   return true;
 }
 
 static int parse_one(char *param,
@@ -144,8 +150,10 @@ static int parse_one(char *param,
pr_debug("handling %s with %p\n", param,
params[i].ops->set);
kernel_param_lock(params[i].mod);
-   param_check_unsafe([i]);
-   err = params[i].ops->set(val, [i]);
+   if (param_check_unsafe([i], doing))
+   err = params[i].ops->set(val, [i]);
+   else
+   err = -EPERM;
kernel_param_unlock(params[i].mod);
return err;
}
@@ -553,6 +561,12 @@ static ssize_t param_attr_show(struct module_attribute 
*mattr,
return count;
 }
 
+#ifdef CONFIG_MODULES
+#define mod_name(mod) (mod)->name
+#else
+#define mod_name(mod) "unknown"
+#endif
+
 /* sysfs always hands a nul-terminated string in buf.  We rely on that. */
 static ssize_t param_attr_store(struct module_attribute *mattr,
struct module_kobject *mk,
@@ -565,8 +579,10 @@ static ssize_t param_attr_store(struct module_attribute 
*mattr,
return -EPERM;
 
kernel_param_lock(mk->mod);
-   param_check_unsafe(attribute->param);
-   err = attribute->param->ops->set(buf, attribute->param);
+   if (param_check_unsafe(attribute->param, mod_name(mk->mod)))
+   err = attribute->param->ops->set(buf, attribute->param);
+   else
+   err = -EPERM;
kernel_param_unlock(mk->mod);
if (!err)
return len;
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 22/27] Lock down /proc/kcore

2019-03-06 Thread Matthew Garrett
From: David Howells 

Disallow access to /proc/kcore when the kernel is locked down to prevent
access to cryptographic data.

Signed-off-by: David Howells 
Reviewed-by: James Morris 
Signed-off-by: Matthew Garrett 
---
 fs/proc/kcore.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index bbcc185062bb..d50ebfbf3dbb 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -518,6 +518,8 @@ read_kcore(struct file *file, char __user *buffer, size_t 
buflen, loff_t *fpos)
 
 static int open_kcore(struct inode *inode, struct file *filp)
 {
+   if (kernel_is_locked_down("/proc/kcore"))
+   return -EPERM;
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
 
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 14/27] ACPI: Limit access to custom_method when the kernel is locked down

2019-03-06 Thread Matthew Garrett
From: Matthew Garrett 

custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to circumvent restrictions on module loading.
Disable it if the kernel is locked down.

Signed-off-by: Matthew Garrett 
Signed-off-by: David Howells 
Reviewed-by: "Lee, Chun-Yi" 
cc: linux-a...@vger.kernel.org
Signed-off-by: Matthew Garrett 
---
 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 4451877f83b6..ac8a90dc7096 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("ACPI custom methods"))
+   return -EPERM;
+
if (!(*ppos)) {
/* parse the table header to get the table length */
if (count <= sizeof(struct acpi_table_header))
-- 
2.21.0.352.gf09ad66450-goog



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

2019-03-06 Thread Matthew Garrett
From: Linn Crosetto 

>From the kernel documentation (initrd_table_override.txt):

  If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible
  to override nearly any ACPI table provided by the BIOS with an
  instrumented, modified one.

When securelevel is set, the kernel should disallow any unauthenticated
changes to kernel space.  ACPI tables contain code invoked by the kernel,
so do not allow ACPI tables to be overridden if the kernel is locked down.

Signed-off-by: Linn Crosetto 
Signed-off-by: David Howells 
Reviewed-by: "Lee, Chun-Yi" 
cc: linux-a...@vger.kernel.org
Signed-off-by: Matthew Garrett 
---
 drivers/acpi/tables.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 48eabb6c2d4f..f3b4117cd8f3 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -531,6 +531,11 @@ void __init acpi_table_upgrade(void)
if (table_nr == 0)
return;
 
+   if (kernel_is_locked_down("ACPI table override")) {
+   pr_notice("kernel is locked down, ignoring table override\n");
+   return;
+   }
+
acpi_tables_addr =
memblock_find_in_range(0, ACPI_TABLE_UPGRADE_MAX_PHYS,
   all_tables_size, PAGE_SIZE);
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 10/27] uswsusp: Disable when the kernel is locked down

2019-03-06 Thread Matthew Garrett
From: Matthew Garrett 

uswsusp allows a user process to dump and then restore kernel state, which
makes it possible to modify the running kernel.  Disable this if the kernel
is locked down.

Signed-off-by: Matthew Garrett 
Signed-off-by: David Howells 
Reviewed-by: "Lee, Chun-Yi" 
Reviewed-by: James Morris 
cc: linux...@vger.kernel.org
Signed-off-by: Matthew Garrett 
---
 kernel/power/user.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/power/user.c b/kernel/power/user.c
index 2d8b60a3c86b..0305d513c274 100644
--- a/kernel/power/user.c
+++ b/kernel/power/user.c
@@ -52,6 +52,9 @@ static int snapshot_open(struct inode *inode, struct file 
*filp)
if (!hibernation_available())
return -EPERM;
 
+   if (kernel_is_locked_down("/dev/snapshot"))
+   return -EPERM;
+
lock_system_sleep();
 
if (!atomic_add_unless(_device_available, -1, 0)) {
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 08/27] kexec_file: Restrict at runtime if the kernel is locked down

2019-03-06 Thread Matthew Garrett
From: Jiri Bohac 

When KEXEC_SIG is not enabled, kernel should not load images through
kexec_file systemcall if the kernel is locked down.

[Modified by David Howells to fit with modifications to the previous patch
 and to return -EPERM if the kernel is locked down for consistency with
 other lockdowns. Modified by Matthew Garrett to remove the IMA
 integration, which will be replaced by integrating with the IMA
 architecture policy patches.]

Signed-off-by: Jiri Bohac 
Signed-off-by: David Howells 
Reviewed-by: Jiri Bohac 
Cc: Matthew Garrett 
cc: Chun-Yi Lee 
cc: ke...@lists.infradead.org
Signed-off-by: Matthew Garrett 
---
 kernel/kexec_file.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 67f3a866eabe..0cfe4f6f7f85 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -239,6 +239,12 @@ kimage_file_prepare_segments(struct kimage *image, int 
kernel_fd, int initrd_fd,
}
 
ret = 0;
+
+   if (kernel_is_locked_down(reason)) {
+   ret = -EPERM;
+   goto out;
+   }
+
break;
 
/* All other errors are fatal, including nomem, unparseable
-- 
2.21.0.352.gf09ad66450-goog



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

2019-03-06 Thread Matthew Garrett
From: Matthew Garrett 

Writing to MSRs should not be allowed if the kernel is locked down, since
it could lead to execution of arbitrary code in kernel mode.  Based on a
patch by Kees Cook.

MSR accesses are logged for the purposes of building up a whitelist as per
Alan Cox's suggestion.

Signed-off-by: Matthew Garrett 
Signed-off-by: David Howells 
Acked-by: Kees Cook 
Reviewed-by: Thomas Gleixner 
Reviewed-by: "Lee, Chun-Yi" 
cc: x...@kernel.org
Signed-off-by: Matthew Garrett 
---
 arch/x86/kernel/msr.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index 4588414e2561..f5a2cf07972f 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -84,6 +84,11 @@ static ssize_t msr_write(struct file *file, const char 
__user *buf,
int err = 0;
ssize_t bytes = 0;
 
+   if (kernel_is_locked_down("Direct MSR access")) {
+   pr_info("Direct access to MSR %x\n", reg);
+   return -EPERM;
+   }
+
if (count % 8)
return -EINVAL; /* Invalid chunk size */
 
@@ -135,6 +140,11 @@ static long msr_ioctl(struct file *file, unsigned int ioc, 
unsigned long arg)
err = -EFAULT;
break;
}
+   if (kernel_is_locked_down("Direct MSR access")) {
+   pr_info("Direct access to MSR %x\n", regs[1]); /* 
Display %ecx */
+   err = -EPERM;
+   break;
+   }
err = wrmsr_safe_regs_on_cpu(cpu, regs);
if (err)
break;
-- 
2.21.0.352.gf09ad66450-goog



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

2019-03-06 Thread Matthew Garrett
From: Dave Young 

Kexec reboot in case secure boot being enabled does not keep the secure
boot mode in new kernel, so later one can load unsigned kernel via legacy
kexec_load.  In this state, the system is missing the 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 
Signed-off-by: David Howells 
Reviewed-by: "Lee, Chun-Yi" 
cc: ke...@lists.infradead.org
Signed-off-by: Matthew Garrett 
---
 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 278cd07228dd..d49554b948fd 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;
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 07/27] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

2019-03-06 Thread Matthew Garrett
From: Jiri Bohac 

This is a preparatory patch for kexec_file_load() lockdown.  A locked down
kernel needs to prevent unsigned kernel images from being loaded with
kexec_file_load().  Currently, the only way to force the signature
verification is compiling with KEXEC_VERIFY_SIG.  This prevents loading
usigned images even when the kernel is not locked down at runtime.

This patch splits KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE.
Analogous to the MODULE_SIG and MODULE_SIG_FORCE for modules, KEXEC_SIG
turns on the signature verification but allows unsigned images to be
loaded.  KEXEC_SIG_FORCE disallows images without a valid signature.

[Modified by David Howells such that:

 (1) verify_pefile_signature() differentiates between no-signature and
 sig-didn't-match in its returned errors.

 (2) kexec fails with EKEYREJECTED and logs an appropriate message if
 signature checking is enforced and an signature is not found, uses
 unsupported crypto or has no matching key.

 (3) kexec fails with EKEYREJECTED if there is a signature for which we
 have a key, but signature doesn't match - even if in non-forcing mode.

 (4) kexec fails with EBADMSG or some other error if there is a signature
 which cannot be parsed - even if in non-forcing mode.

 (5) kexec fails with ELIBBAD if the PE file cannot be parsed to extract
 the signature - even if in non-forcing mode.

]

Signed-off-by: Jiri Bohac 
Signed-off-by: David Howells 
Reviewed-by: Jiri Bohac 
cc: Matthew Garrett 
cc: Chun-Yi Lee 
cc: ke...@lists.infradead.org
Signed-off-by: Matthew Garrett 
---
 arch/x86/Kconfig   | 20 ---
 crypto/asymmetric_keys/verify_pefile.c |  4 ++-
 include/linux/kexec.h  |  4 +--
 kernel/kexec_file.c| 48 ++
 4 files changed, 61 insertions(+), 15 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 4b4a7f32b68e..735d04a4b18f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2016,20 +2016,30 @@ config KEXEC_FILE
 config ARCH_HAS_KEXEC_PURGATORY
def_bool KEXEC_FILE
 
-config KEXEC_VERIFY_SIG
+config KEXEC_SIG
bool "Verify kernel signature during kexec_file_load() syscall"
depends on KEXEC_FILE
---help---
- This option makes kernel signature verification mandatory for
- the kexec_file_load() syscall.
 
- In addition to that option, you need to enable signature
+ This option makes the kexec_file_load() syscall check for a valid
+ signature of the kernel image.  The image can still be loaded without
+ a valid signature unless you also enable KEXEC_SIG_FORCE, though if
+ there's a signature that we can check, then it must be valid.
+
+ In addition to this option, you need to enable signature
  verification for the corresponding kernel image type being
  loaded in order for this to work.
 
+config KEXEC_SIG_FORCE
+   bool "Require a valid signature in kexec_file_load() syscall"
+   depends on KEXEC_SIG
+   ---help---
+ This option makes kernel signature verification mandatory for
+ the kexec_file_load() syscall.
+
 config KEXEC_BZIMAGE_VERIFY_SIG
bool "Enable bzImage signature verification support"
-   depends on KEXEC_VERIFY_SIG
+   depends on KEXEC_SIG
depends on SIGNED_PE_FILE_VERIFICATION
select SYSTEM_TRUSTED_KEYRING
---help---
diff --git a/crypto/asymmetric_keys/verify_pefile.c 
b/crypto/asymmetric_keys/verify_pefile.c
index d178650fd524..4473cea1e877 100644
--- a/crypto/asymmetric_keys/verify_pefile.c
+++ b/crypto/asymmetric_keys/verify_pefile.c
@@ -100,7 +100,7 @@ static int pefile_parse_binary(const void *pebuf, unsigned 
int pelen,
 
if (!ddir->certs.virtual_address || !ddir->certs.size) {
pr_debug("Unsigned PE binary\n");
-   return -EKEYREJECTED;
+   return -ENODATA;
}
 
chkaddr(ctx->header_size, ddir->certs.virtual_address,
@@ -408,6 +408,8 @@ static int pefile_digest_pe(const void *pebuf, unsigned int 
pelen,
  *  (*) 0 if at least one signature chain intersects with the keys in the trust
  * keyring, or:
  *
+ *  (*) -ENODATA if there is no signature present.
+ *
  *  (*) -ENOPKG if a suitable crypto module couldn't be found for a check on a
  * chain.
  *
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index b9b1bc5f9669..58b27c7bdc2b 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -125,7 +125,7 @@ typedef void *(kexec_load_t)(struct kimage *image, char 
*kernel_buf,
 unsigned long cmdline_len);
 typedef int (kexec_cleanup_t)(void *loader_data);
 
-#ifdef CONFIG_KEXEC_VERIFY_SIG
+#ifdef CONFIG_KEXEC_SIG
 typedef int (kexec_verify_sig_t)(const char *kernel_buf,
 unsigned long kernel_len

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

2019-03-06 Thread Matthew Garrett
From: Matthew Garrett 

The kexec_load() syscall 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_load() in this situation.

This does not affect kexec_file_load() syscall which can check for a
signature on the image to be booted.

Signed-off-by: Matthew Garrett 
Signed-off-by: David Howells 
Acked-by: Dave Young 
Reviewed-by: "Lee, Chun-Yi" 
Reviewed-by: James Morris 
cc: ke...@lists.infradead.org
Signed-off-by: Matthew Garrett 
---
 kernel/kexec.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/kernel/kexec.c b/kernel/kexec.c
index 68559808fdfa..8ea0ce31271f 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -207,6 +207,13 @@ static inline int kexec_load_check(unsigned long 
nr_segments,
if (result < 0)
return result;
 
+   /*
+* kexec can be used to circumvent module loading restrictions, so
+* prevent loading in that case
+*/
+   if (kernel_is_locked_down("kexec of unsigned images"))
+   return -EPERM;
+
/*
 * Verify we have a legal set of flags
 * This leaves us room for future extensions.
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 04/27] Restrict /dev/{mem,kmem,port} when the kernel is locked down

2019-03-06 Thread Matthew Garrett
From: Matthew Garrett 

Allowing users to read and write to core kernel memory makes it possible
for the kernel to be subverted, avoiding module loading restrictions, and
also to steal cryptographic information.

Disallow /dev/mem and /dev/kmem from being opened this when the kernel has
been locked down to prevent this.

Also disallow /dev/port from being opened to prevent raw ioport access and
thus DMA from being used to accomplish the same thing.

Signed-off-by: Matthew Garrett 
Signed-off-by: David Howells 
Reviewed-by: "Lee, Chun-Yi" 
Signed-off-by: Matthew Garrett 
---
 drivers/char/mem.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index b08dc50f9f26..0a2f2e75d5f4 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -786,6 +786,8 @@ static loff_t memory_lseek(struct file *file, loff_t 
offset, int orig)
 
 static int open_port(struct inode *inode, struct file *filp)
 {
+   if (kernel_is_locked_down("/dev/mem,kmem,port"))
+   return -EPERM;
return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
 }
 
-- 
2.21.0.352.gf09ad66450-goog



[PULL REQUEST] Kernel lockdown patches for 5.2

2019-03-06 Thread Matthew Garrett
Hi James,

This patchset introduces an optional kernel lockdown feature,
intended to strengthen the boundary between UID 0 and the kernel. When
enabled and active (by enabling the config option and passing the
"lockdown" option on the kernel command line), various pieces of
kernel functionality are restricted. Applications that rely on
low-level access to either hardware or the kernel may cease working as
a result - therefore this should not be enabled without appropriate
evaluation beforehand.

The majority of mainstream distributions have been carrying variants
of this patchset for many years now, so there's value in providing a
unified upstream implementation to reduce the delta. This PR probably
doesn't meet every distribution requirement, but gets us much closer
to not requiring external patches.

This PR is mostly the same as the previous attempt, but with the
following changes:

1) The integration between EFI secure boot and the lockdown state has
been removed
2) A new CONFIG_KERNEL_LOCK_DOWN_FORCE kconfig option has been added,
which will always enable lockdown regardless of the kernel command
line
3) The integration with IMA has been dropped for now. IMA is in the
process of adding support for architecture-specific policies that will
interact correctly with the lockdown feature, and a followup patch will
integrate that so we don't end up with an ordering dependency on the
merge

The following changes since commit 468e91cecb3218afd684b8c422490dfebe0691bb:

  keys: fix missing __user in KEYCTL_PKEY_QUERY (2019-03-04 15:48:37 -0800)

are available in the Git repository at:

  https://github.com/mjg59/linux lock_down

for you to fetch changes up to 3d53449e0ac1df8cfdcc1ec48dc9cb622f220300:

  lockdown: Print current->comm in restriction messages (2019-03-06 13:32:19 
-0800)


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

David Howells (12):
  Add the ability to lock down access to the running kernel image
  Enforce module signatures if the kernel is locked down
  Prohibit PCMCIA CIS storage when the kernel is locked down
  Lock down TIOCSSERIAL
  Lock down module params that specify hardware parameters (eg. ioport)
  x86/mmiotrace: Lock down the testmmiotrace module
  Lock down /proc/kcore
  Lock down kprobes
  bpf: Restrict kernel image access functions when the kernel is locked down
  Lock down perf
  debugfs: Restrict debugfs when the kernel is locked down
  lockdown: Print current->comm in restriction messages

Jiri Bohac (2):
  kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE
  kexec_file: Restrict at runtime if the kernel is locked down

Josh Boyer (2):
  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 lift kernel lockdown

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 (7):
  Restrict /dev/{mem,kmem,port} when the kernel is locked down
  kexec_load: 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/msr: Restrict MSR access when the kernel is locked down
  ACPI: Limit access to custom_method when the kernel is locked down

 arch/x86/Kconfig   |  20 +--
 arch/x86/include/asm/setup.h   |   2 +
 arch/x86/kernel/ioport.c   |   6 +-
 arch/x86/kernel/kexec-bzimage64.c  |   1 +
 arch/x86/kernel/msr.c  |  10 
 arch/x86/mm/testmmiotrace.c|   3 +
 crypto/asymmetric_keys/verify_pefile.c |   4 +-
 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 |   2 +
 drivers/input/misc/uinput.c|   1 +
 drivers/pci/pci-sysfs.c|   9 +++
 drivers/pci/proc.c |   9 ++-
 drivers/pci/syscall.c  |   3 +-
 drivers/pcmcia/cistpl.c|   3 +
 drivers/tty/serial/serial_core.c   |   6 ++
 drivers/tty/sysrq.c|  19 --
 fs/debugfs/file.c  |  28 +
 fs/debugfs/inode.c |  30 +-
 fs/proc/kcore.c|   2 +
 include/linux/input.h  |   5 ++
 include/linux/kernel.h |  17 ++
 include/linux/kexec.h  |   4 +-
 include/linux/security.h   |   9 ++-
 include/linux/sysrq.h  |   8 ++-
 kern

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

2019-03-06 Thread Matthew Garrett
From: David Howells 

If the kernel is locked down, require that all modules have valid
signatures that we can verify.

I have adjusted the errors generated:

 (1) If there's no signature (ENODATA) or we can't check it (ENOPKG,
 ENOKEY), then:

 (a) If signatures are enforced then EKEYREJECTED is returned.

 (b) If there's no signature or we can't check it, but the kernel is
 locked down then EPERM is returned (this is then consistent with
 other lockdown cases).

 (2) If the signature is unparseable (EBADMSG, EINVAL), the signature fails
 the check (EKEYREJECTED) or a system error occurs (eg. ENOMEM), we
 return the error we got.

Note that the X.509 code doesn't check for key expiry as the RTC might not
be valid or might not have been transferred to the kernel's clock yet.

 [Modified by Matthew Garrett to remove the IMA integration. This will
  be replaced with integration with the IMA architecture policy
  patchset.]

Signed-off-by: David Howells 
Reviewed-by: Jiri Bohac 
cc: "Lee, Chun-Yi" 
cc: James Morris 
Signed-off-by: Matthew Garrett 
---
 kernel/module.c | 39 ---
 1 file changed, 32 insertions(+), 7 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index 2ad1b5239910..9a377c6ea200 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2767,8 +2767,9 @@ static inline void kmemleak_load_module(const struct 
module *mod,
 #ifdef CONFIG_MODULE_SIG
 static int module_sig_check(struct load_info *info, int flags)
 {
-   int err = -ENOKEY;
+   int err = -ENODATA;
const unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
+   const char *reason;
const void *mod = info->hdr;
 
/*
@@ -2783,16 +2784,40 @@ static int module_sig_check(struct load_info *info, int 
flags)
err = mod_verify_sig(mod, info);
}
 
-   if (!err) {
+   switch (err) {
+   case 0:
info->sig_ok = true;
return 0;
-   }
 
-   /* Not having a signature is only an error if we're strict. */
-   if (err == -ENOKEY && !is_module_sig_enforced())
-   err = 0;
+   /* We don't permit modules to be loaded into trusted kernels
+* without a valid signature on them, but if we're not
+* enforcing, certain errors are non-fatal.
+*/
+   case -ENODATA:
+   reason = "Loading of unsigned module";
+   goto decide;
+   case -ENOPKG:
+   reason = "Loading of module with unsupported crypto";
+   goto decide;
+   case -ENOKEY:
+   reason = "Loading of module with unavailable key";
+   decide:
+   if (is_module_sig_enforced()) {
+   pr_notice("%s is rejected\n", reason);
+   return -EKEYREJECTED;
+   }
 
-   return err;
+   if (kernel_is_locked_down(reason))
+   return -EPERM;
+   return 0;
+
+   /* All other errors are fatal, including nomem, unparseable
+* signatures and signature check failures - even if signatures
+* aren't required.
+*/
+   default:
+   return err;
+   }
 }
 #else /* !CONFIG_MODULE_SIG */
 static int module_sig_check(struct load_info *info, int flags)
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 02/27] Add a SysRq option to lift kernel lockdown

2019-03-06 Thread Matthew Garrett
From: Kyle McMartin 

Make an option to provide a sysrq key that will lift the kernel lockdown,
thereby allowing the running kernel image to be accessed and modified.

On x86 this is triggered with SysRq+x, but this key may not be available on
all arches, so it is set by setting LOCKDOWN_LIFT_KEY in asm/setup.h.
Since this macro must be defined in an arch to be able to use this facility
for that arch, the Kconfig option is restricted to arches that support it.

Signed-off-by: Kyle McMartin 
Signed-off-by: David Howells 
cc: x...@kernel.org
Signed-off-by: Matthew Garrett 
---
 arch/x86/include/asm/setup.h |  2 ++
 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 +-
 security/Kconfig |  9 +++
 security/lock_down.c | 47 
 8 files changed, 85 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index ed8ec011a9fd..8daf633a5347 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -9,6 +9,8 @@
 #include 
 #include 
 
+#define LOCKDOWN_LIFT_KEY 'x'
+
 #ifdef __i386__
 
 #include 
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index 8ec483e8688b..c2a77dc73fa0 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -365,6 +365,7 @@ static int uinput_create_device(struct uinput_device *udev)
dev->flush = uinput_dev_flush;
}
 
+   dev->flags |= INPUTDEV_FLAGS_SYNTHETIC;
dev->event = uinput_dev_event;
 
input_set_drvdata(udev->dev, udev);
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 1f03078ec352..0a05d336008e 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -480,6 +480,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 */
@@ -523,7 +524,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;
@@ -543,11 +544,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);
@@ -579,7 +584,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(struct timer_list *t)
 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(>keyreset_timer,
@@ -812,8 +817,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;
}
@@ -1096,7 +1103,7 @@ static ssize_t write_sysrq_trigger(struct file *file, 
const

Re: [PULL REQUEST] Lock down patches

2019-03-04 Thread Matthew Garrett
Hi James,

Based on feedback, I'm going to make a couple of small changes to this
patchset and then resend.


Re: [PULL REQUEST] Lock down patches

2019-02-28 Thread Matthew Garrett
On Thu, Feb 28, 2019 at 5:45 PM Mimi Zohar  wrote:
>
> On Thu, 2019-02-28 at 17:01 -0800, Matthew Garrett wrote:
>
> > > That's not a valid reason for preventing systems that do use IMA for
> > > verifying the kexec kernel image signature or kernel module signatures
> > > from enabling "lock down".  This just means that there needs to be
> > > some coordination between the different signature verification
> > > methods. [1][2]
> >
> > I agree, but the current form of the integration makes it impossible
> > for anyone using an IMA-enabled kernel (but not using IMA) to do
> > anything unless they have IMA signatures. It's a problem we need to
> > solve, I just don't think it's a problem we need to solve before
> > merging the patchset.
>
> That's simply not true.  Have you even looked at the IMA architecture
> patches?

Sorry, I think we're talking at cross purposes - I was referring to
your patch "ima: require secure_boot rules in lockdown mode"
(https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=efi-lock-down=7fa3734bd31a4b3fe71358fcba8d4878e5005b7f).
If the goal is just to use the architecture rules then I don't see any
conflict, and as far as I can tell things would just work as is if I
drop the ima portion from "kexec_file: Restrict at runtime if the
kernel is locked down"? Apologies, I'd thought that the secure_boot
ruleset was still intended to be used in a lockdown environment.


Re: [PULL REQUEST] Lock down patches

2019-02-28 Thread Matthew Garrett
On Thu, Feb 28, 2019 at 4:05 PM Mimi Zohar  wrote:
>
> On Thu, 2019-02-28 at 15:13 -0800, Matthew Garrett wrote:
> > On Thu, Feb 28, 2019 at 2:20 PM Mimi Zohar  wrote:
> > > Where/when was this latest version of the patches posted?
> >
> > They should have followed this, but git-send-email choked on some
> > reviewed-by: lines so I'm just trying to sort that out.
>
> I'm a little perplexed as to why you would send a pull request, before
> re-posting the patches with the changes for review.

They should be there now. There's no substantive change to the
patches, other than having dropped a few from the series.

> > It's a little more complicated than this. We can't just rely on IMA
> > appraisal - it has to be based on digital signatures, and the existing
> > patch only made that implicit by enabling the secure_boot policy.
>
> Right, which is the reason the IMA architecture specific policy
> requires file signatures. [1][2]

The current patches seem to require ima signatures - shouldn't this
allow ima digests as long as there's an evm signature?

> > I
> > think we do want to integrate these, but there's a few things we need
> > to take into account:
> >
> > 1) An integrated solution can't depend on xattrs, both because of the
> > lagging support for distributing those signatures but also because we
> > need to support filesystems that don't support xattrs
>
> That's not a valid reason for preventing systems that do use IMA for
> verifying the kexec kernel image signature or kernel module signatures
> from enabling "lock down".  This just means that there needs to be
> some coordination between the different signature verification
> methods. [1][2]

I agree, but the current form of the integration makes it impossible
for anyone using an IMA-enabled kernel (but not using IMA) to do
anything unless they have IMA signatures. It's a problem we need to
solve, I just don't think it's a problem we need to solve before
merging the patchset.

> > 2) An integrated solution can't depend on the current secure_boot
> > policy because that requires signed IMA policy updates, but
> > distributions have no way of knowing what IMA policy end users require
>
> Both the "CONFIG_IMA_APPRAISE_REQUIRE_KEXEC_SIGS" and the IMA
> architecture policy rules persist after loading a custom policy.
>  Neither of them require loading or signing a custom policy.

The previous version of the lockdown patchset sets the secure_boot
policy when lockdown is enabled, which does require that any custom
policy be signed.

> > In any case, I do agree that we should aim to make this more
> > reasonable - having orthogonal signing code doesn't benefit anyone.
> > Once there's solid agreement on that we can extend this support.
> >
>
> Having multiple signature verification methods is going to be around
> for a while.  The solution is to coordinate the signature verification
> methods, without requiring both types of signatures. [1][2]

Agree, and once we have a solution to this we should integrate that
with lockdown. I don't think merging this first makes that any harder.
Importantly, this version of the patchset doesn't enable lockdown
automatically unless explicitly configured to do so, which means you
can build a lockdown kernel without interfering with IMA.


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

2019-02-28 Thread Matthew Garrett
From: Dave Young 

Kexec reboot in case secure boot being enabled does not keep the secure
boot mode in new kernel, so later one can load unsigned kernel via legacy
kexec_load.  In this state, the system is missing the 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 
Signed-off-by: David Howells 
Reviewed-by: "Lee, Chun-Yi" 
cc: ke...@lists.infradead.org
---
 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 53917a3ebf94..58301a11f6da 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -182,6 +182,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;
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 08/27] kexec_file: Restrict at runtime if the kernel is locked down

2019-02-28 Thread Matthew Garrett
From: Jiri Bohac 

When KEXEC_SIG is not enabled, kernel should not load images through
kexec_file systemcall if the kernel is locked down unless IMA can be used
to validate the image.

[Modified by David Howells to fit with modifications to the previous patch
 and to return -EPERM if the kernel is locked down for consistency with
 other lockdowns]

Signed-off-by: Jiri Bohac 
Signed-off-by: David Howells 
Reviewed-by: Jiri Bohac 
Cc: Matthew Garrett 
cc: Chun-Yi Lee 
cc: ke...@lists.infradead.org
---
 include/linux/ima.h | 6 ++
 kernel/kexec_file.c | 8 
 2 files changed, 14 insertions(+)

diff --git a/include/linux/ima.h b/include/linux/ima.h
index b5e16b8c50b7..b35ed0725a05 100644
--- a/include/linux/ima.h
+++ b/include/linux/ima.h
@@ -127,4 +127,10 @@ static inline int ima_inode_removexattr(struct dentry 
*dentry,
return 0;
 }
 #endif /* CONFIG_IMA_APPRAISE */
+
+static inline bool is_ima_kexec_appraise_enabled(void)
+{
+   return IS_ENABLED(CONFIG_IMA_APPRAISE_REQUIRE_KEXEC_SIGS);
+}
+
 #endif /* _LINUX_IMA_H */
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 67f3a866eabe..b4e938dff4be 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -239,6 +239,14 @@ kimage_file_prepare_segments(struct kimage *image, int 
kernel_fd, int initrd_fd,
}
 
ret = 0;
+   if (is_ima_kexec_appraise_enabled())
+   break;
+
+   if (kernel_is_locked_down(reason)) {
+   ret = -EPERM;
+   goto out;
+   }
+
break;
 
/* All other errors are fatal, including nomem, unparseable
-- 
2.21.0.352.gf09ad66450-goog



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

2019-02-28 Thread Matthew Garrett
From: Matthew Garrett 

IO port access would permit users to gain access to PCI configuration
registers, which in turn (on a lot of hardware) give access to MMIO
register space. This would potentially permit root to trigger arbitrary
DMA, so lock it down by default.

This also implicitly locks down the KDADDIO, KDDELIO, KDENABIO and
KDDISABIO console ioctls.

Signed-off-by: Matthew Garrett 
Signed-off-by: David Howells 
Reviewed-by: Thomas Gleixner 
Reviewed-by: "Lee, Chun-Yi" 
cc: x...@kernel.org
---
 arch/x86/kernel/ioport.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index 0fe1c8782208..abc702a6ae9c 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -31,7 +31,8 @@ long ksys_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("ioperm")))
return -EPERM;
 
/*
@@ -126,7 +127,8 @@ 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("iopl"))
return -EPERM;
}
regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) |
-- 
2.21.0.352.gf09ad66450-goog



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

2019-02-28 Thread Matthew Garrett
From: Matthew Garrett 

Any hardware that can potentially generate DMA has to be locked down in
order to avoid it being possible for an attacker to modify kernel code,
allowing them to circumvent disabled module loading or module signing.
Default to paranoid - in future we can potentially relax this for
sufficiently IOMMU-isolated devices.

Signed-off-by: Matthew Garrett 
Signed-off-by: David Howells 
Acked-by: Bjorn Helgaas 
Reviewed-by: "Lee, Chun-Yi" 
cc: linux-...@vger.kernel.org
---
 drivers/pci/pci-sysfs.c | 9 +
 drivers/pci/proc.c  | 9 -
 drivers/pci/syscall.c   | 3 ++-
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 9ecfe13157c0..40c14574fcf8 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -905,6 +905,9 @@ static ssize_t pci_write_config(struct file *filp, struct 
kobject *kobj,
loff_t init_off = off;
u8 *data = (u8 *) buf;
 
+   if (kernel_is_locked_down("Direct PCI access"))
+   return -EPERM;
+
if (off > dev->cfg_size)
return 0;
if (off + count > dev->cfg_size) {
@@ -1167,6 +1170,9 @@ static int pci_mmap_resource(struct kobject *kobj, struct 
bin_attribute *attr,
enum pci_mmap_state mmap_type;
struct resource *res = >resource[bar];
 
+   if (kernel_is_locked_down("Direct PCI access"))
+   return -EPERM;
+
if (res->flags & IORESOURCE_MEM && iomem_is_exclusive(res->start))
return -EINVAL;
 
@@ -1242,6 +1248,9 @@ static ssize_t pci_write_resource_io(struct file *filp, 
struct kobject *kobj,
 struct bin_attribute *attr, char *buf,
 loff_t off, size_t count)
 {
+   if (kernel_is_locked_down("Direct PCI access"))
+   return -EPERM;
+
return pci_resource_io(filp, kobj, attr, buf, off, count, true);
 }
 
diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index 6fa1627ce08d..1549cdd0710e 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -117,6 +117,9 @@ static ssize_t proc_bus_pci_write(struct file *file, const 
char __user *buf,
int size = dev->cfg_size;
int cnt;
 
+   if (kernel_is_locked_down("Direct PCI access"))
+   return -EPERM;
+
if (pos >= size)
return 0;
if (nbytes >= size)
@@ -196,6 +199,9 @@ static long proc_bus_pci_ioctl(struct file *file, unsigned 
int cmd,
 #endif /* HAVE_PCI_MMAP */
int ret = 0;
 
+   if (kernel_is_locked_down("Direct PCI access"))
+   return -EPERM;
+
switch (cmd) {
case PCIIOC_CONTROLLER:
ret = pci_domain_nr(dev->bus);
@@ -237,7 +243,8 @@ static int proc_bus_pci_mmap(struct file *file, struct 
vm_area_struct *vma)
struct pci_filp_private *fpriv = file->private_data;
int i, ret, write_combine = 0, res_bit = IORESOURCE_MEM;
 
-   if (!capable(CAP_SYS_RAWIO))
+   if (!capable(CAP_SYS_RAWIO) ||
+   kernel_is_locked_down("Direct PCI access"))
return -EPERM;
 
if (fpriv->mmap_state == pci_mmap_io) {
diff --git a/drivers/pci/syscall.c b/drivers/pci/syscall.c
index d96626c614f5..b8a08d3166a1 100644
--- a/drivers/pci/syscall.c
+++ b/drivers/pci/syscall.c
@@ -90,7 +90,8 @@ SYSCALL_DEFINE5(pciconfig_write, unsigned long, bus, unsigned 
long, dfn,
u32 dword;
int err = 0;
 
-   if (!capable(CAP_SYS_ADMIN))
+   if (!capable(CAP_SYS_ADMIN) ||
+   kernel_is_locked_down("Direct PCI access"))
return -EPERM;
 
dev = pci_get_domain_bus_and_slot(0, bus, dfn);
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 10/27] uswsusp: Disable when the kernel is locked down

2019-02-28 Thread Matthew Garrett
From: Matthew Garrett 

uswsusp allows a user process to dump and then restore kernel state, which
makes it possible to modify the running kernel.  Disable this if the kernel
is locked down.

Signed-off-by: Matthew Garrett 
Signed-off-by: David Howells 
Reviewed-by: "Lee, Chun-Yi" 
Reviewed-by: James Morris 
cc: linux...@vger.kernel.org
---
 kernel/power/user.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/power/user.c b/kernel/power/user.c
index 2d8b60a3c86b..0305d513c274 100644
--- a/kernel/power/user.c
+++ b/kernel/power/user.c
@@ -52,6 +52,9 @@ static int snapshot_open(struct inode *inode, struct file 
*filp)
if (!hibernation_available())
return -EPERM;
 
+   if (kernel_is_locked_down("/dev/snapshot"))
+   return -EPERM;
+
lock_system_sleep();
 
if (!atomic_add_unless(_device_available, -1, 0)) {
-- 
2.21.0.352.gf09ad66450-goog



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

2019-02-28 Thread Matthew Garrett
From: Linn Crosetto 

>From the kernel documentation (initrd_table_override.txt):

  If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible
  to override nearly any ACPI table provided by the BIOS with an
  instrumented, modified one.

When securelevel is set, the kernel should disallow any unauthenticated
changes to kernel space.  ACPI tables contain code invoked by the kernel,
so do not allow ACPI tables to be overridden if the kernel is locked down.

Signed-off-by: Linn Crosetto 
Signed-off-by: David Howells 
Reviewed-by: "Lee, Chun-Yi" 
cc: linux-a...@vger.kernel.org
---
 drivers/acpi/tables.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 48eabb6c2d4f..f3b4117cd8f3 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -531,6 +531,11 @@ void __init acpi_table_upgrade(void)
if (table_nr == 0)
return;
 
+   if (kernel_is_locked_down("ACPI table override")) {
+   pr_notice("kernel is locked down, ignoring table override\n");
+   return;
+   }
+
acpi_tables_addr =
memblock_find_in_range(0, ACPI_TABLE_UPGRADE_MAX_PHYS,
   all_tables_size, PAGE_SIZE);
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 14/27] ACPI: Limit access to custom_method when the kernel is locked down

2019-02-28 Thread Matthew Garrett
From: Matthew Garrett 

custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to circumvent restrictions on module loading.
Disable it if the kernel is locked down.

Signed-off-by: Matthew Garrett 
Signed-off-by: David Howells 
Reviewed-by: "Lee, Chun-Yi" 
cc: linux-a...@vger.kernel.org
---
 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 4451877f83b6..ac8a90dc7096 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("ACPI custom methods"))
+   return -EPERM;
+
if (!(*ppos)) {
/* parse the table header to get the table length */
if (count <= sizeof(struct acpi_table_header))
-- 
2.21.0.352.gf09ad66450-goog



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

2019-02-28 Thread Matthew Garrett
From: David Howells 

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 image signing key) to
be read by an eBPF program and kernel memory to be altered without
restriction.

Completely prohibit the use of BPF when the kernel is locked down.

Suggested-by: Alexei Starovoitov 
Signed-off-by: David Howells 
cc: net...@vger.kernel.org
cc: Chun-Yi Lee 
cc: Alexei Starovoitov 
---
 kernel/bpf/syscall.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 8577bb7f8be6..e78dbe5473c9 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -2593,6 +2593,9 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, 
uattr, unsigned int, siz
if (sysctl_unprivileged_bpf_disabled && !capable(CAP_SYS_ADMIN))
return -EPERM;
 
+   if (kernel_is_locked_down("BPF"))
+   return -EPERM;
+
err = bpf_check_uarg_tail_zero(uattr, sizeof(attr), size);
if (err)
return err;
-- 
2.21.0.352.gf09ad66450-goog



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

2019-02-28 Thread Matthew Garrett
From: Matthew Garrett 

Writing to MSRs should not be allowed if the kernel is locked down, since
it could lead to execution of arbitrary code in kernel mode.  Based on a
patch by Kees Cook.

MSR accesses are logged for the purposes of building up a whitelist as per
Alan Cox's suggestion.

Signed-off-by: Matthew Garrett 
Signed-off-by: David Howells 
Acked-by: Kees Cook 
Reviewed-by: Thomas Gleixner 
Reviewed-by: "Lee, Chun-Yi" 
cc: x...@kernel.org
---
 arch/x86/kernel/msr.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index 4588414e2561..f5a2cf07972f 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -84,6 +84,11 @@ static ssize_t msr_write(struct file *file, const char 
__user *buf,
int err = 0;
ssize_t bytes = 0;
 
+   if (kernel_is_locked_down("Direct MSR access")) {
+   pr_info("Direct access to MSR %x\n", reg);
+   return -EPERM;
+   }
+
if (count % 8)
return -EINVAL; /* Invalid chunk size */
 
@@ -135,6 +140,11 @@ static long msr_ioctl(struct file *file, unsigned int ioc, 
unsigned long arg)
err = -EFAULT;
break;
}
+   if (kernel_is_locked_down("Direct MSR access")) {
+   pr_info("Direct access to MSR %x\n", regs[1]); /* 
Display %ecx */
+   err = -EPERM;
+   break;
+   }
err = wrmsr_safe_regs_on_cpu(cpu, regs);
if (err)
break;
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 21/27] x86/mmiotrace: Lock down the testmmiotrace module

2019-02-28 Thread Matthew Garrett
From: David Howells 

The testmmiotrace module shouldn't be permitted when the kernel is locked
down as it can be used to arbitrarily read and write MMIO space.

Suggested-by: Thomas Gleixner 
Signed-off-by: David Howells 
cc: Steven Rostedt 
cc: Ingo Molnar 
cc: "H. Peter Anvin" 
cc: x...@kernel.org
---
 arch/x86/mm/testmmiotrace.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/mm/testmmiotrace.c b/arch/x86/mm/testmmiotrace.c
index f6ae6830b341..bbaad357f5d7 100644
--- a/arch/x86/mm/testmmiotrace.c
+++ b/arch/x86/mm/testmmiotrace.c
@@ -115,6 +115,9 @@ static int __init init(void)
 {
unsigned long size = (read_far) ? (8 << 20) : (16 << 10);
 
+   if (kernel_is_locked_down("MMIO trace testing"))
+   return -EPERM;
+
if (mmio_address == 0) {
pr_err("you have to use the module argument mmio_address.\n");
pr_err("DO NOT LOAD THIS MODULE UNLESS YOU REALLY KNOW WHAT YOU 
ARE DOING!\n");
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 19/27] Lock down TIOCSSERIAL

2019-02-28 Thread Matthew Garrett
From: David Howells 

Lock down TIOCSSERIAL as that can be used to change the ioport and irq
settings on a serial port.  This only appears to be an issue for the serial
drivers that use the core serial code.  All other drivers seem to either
ignore attempts to change port/irq or give an error.

Reported-by: Greg Kroah-Hartman 
Signed-off-by: David Howells 
cc: Jiri Slaby 
---
 drivers/tty/serial/serial_core.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 556f50aa1b58..627e859ae25a 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -852,6 +852,12 @@ static int uart_set_info(struct tty_struct *tty, struct 
tty_port *port,
new_flags = (__force upf_t)new_info->flags;
old_custom_divisor = uport->custom_divisor;
 
+   if ((change_port || change_irq) &&
+   kernel_is_locked_down("Using TIOCSSERIAL to change device 
addresses, irqs and dma channels")) {
+   retval = -EPERM;
+   goto exit;
+   }
+
if (!capable(CAP_SYS_ADMIN)) {
retval = -EPERM;
if (change_irq || change_port ||
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 26/27] debugfs: Restrict debugfs when the kernel is locked down

2019-02-28 Thread Matthew Garrett
From: David Howells 

Disallow opening of debugfs files that might be used to muck around when
the kernel is locked down as various drivers give raw access to hardware
through debugfs.  Given the effort of auditing all 2000 or so files and
manually fixing each one as necessary, I've chosen to apply a heuristic
instead.  The following changes are made:

 (1) chmod and chown are disallowed on debugfs objects (though the root dir
 can be modified by mount and remount, but I'm not worried about that).

 (2) When the kernel is locked down, only files with the following criteria
 are permitted to be opened:

- The file must have mode 00444
- The file must not have ioctl methods
- The file must not have mmap

 (3) When the kernel is locked down, files may only be opened for reading.

Normal device interaction should be done through configfs, sysfs or a
miscdev, not debugfs.

Note that this makes it unnecessary to specifically lock down show_dsts(),
show_devs() and show_call() in the asus-wmi driver.

I would actually prefer to lock down all files by default and have the
the files unlocked by the creator.  This is tricky to manage correctly,
though, as there are 19 creation functions and ~1600 call sites (some of
them in loops scanning tables).

Signed-off-by: David Howells 
cc: Andy Shevchenko 
cc: acpi4asus-u...@lists.sourceforge.net
cc: platform-driver-...@vger.kernel.org
cc: Matthew Garrett 
cc: Thomas Gleixner 
---
 fs/debugfs/file.c  | 28 
 fs/debugfs/inode.c | 30 --
 2 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 4fce1da7db23..c33042c1eff3 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -136,6 +136,25 @@ void debugfs_file_put(struct dentry *dentry)
 }
 EXPORT_SYMBOL_GPL(debugfs_file_put);
 
+/*
+ * Only permit access to world-readable files when the kernel is locked down.
+ * We also need to exclude any file that has ways to write or alter it as root
+ * can bypass the permissions check.
+ */
+static bool debugfs_is_locked_down(struct inode *inode,
+  struct file *filp,
+  const struct file_operations *real_fops)
+{
+   if ((inode->i_mode & 0) == 0444 &&
+   !(filp->f_mode & FMODE_WRITE) &&
+   !real_fops->unlocked_ioctl &&
+   !real_fops->compat_ioctl &&
+   !real_fops->mmap)
+   return false;
+
+   return kernel_is_locked_down("debugfs");
+}
+
 static int open_proxy_open(struct inode *inode, struct file *filp)
 {
struct dentry *dentry = F_DENTRY(filp);
@@ -147,6 +166,11 @@ static int open_proxy_open(struct inode *inode, struct 
file *filp)
return r == -EIO ? -ENOENT : r;
 
real_fops = debugfs_real_fops(filp);
+
+   r = -EPERM;
+   if (debugfs_is_locked_down(inode, filp, real_fops))
+   goto out;
+
real_fops = fops_get(real_fops);
if (!real_fops) {
/* Huh? Module did not clean up after itself at exit? */
@@ -272,6 +296,10 @@ static int full_proxy_open(struct inode *inode, struct 
file *filp)
return r == -EIO ? -ENOENT : r;
 
real_fops = debugfs_real_fops(filp);
+   r = -EPERM;
+   if (debugfs_is_locked_down(inode, filp, real_fops))
+   goto out;
+
real_fops = fops_get(real_fops);
if (!real_fops) {
/* Huh? Module did not cleanup after itself at exit? */
diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 29c68c5d44d5..3a62dbfd3840 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -32,6 +32,31 @@ static struct vfsmount *debugfs_mount;
 static int debugfs_mount_count;
 static bool debugfs_registered;
 
+/*
+ * Don't allow access attributes to be changed whilst the kernel is locked down
+ * so that we can use the file mode as part of a heuristic to determine whether
+ * to lock down individual files.
+ */
+static int debugfs_setattr(struct dentry *dentry, struct iattr *ia)
+{
+   if ((ia->ia_valid & (ATTR_MODE | ATTR_UID | ATTR_GID)) &&
+   kernel_is_locked_down("debugfs"))
+   return -EPERM;
+   return simple_setattr(dentry, ia);
+}
+
+static const struct inode_operations debugfs_file_inode_operations = {
+   .setattr= debugfs_setattr,
+};
+static const struct inode_operations debugfs_dir_inode_operations = {
+   .lookup = simple_lookup,
+   .setattr= debugfs_setattr,
+};
+static const struct inode_operations debugfs_symlink_inode_operations = {
+   .get_link   = simple_get_link,
+   .setattr= debugfs_setattr,
+};
+
 static struct inode *debugfs_get_inode(struct super_block *sb)
 {
struct inode *inode = new_inode(sb);
@@ -356,6 +381,7 @@ static struct dentry *__debugfs_create_fi

Re: [PULL REQUEST] Lock down patches

2019-02-28 Thread Matthew Garrett
On Thu, Feb 28, 2019 at 2:20 PM Mimi Zohar  wrote:
> On Thu, 2019-02-28 at 13:28 -0800, Matthew Garrett wrote:
> > This PR is mostly the same as the previous attempt, but with the
> > following changes:
>
> Where/when was this latest version of the patches posted?

They should have followed this, but git-send-email choked on some
reviewed-by: lines so I'm just trying to sort that out.

> >
> > 1) The integration between EFI secure boot and the lockdown state has
> > been removed
> > 2) A new CONFIG_KERNEL_LOCK_DOWN_FORCE kconfig option has been added,
> > which will always enable lockdown regardless of the kernel command
> > line
> > 3) The integration with IMA has been dropped for now. Requiring the
> > use of the IMA secure boot policy when lockdown is enabled isn't
> > practical for most distributions at the moment, as there's still not a
> > great deal of infrastructure for shipping packages with appropriate
> > IMA signatures, and it makes it complicated for end users to manage
> > custom IMA policies.
>
> I'm all in favor of dropping the original attempt to coordinate
> between the kexec PE and IMA kernel image signatures and the kernel
> appended and IMA modules signatures, but there has been quite a bit of
> work recently coordinating the different types of signatures.
>
> Preventing systems which do use IMA for signature verification, should
> not limit their ability to enable "lock down".  Does this version of
> the "lock down" patches coordinate the different kexec kernel image
> and kernel module signature verification methods?

It's a little more complicated than this. We can't just rely on IMA
appraisal - it has to be based on digital signatures, and the existing
patch only made that implicit by enabling the secure_boot policy. I
think we do want to integrate these, but there's a few things we need
to take into account:

1) An integrated solution can't depend on xattrs, both because of the
lagging support for distributing those signatures but also because we
need to support filesystems that don't support xattrs
2) An integrated solution can't depend on the current secure_boot
policy because that requires signed IMA policy updates, but
distributions have no way of knowing what IMA policy end users require

In any case, I do agree that we should aim to make this more
reasonable - having orthogonal signing code doesn't benefit anyone.
Once there's solid agreement on that we can extend this support.


[PATCH 23/27] Lock down kprobes

2019-02-28 Thread Matthew Garrett
From: David Howells 

Disallow the creation of kprobes when the kernel is locked down by
preventing their registration.  This prevents kprobes from being used to
access kernel memory, either to make modifications or to steal crypto data.

Reported-by: Alexei Starovoitov 
Signed-off-by: David Howells 
---
 kernel/kprobes.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index f4ddfdd2d07e..6f66cca8e2c6 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1552,6 +1552,9 @@ int register_kprobe(struct kprobe *p)
struct module *probed_mod;
kprobe_opcode_t *addr;
 
+   if (kernel_is_locked_down("Use of kprobes"))
+   return -EPERM;
+
/* Adjust probe address from symbol */
addr = kprobe_addr(p);
if (IS_ERR(addr))
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 27/27] lockdown: Print current->comm in restriction messages

2019-02-28 Thread Matthew Garrett
From: David Howells 

Print the content of current->comm in messages generated by lockdown to
indicate a restriction that was hit.  This makes it a bit easier to find
out what caused the message.

The message now patterned something like:

Lockdown: :  is restricted; see man kernel_lockdown.7

Signed-off-by: David Howells 
---
 security/lock_down.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/security/lock_down.c b/security/lock_down.c
index cfbc2c39712b..5243b55b3c1f 100644
--- a/security/lock_down.c
+++ b/security/lock_down.c
@@ -58,8 +58,8 @@ void __init init_lockdown(void)
 bool __kernel_is_locked_down(const char *what, bool first)
 {
if (what && first && kernel_locked_down)
-   pr_notice("Lockdown: %s is restricted; see man 
kernel_lockdown.7\n",
- what);
+   pr_notice("Lockdown: %s: %s is restricted; see man 
kernel_lockdown.7\n",
+ current->comm, what);
return kernel_locked_down;
 }
 EXPORT_SYMBOL(__kernel_is_locked_down);
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 18/27] Prohibit PCMCIA CIS storage when the kernel is locked down

2019-02-28 Thread Matthew Garrett
From: David Howells 

Prohibit replacement of the PCMCIA Card Information Structure when the
kernel is locked down.

Suggested-by: Dominik Brodowski 
Signed-off-by: David Howells 
cc: linux-pcm...@lists.infradead.org
---
 drivers/pcmcia/cistpl.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pcmcia/cistpl.c b/drivers/pcmcia/cistpl.c
index ac0672b8dfca..8adf092d0e18 100644
--- a/drivers/pcmcia/cistpl.c
+++ b/drivers/pcmcia/cistpl.c
@@ -1578,6 +1578,9 @@ static ssize_t pccard_store_cis(struct file *filp, struct 
kobject *kobj,
struct pcmcia_socket *s;
int error;
 
+   if (kernel_is_locked_down("Direct PCMCIA CIS storage"))
+   return -EPERM;
+
s = to_socket(container_of(kobj, struct device, kobj));
 
if (off)
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 25/27] Lock down perf

2019-02-28 Thread Matthew Garrett
From: David Howells 

Disallow the use of certain perf facilities that might allow userspace to
access kernel data.

Signed-off-by: David Howells 
---
 kernel/events/core.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 26d6edab051a..4265ce43bca4 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -10477,6 +10477,11 @@ SYSCALL_DEFINE5(perf_event_open,
return -EINVAL;
}
 
+   if ((attr.sample_type & PERF_SAMPLE_REGS_INTR) &&
+   kernel_is_locked_down("PERF_SAMPLE_REGS_INTR"))
+   /* REGS_INTR can leak data, lockdown must prevent this */
+   return -EPERM;
+
/* Only privileged users can get physical addresses */
if ((attr.sample_type & PERF_SAMPLE_PHYS_ADDR) &&
perf_paranoid_kernel() && !capable(CAP_SYS_ADMIN))
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 22/27] Lock down /proc/kcore

2019-02-28 Thread Matthew Garrett
From: David Howells 

Disallow access to /proc/kcore when the kernel is locked down to prevent
access to cryptographic data.

Signed-off-by: David Howells 
Reviewed-by: James Morris 
---
 fs/proc/kcore.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index bbcc185062bb..d50ebfbf3dbb 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -518,6 +518,8 @@ read_kcore(struct file *file, char __user *buffer, size_t 
buflen, loff_t *fpos)
 
 static int open_kcore(struct inode *inode, struct file *filp)
 {
+   if (kernel_is_locked_down("/proc/kcore"))
+   return -EPERM;
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
 
-- 
2.21.0.352.gf09ad66450-goog



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

2019-02-28 Thread Matthew Garrett
From: Josh Boyer 

This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to modify the workings of hardware .  Reject
the option when the kernel is locked down.

Signed-off-by: Josh Boyer 
Signed-off-by: David Howells 
Reviewed-by: "Lee, Chun-Yi" 
cc: Dave Young 
cc: linux-a...@vger.kernel.org
---
 drivers/acpi/osl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index f29e427d0d1d..3e44cef7a0cd 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -194,7 +194,7 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
acpi_physical_address pa;
 
 #ifdef CONFIG_KEXEC
-   if (acpi_rsdp)
+   if (acpi_rsdp && !kernel_is_locked_down("ACPI RSDP specification"))
return acpi_rsdp;
 #endif
pa = acpi_arch_get_root_pointer();
-- 
2.21.0.352.gf09ad66450-goog



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

2019-02-28 Thread Matthew Garrett
From: David Howells 

If the kernel is locked down, require that all modules have valid
signatures that we can verify or that IMA can validate the file.

I have adjusted the errors generated:

 (1) If there's no signature (ENODATA) or we can't check it (ENOPKG,
 ENOKEY), then:

 (a) If signatures are enforced then EKEYREJECTED is returned.

 (b) If IMA will have validated the image, return 0 (okay).

 (c) If there's no signature or we can't check it, but the kernel is
 locked down then EPERM is returned (this is then consistent with
 other lockdown cases).

 (2) If the signature is unparseable (EBADMSG, EINVAL), the signature fails
 the check (EKEYREJECTED) or a system error occurs (eg. ENOMEM), we
 return the error we got.

Note that the X.509 code doesn't check for key expiry as the RTC might not
be valid or might not have been transferred to the kernel's clock yet.

Signed-off-by: David Howells 
Reviewed-by: Jiri Bohac 
cc: "Lee, Chun-Yi" 
cc: James Morris 
---
 kernel/module.c | 56 +
 1 file changed, 43 insertions(+), 13 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index 2ad1b5239910..afa5489be39f 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -64,6 +64,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "module-internal.h"
 
@@ -2765,10 +2766,12 @@ static inline void kmemleak_load_module(const struct 
module *mod,
 #endif
 
 #ifdef CONFIG_MODULE_SIG
-static int module_sig_check(struct load_info *info, int flags)
+static int module_sig_check(struct load_info *info, int flags,
+   bool can_do_ima_check)
 {
-   int err = -ENOKEY;
+   int err = -ENODATA;
const unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
+   const char *reason;
const void *mod = info->hdr;
 
/*
@@ -2783,19 +2786,46 @@ static int module_sig_check(struct load_info *info, int 
flags)
err = mod_verify_sig(mod, info);
}
 
-   if (!err) {
+   switch (err) {
+   case 0:
info->sig_ok = true;
return 0;
-   }
 
-   /* Not having a signature is only an error if we're strict. */
-   if (err == -ENOKEY && !is_module_sig_enforced())
-   err = 0;
+   /* We don't permit modules to be loaded into trusted kernels
+* without a valid signature on them, but if we're not
+* enforcing, certain errors are non-fatal.
+*/
+   case -ENODATA:
+   reason = "Loading of unsigned module";
+   goto decide;
+   case -ENOPKG:
+   reason = "Loading of module with unsupported crypto";
+   goto decide;
+   case -ENOKEY:
+   reason = "Loading of module with unavailable key";
+   decide:
+   if (is_module_sig_enforced()) {
+   pr_notice("%s is rejected\n", reason);
+   return -EKEYREJECTED;
+   }
 
-   return err;
+   if (can_do_ima_check && is_ima_appraise_enabled())
+   return 0;
+   if (kernel_is_locked_down(reason))
+   return -EPERM;
+   return 0;
+
+   /* All other errors are fatal, including nomem, unparseable
+* signatures and signature check failures - even if signatures
+* aren't required.
+*/
+   default:
+   return err;
+   }
 }
 #else /* !CONFIG_MODULE_SIG */
-static int module_sig_check(struct load_info *info, int flags)
+static int module_sig_check(struct load_info *info, int flags,
+   bool can_do_ima_check)
 {
return 0;
 }
@@ -3658,7 +3688,7 @@ static int unknown_module_param_cb(char *param, char 
*val, const char *modname,
 /* Allocate and load the module: note that size of section 0 is always
zero, and we rely on this for optional sections. */
 static int load_module(struct load_info *info, const char __user *uargs,
-  int flags)
+  int flags, bool can_do_ima_check)
 {
struct module *mod;
long err = 0;
@@ -3677,7 +3707,7 @@ static int load_module(struct load_info *info, const char 
__user *uargs,
goto free_copy;
}
 
-   err = module_sig_check(info, flags);
+   err = module_sig_check(info, flags, can_do_ima_check);
if (err)
goto free_copy;
 
@@ -3872,7 +3902,7 @@ SYSCALL_DEFINE3(init_module, void __user *, umod,
if (err)
return err;
 
-   return load_module(, uargs, 0);
+   return load_module(, uargs, 0, false);
 }
 
 SYSCALL_DEFINE3(finit_module, int, fd, const char __user *, uargs, int, flags)
@@ -3899,7 +3929,7 @@ SYSCALL_DEFINE3(finit_module, int, fd, const char __user 
*, uargs, int, flags)
info.hdr = hdr;
info.len = 

[PATCH 02/27] Add a SysRq option to lift kernel lockdown

2019-02-28 Thread Matthew Garrett
From: Kyle McMartin 

Make an option to provide a sysrq key that will lift the kernel lockdown,
thereby allowing the running kernel image to be accessed and modified.

On x86 this is triggered with SysRq+x, but this key may not be available on
all arches, so it is set by setting LOCKDOWN_LIFT_KEY in asm/setup.h.
Since this macro must be defined in an arch to be able to use this facility
for that arch, the Kconfig option is restricted to arches that support it.

Signed-off-by: Kyle McMartin 
Signed-off-by: David Howells 
cc: x...@kernel.org
---
 arch/x86/include/asm/setup.h |  2 ++
 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 +-
 security/Kconfig |  9 +++
 security/lock_down.c | 47 
 8 files changed, 85 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index ed8ec011a9fd..8daf633a5347 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -9,6 +9,8 @@
 #include 
 #include 
 
+#define LOCKDOWN_LIFT_KEY 'x'
+
 #ifdef __i386__
 
 #include 
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index 26ec603fe220..a73e92490286 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -366,6 +366,7 @@ static int uinput_create_device(struct uinput_device *udev)
dev->flush = uinput_dev_flush;
}
 
+   dev->flags |= INPUTDEV_FLAGS_SYNTHETIC;
dev->event = uinput_dev_event;
 
input_set_drvdata(udev->dev, udev);
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 1f03078ec352..0a05d336008e 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -480,6 +480,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 */
@@ -523,7 +524,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;
@@ -543,11 +544,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);
@@ -579,7 +584,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(struct timer_list *t)
 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(>keyreset_timer,
@@ -812,8 +817,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;
}
@@ -1096,7 +1103,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);

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

2019-02-28 Thread Matthew Garrett
From: Linn Crosetto 

ACPI provides an error injection mechanism, EINJ, for debugging and testing
the ACPI Platform Error Interface (APEI) and other RAS features.  If
supported by the firmware, ACPI specification 5.0 and later provide for a
way to specify a physical memory address to which to inject the error.

Injecting errors through EINJ can produce errors which to the platform are
indistinguishable from real hardware errors.  This can have undesirable
side-effects, such as causing the platform to mark hardware as needing
replacement.

While it does not provide a method to load unauthenticated privileged code,
the effect of these errors may persist across reboots and affect trust in
the underlying hardware, so disable error injection through EINJ if
the kernel is locked down.

Signed-off-by: Linn Crosetto 
Signed-off-by: David Howells 
Reviewed-by: "Lee, Chun-Yi" 
cc: linux-a...@vger.kernel.org
---
 drivers/acpi/apei/einj.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c
index fcccbfdbdd1a..9fe6bbab2e7d 100644
--- a/drivers/acpi/apei/einj.c
+++ b/drivers/acpi/apei/einj.c
@@ -518,6 +518,9 @@ static int einj_error_inject(u32 type, u32 flags, u64 
param1, u64 param2,
int rc;
u64 base_addr, size;
 
+   if (kernel_is_locked_down("ACPI error injection"))
+   return -EPERM;
+
/* If user manually set "flags", make sure it is legal */
if (flags && (flags &
~(SETWA_FLAGS_APICID|SETWA_FLAGS_MEM|SETWA_FLAGS_PCIE_SBDF)))
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 04/27] Restrict /dev/{mem,kmem,port} when the kernel is locked down

2019-02-28 Thread Matthew Garrett
From: Matthew Garrett 

Allowing users to read and write to core kernel memory makes it possible
for the kernel to be subverted, avoiding module loading restrictions, and
also to steal cryptographic information.

Disallow /dev/mem and /dev/kmem from being opened this when the kernel has
been locked down to prevent this.

Also disallow /dev/port from being opened to prevent raw ioport access and
thus DMA from being used to accomplish the same thing.

Signed-off-by: Matthew Garrett 
Signed-off-by: David Howells 
Reviewed-by: "Lee, Chun-Yi" 
---
 drivers/char/mem.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index b08dc50f9f26..0a2f2e75d5f4 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -786,6 +786,8 @@ static loff_t memory_lseek(struct file *file, loff_t 
offset, int orig)
 
 static int open_port(struct inode *inode, struct file *filp)
 {
+   if (kernel_is_locked_down("/dev/mem,kmem,port"))
+   return -EPERM;
return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
 }
 
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 20/27] Lock down module params that specify hardware parameters (eg. ioport)

2019-02-28 Thread Matthew Garrett
From: David Howells 

Provided an annotation for module parameters that specify hardware
parameters (such as io ports, iomem addresses, irqs, dma channels, fixed
dma buffers and other types).

Suggested-by: Alan Cox 
Signed-off-by: David Howells 
---
 kernel/params.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/kernel/params.c b/kernel/params.c
index ce89f757e6da..8ac751c938f8 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -108,13 +108,19 @@ bool parameq(const char *a, const char *b)
return parameqn(a, b, strlen(a)+1);
 }
 
-static void param_check_unsafe(const struct kernel_param *kp)
+static bool param_check_unsafe(const struct kernel_param *kp,
+  const char *doing)
 {
if (kp->flags & KERNEL_PARAM_FL_UNSAFE) {
pr_notice("Setting dangerous option %s - tainting kernel\n",
  kp->name);
add_taint(TAINT_USER, LOCKDEP_STILL_OK);
}
+
+   if (kp->flags & KERNEL_PARAM_FL_HWPARAM &&
+   kernel_is_locked_down("Command line-specified device addresses, 
irqs and dma channels"))
+   return false;
+   return true;
 }
 
 static int parse_one(char *param,
@@ -144,8 +150,10 @@ static int parse_one(char *param,
pr_debug("handling %s with %p\n", param,
params[i].ops->set);
kernel_param_lock(params[i].mod);
-   param_check_unsafe([i]);
-   err = params[i].ops->set(val, [i]);
+   if (param_check_unsafe([i], doing))
+   err = params[i].ops->set(val, [i]);
+   else
+   err = -EPERM;
kernel_param_unlock(params[i].mod);
return err;
}
@@ -553,6 +561,12 @@ static ssize_t param_attr_show(struct module_attribute 
*mattr,
return count;
 }
 
+#ifdef CONFIG_MODULES
+#define mod_name(mod) (mod)->name
+#else
+#define mod_name(mod) "unknown"
+#endif
+
 /* sysfs always hands a nul-terminated string in buf.  We rely on that. */
 static ssize_t param_attr_store(struct module_attribute *mattr,
struct module_kobject *mk,
@@ -565,8 +579,10 @@ static ssize_t param_attr_store(struct module_attribute 
*mattr,
return -EPERM;
 
kernel_param_lock(mk->mod);
-   param_check_unsafe(attribute->param);
-   err = attribute->param->ops->set(buf, attribute->param);
+   if (param_check_unsafe(attribute->param, mod_name(mk->mod)))
+   err = attribute->param->ops->set(buf, attribute->param);
+   else
+   err = -EPERM;
kernel_param_unlock(mk->mod);
if (!err)
return len;
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 01/27] Add the ability to lock down access to the running kernel image

2019-02-28 Thread Matthew Garrett
From: David Howells 

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 registers and disallowing hibernation.

Signed-off-by: David Howells 
Acked-by: James Morris 
---
 include/linux/kernel.h   | 17 
 include/linux/security.h |  9 +-
 security/Kconfig | 15 ++
 security/Makefile|  3 ++
 security/lock_down.c | 59 
 5 files changed, 102 insertions(+), 1 deletion(-)
 create mode 100644 security/lock_down.c

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 8f0e68e250a7..833bf32ce4e6 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -340,6 +340,23 @@ static inline void refcount_error_report(struct pt_regs 
*regs, const char *err)
 { }
 #endif
 
+#ifdef CONFIG_LOCK_DOWN_KERNEL
+extern bool __kernel_is_locked_down(const char *what, bool first);
+#else
+static inline bool __kernel_is_locked_down(const char *what, bool first)
+{
+   return false;
+}
+#endif
+
+#define kernel_is_locked_down(what)\
+   ({  \
+   static bool message_given;  \
+   bool locked_down = __kernel_is_locked_down(what, 
!message_given); \
+   message_given = true;   \
+   locked_down;\
+   })
+
 /* Internal, do not use. */
 int __must_check _kstrtoul(const char *s, unsigned int base, unsigned long 
*res);
 int __must_check _kstrtol(const char *s, unsigned int base, long *res);
diff --git a/include/linux/security.h b/include/linux/security.h
index dbfb5a66babb..35f0be540e0b 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -1793,5 +1793,12 @@ static inline void security_bpf_prog_free(struct 
bpf_prog_aux *aux)
 #endif /* CONFIG_SECURITY */
 #endif /* CONFIG_BPF_SYSCALL */
 
-#endif /* ! __LINUX_SECURITY_H */
+#ifdef CONFIG_LOCK_DOWN_KERNEL
+extern void __init init_lockdown(void);
+#else
+static inline void __init init_lockdown(void)
+{
+}
+#endif
 
+#endif /* ! __LINUX_SECURITY_H */
diff --git a/security/Kconfig b/security/Kconfig
index e4fe2f3c2c65..c2aff0006de2 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -230,6 +230,21 @@ config STATIC_USERMODEHELPER_PATH
  If you wish for all usermode helper programs to be disabled,
  specify an empty string here (i.e. "").
 
+config LOCK_DOWN_KERNEL
+   bool "Allow the kernel to be 'locked down'"
+   help
+ Allow the kernel to be locked down. If lockdown support is enabled
+ and activated, the kernel will impose additional restrictions
+ intended to prevent uid 0 from being able to modify the running
+ kernel. This may break userland applications that rely on low-level
+ access to hardware.
+
+config LOCK_DOWN_KERNEL_FORCE
+bool "Enable kernel lockdown mode automatically"
+depends on LOCK_DOWN_KERNEL
+help
+  Enable the kernel lock down functionality automatically at boot.
+
 source "security/selinux/Kconfig"
 source "security/smack/Kconfig"
 source "security/tomoyo/Kconfig"
diff --git a/security/Makefile b/security/Makefile
index 4d2d3782ddef..507ac8c520ce 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -30,3 +30,6 @@ obj-$(CONFIG_CGROUP_DEVICE)   += device_cgroup.o
 # Object integrity file lists
 subdir-$(CONFIG_INTEGRITY) += integrity
 obj-$(CONFIG_INTEGRITY)+= integrity/
+
+# Allow the kernel to be locked down
+obj-$(CONFIG_LOCK_DOWN_KERNEL) += lock_down.o
diff --git a/security/lock_down.c b/security/lock_down.c
new file mode 100644
index ..13a8228c1034
--- /dev/null
+++ b/security/lock_down.c
@@ -0,0 +1,59 @@
+/* Lock down the kernel
+ *
+ * Copyright (C) 2016 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowe...@redhat.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public Licence
+ * as published by the Free Software Foundation; either version
+ * 2 of the Licence, or (at your option) any later version.
+ */
+
+#include 
+#include 
+
+static __ro_after_init bool kernel_locked_down;
+
+/*
+ * Put the kernel into lock-down mode.
+ */
+static void __init lock_kernel_down(const char *where)
+{
+   if (!kernel_locked_down) {
+   kernel_locked_down = true;
+   pr_notice("Kernel is locked down from %s; see man 
kernel_lockdown.7\n",
+ where);
+   }
+}
+
+static int __init lockdown_param(char *ignored)
+{
+   lock_kernel_down("command 

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

2019-02-28 Thread Matthew Garrett
From: Matthew Garrett 

The kexec_load() syscall 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_load() in this situation.

This does not affect kexec_file_load() syscall which can check for a
signature on the image to be booted.

Signed-off-by: Matthew Garrett 
Signed-off-by: David Howells 
Acked-by: Dave Young 
Reviewed-by: "Lee, Chun-Yi" 
Reviewed-by: James Morris 
cc: ke...@lists.infradead.org
---
 kernel/kexec.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/kernel/kexec.c b/kernel/kexec.c
index 68559808fdfa..8ea0ce31271f 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -207,6 +207,13 @@ static inline int kexec_load_check(unsigned long 
nr_segments,
if (result < 0)
return result;
 
+   /*
+* kexec can be used to circumvent module loading restrictions, so
+* prevent loading in that case
+*/
+   if (kernel_is_locked_down("kexec of unsigned images"))
+   return -EPERM;
+
/*
 * Verify we have a legal set of flags
 * This leaves us room for future extensions.
-- 
2.21.0.352.gf09ad66450-goog



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

2019-02-28 Thread Matthew Garrett
From: Josh Boyer 

There is currently no way to verify the resume image when returning
from hibernate.  This might compromise the signed modules trust model,
so until we can work with signed hibernate images we disable it when the
kernel is locked down.

Signed-off-by: Josh Boyer 
Signed-off-by: David Howells 
Reviewed-by: "Lee, Chun-Yi" 
cc: linux...@vger.kernel.org
---
 kernel/power/hibernate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index abef759de7c8..802795becb88 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -70,7 +70,7 @@ static const struct platform_hibernation_ops *hibernation_ops;
 
 bool hibernation_available(void)
 {
-   return (nohibernate == 0);
+   return nohibernate == 0 && !kernel_is_locked_down("Hibernation");
 }
 
 /**
-- 
2.21.0.352.gf09ad66450-goog



[PATCH 07/27] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

2019-02-28 Thread Matthew Garrett
From: Jiri Bohac 

This is a preparatory patch for kexec_file_load() lockdown.  A locked down
kernel needs to prevent unsigned kernel images from being loaded with
kexec_file_load().  Currently, the only way to force the signature
verification is compiling with KEXEC_VERIFY_SIG.  This prevents loading
usigned images even when the kernel is not locked down at runtime.

This patch splits KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE.
Analogous to the MODULE_SIG and MODULE_SIG_FORCE for modules, KEXEC_SIG
turns on the signature verification but allows unsigned images to be
loaded.  KEXEC_SIG_FORCE disallows images without a valid signature.

[Modified by David Howells such that:

 (1) verify_pefile_signature() differentiates between no-signature and
 sig-didn't-match in its returned errors.

 (2) kexec fails with EKEYREJECTED and logs an appropriate message if
 signature checking is enforced and an signature is not found, uses
 unsupported crypto or has no matching key.

 (3) kexec fails with EKEYREJECTED if there is a signature for which we
 have a key, but signature doesn't match - even if in non-forcing mode.

 (4) kexec fails with EBADMSG or some other error if there is a signature
 which cannot be parsed - even if in non-forcing mode.

 (5) kexec fails with ELIBBAD if the PE file cannot be parsed to extract
 the signature - even if in non-forcing mode.

]

Signed-off-by: Jiri Bohac 
Signed-off-by: David Howells 
Reviewed-by: Jiri Bohac 
cc: Matthew Garrett 
cc: Chun-Yi Lee 
cc: ke...@lists.infradead.org
---
 arch/x86/Kconfig   | 20 ---
 crypto/asymmetric_keys/verify_pefile.c |  4 ++-
 include/linux/kexec.h  |  4 +--
 kernel/kexec_file.c| 48 ++
 4 files changed, 61 insertions(+), 15 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 68261430fe6e..710f77a0caef 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2016,20 +2016,30 @@ config KEXEC_FILE
 config ARCH_HAS_KEXEC_PURGATORY
def_bool KEXEC_FILE
 
-config KEXEC_VERIFY_SIG
+config KEXEC_SIG
bool "Verify kernel signature during kexec_file_load() syscall"
depends on KEXEC_FILE
---help---
- This option makes kernel signature verification mandatory for
- the kexec_file_load() syscall.
 
- In addition to that option, you need to enable signature
+ This option makes the kexec_file_load() syscall check for a valid
+ signature of the kernel image.  The image can still be loaded without
+ a valid signature unless you also enable KEXEC_SIG_FORCE, though if
+ there's a signature that we can check, then it must be valid.
+
+ In addition to this option, you need to enable signature
  verification for the corresponding kernel image type being
  loaded in order for this to work.
 
+config KEXEC_SIG_FORCE
+   bool "Require a valid signature in kexec_file_load() syscall"
+   depends on KEXEC_SIG
+   ---help---
+ This option makes kernel signature verification mandatory for
+ the kexec_file_load() syscall.
+
 config KEXEC_BZIMAGE_VERIFY_SIG
bool "Enable bzImage signature verification support"
-   depends on KEXEC_VERIFY_SIG
+   depends on KEXEC_SIG
depends on SIGNED_PE_FILE_VERIFICATION
select SYSTEM_TRUSTED_KEYRING
---help---
diff --git a/crypto/asymmetric_keys/verify_pefile.c 
b/crypto/asymmetric_keys/verify_pefile.c
index d178650fd524..4473cea1e877 100644
--- a/crypto/asymmetric_keys/verify_pefile.c
+++ b/crypto/asymmetric_keys/verify_pefile.c
@@ -100,7 +100,7 @@ static int pefile_parse_binary(const void *pebuf, unsigned 
int pelen,
 
if (!ddir->certs.virtual_address || !ddir->certs.size) {
pr_debug("Unsigned PE binary\n");
-   return -EKEYREJECTED;
+   return -ENODATA;
}
 
chkaddr(ctx->header_size, ddir->certs.virtual_address,
@@ -408,6 +408,8 @@ static int pefile_digest_pe(const void *pebuf, unsigned int 
pelen,
  *  (*) 0 if at least one signature chain intersects with the keys in the trust
  * keyring, or:
  *
+ *  (*) -ENODATA if there is no signature present.
+ *
  *  (*) -ENOPKG if a suitable crypto module couldn't be found for a check on a
  * chain.
  *
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index b9b1bc5f9669..58b27c7bdc2b 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -125,7 +125,7 @@ typedef void *(kexec_load_t)(struct kimage *image, char 
*kernel_buf,
 unsigned long cmdline_len);
 typedef int (kexec_cleanup_t)(void *loader_data);
 
-#ifdef CONFIG_KEXEC_VERIFY_SIG
+#ifdef CONFIG_KEXEC_SIG
 typedef int (kexec_verify_sig_t)(const char *kernel_buf,
 unsigned long kernel_len);
 #endif
@@ -134,7 +134,7 @@ 

[PATCH 02/27] Add a SysRq option to lift kernel lockdown

2019-02-28 Thread Matthew Garrett
From: Kyle McMartin 

Make an option to provide a sysrq key that will lift the kernel lockdown,
thereby allowing the running kernel image to be accessed and modified.

On x86 this is triggered with SysRq+x, but this key may not be available on
all arches, so it is set by setting LOCKDOWN_LIFT_KEY in asm/setup.h.
Since this macro must be defined in an arch to be able to use this facility
for that arch, the Kconfig option is restricted to arches that support it.

Signed-off-by: Kyle McMartin 
Signed-off-by: David Howells 
cc: x...@kernel.org
---
 arch/x86/include/asm/setup.h |  2 ++
 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 +-
 security/Kconfig |  9 +++
 security/lock_down.c | 47 
 8 files changed, 85 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index ed8ec011a9fd..8daf633a5347 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -9,6 +9,8 @@
 #include 
 #include 
 
+#define LOCKDOWN_LIFT_KEY 'x'
+
 #ifdef __i386__
 
 #include 
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index 26ec603fe220..a73e92490286 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -366,6 +366,7 @@ static int uinput_create_device(struct uinput_device *udev)
dev->flush = uinput_dev_flush;
}
 
+   dev->flags |= INPUTDEV_FLAGS_SYNTHETIC;
dev->event = uinput_dev_event;
 
input_set_drvdata(udev->dev, udev);
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 1f03078ec352..0a05d336008e 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -480,6 +480,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 */
@@ -523,7 +524,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;
@@ -543,11 +544,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);
@@ -579,7 +584,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(struct timer_list *t)
 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(>keyreset_timer,
@@ -812,8 +817,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;
}
@@ -1096,7 +1103,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);

[PATCH 01/27] Add the ability to lock down access to the running kernel image

2019-02-28 Thread Matthew Garrett
From: David Howells 

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 registers and disallowing hibernation.

Signed-off-by: David Howells 
Acked-by: James Morris 
---
 include/linux/kernel.h   | 17 
 include/linux/security.h |  9 +-
 security/Kconfig | 15 ++
 security/Makefile|  3 ++
 security/lock_down.c | 59 
 5 files changed, 102 insertions(+), 1 deletion(-)
 create mode 100644 security/lock_down.c

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 8f0e68e250a7..833bf32ce4e6 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -340,6 +340,23 @@ static inline void refcount_error_report(struct pt_regs 
*regs, const char *err)
 { }
 #endif
 
+#ifdef CONFIG_LOCK_DOWN_KERNEL
+extern bool __kernel_is_locked_down(const char *what, bool first);
+#else
+static inline bool __kernel_is_locked_down(const char *what, bool first)
+{
+   return false;
+}
+#endif
+
+#define kernel_is_locked_down(what)\
+   ({  \
+   static bool message_given;  \
+   bool locked_down = __kernel_is_locked_down(what, 
!message_given); \
+   message_given = true;   \
+   locked_down;\
+   })
+
 /* Internal, do not use. */
 int __must_check _kstrtoul(const char *s, unsigned int base, unsigned long 
*res);
 int __must_check _kstrtol(const char *s, unsigned int base, long *res);
diff --git a/include/linux/security.h b/include/linux/security.h
index dbfb5a66babb..35f0be540e0b 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -1793,5 +1793,12 @@ static inline void security_bpf_prog_free(struct 
bpf_prog_aux *aux)
 #endif /* CONFIG_SECURITY */
 #endif /* CONFIG_BPF_SYSCALL */
 
-#endif /* ! __LINUX_SECURITY_H */
+#ifdef CONFIG_LOCK_DOWN_KERNEL
+extern void __init init_lockdown(void);
+#else
+static inline void __init init_lockdown(void)
+{
+}
+#endif
 
+#endif /* ! __LINUX_SECURITY_H */
diff --git a/security/Kconfig b/security/Kconfig
index e4fe2f3c2c65..c2aff0006de2 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -230,6 +230,21 @@ config STATIC_USERMODEHELPER_PATH
  If you wish for all usermode helper programs to be disabled,
  specify an empty string here (i.e. "").
 
+config LOCK_DOWN_KERNEL
+   bool "Allow the kernel to be 'locked down'"
+   help
+ Allow the kernel to be locked down. If lockdown support is enabled
+ and activated, the kernel will impose additional restrictions
+ intended to prevent uid 0 from being able to modify the running
+ kernel. This may break userland applications that rely on low-level
+ access to hardware.
+
+config LOCK_DOWN_KERNEL_FORCE
+bool "Enable kernel lockdown mode automatically"
+depends on LOCK_DOWN_KERNEL
+help
+  Enable the kernel lock down functionality automatically at boot.
+
 source "security/selinux/Kconfig"
 source "security/smack/Kconfig"
 source "security/tomoyo/Kconfig"
diff --git a/security/Makefile b/security/Makefile
index 4d2d3782ddef..507ac8c520ce 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -30,3 +30,6 @@ obj-$(CONFIG_CGROUP_DEVICE)   += device_cgroup.o
 # Object integrity file lists
 subdir-$(CONFIG_INTEGRITY) += integrity
 obj-$(CONFIG_INTEGRITY)+= integrity/
+
+# Allow the kernel to be locked down
+obj-$(CONFIG_LOCK_DOWN_KERNEL) += lock_down.o
diff --git a/security/lock_down.c b/security/lock_down.c
new file mode 100644
index ..13a8228c1034
--- /dev/null
+++ b/security/lock_down.c
@@ -0,0 +1,59 @@
+/* Lock down the kernel
+ *
+ * Copyright (C) 2016 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowe...@redhat.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public Licence
+ * as published by the Free Software Foundation; either version
+ * 2 of the Licence, or (at your option) any later version.
+ */
+
+#include 
+#include 
+
+static __ro_after_init bool kernel_locked_down;
+
+/*
+ * Put the kernel into lock-down mode.
+ */
+static void __init lock_kernel_down(const char *where)
+{
+   if (!kernel_locked_down) {
+   kernel_locked_down = true;
+   pr_notice("Kernel is locked down from %s; see man 
kernel_lockdown.7\n",
+ where);
+   }
+}
+
+static int __init lockdown_param(char *ignored)
+{
+   lock_kernel_down("command 

[PATCH 01/27] Add the ability to lock down access to the running kernel image

2019-02-28 Thread Matthew Garrett
From: David Howells 

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 registers and disallowing hibernation.

Signed-off-by: David Howells 
Acked-by: James Morris 
---
 include/linux/kernel.h   | 17 
 include/linux/security.h |  9 +-
 security/Kconfig | 15 ++
 security/Makefile|  3 ++
 security/lock_down.c | 59 
 5 files changed, 102 insertions(+), 1 deletion(-)
 create mode 100644 security/lock_down.c

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 8f0e68e250a7..833bf32ce4e6 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -340,6 +340,23 @@ static inline void refcount_error_report(struct pt_regs 
*regs, const char *err)
 { }
 #endif
 
+#ifdef CONFIG_LOCK_DOWN_KERNEL
+extern bool __kernel_is_locked_down(const char *what, bool first);
+#else
+static inline bool __kernel_is_locked_down(const char *what, bool first)
+{
+   return false;
+}
+#endif
+
+#define kernel_is_locked_down(what)\
+   ({  \
+   static bool message_given;  \
+   bool locked_down = __kernel_is_locked_down(what, 
!message_given); \
+   message_given = true;   \
+   locked_down;\
+   })
+
 /* Internal, do not use. */
 int __must_check _kstrtoul(const char *s, unsigned int base, unsigned long 
*res);
 int __must_check _kstrtol(const char *s, unsigned int base, long *res);
diff --git a/include/linux/security.h b/include/linux/security.h
index dbfb5a66babb..35f0be540e0b 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -1793,5 +1793,12 @@ static inline void security_bpf_prog_free(struct 
bpf_prog_aux *aux)
 #endif /* CONFIG_SECURITY */
 #endif /* CONFIG_BPF_SYSCALL */
 
-#endif /* ! __LINUX_SECURITY_H */
+#ifdef CONFIG_LOCK_DOWN_KERNEL
+extern void __init init_lockdown(void);
+#else
+static inline void __init init_lockdown(void)
+{
+}
+#endif
 
+#endif /* ! __LINUX_SECURITY_H */
diff --git a/security/Kconfig b/security/Kconfig
index e4fe2f3c2c65..c2aff0006de2 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -230,6 +230,21 @@ config STATIC_USERMODEHELPER_PATH
  If you wish for all usermode helper programs to be disabled,
  specify an empty string here (i.e. "").
 
+config LOCK_DOWN_KERNEL
+   bool "Allow the kernel to be 'locked down'"
+   help
+ Allow the kernel to be locked down. If lockdown support is enabled
+ and activated, the kernel will impose additional restrictions
+ intended to prevent uid 0 from being able to modify the running
+ kernel. This may break userland applications that rely on low-level
+ access to hardware.
+
+config LOCK_DOWN_KERNEL_FORCE
+bool "Enable kernel lockdown mode automatically"
+depends on LOCK_DOWN_KERNEL
+help
+  Enable the kernel lock down functionality automatically at boot.
+
 source "security/selinux/Kconfig"
 source "security/smack/Kconfig"
 source "security/tomoyo/Kconfig"
diff --git a/security/Makefile b/security/Makefile
index 4d2d3782ddef..507ac8c520ce 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -30,3 +30,6 @@ obj-$(CONFIG_CGROUP_DEVICE)   += device_cgroup.o
 # Object integrity file lists
 subdir-$(CONFIG_INTEGRITY) += integrity
 obj-$(CONFIG_INTEGRITY)+= integrity/
+
+# Allow the kernel to be locked down
+obj-$(CONFIG_LOCK_DOWN_KERNEL) += lock_down.o
diff --git a/security/lock_down.c b/security/lock_down.c
new file mode 100644
index ..13a8228c1034
--- /dev/null
+++ b/security/lock_down.c
@@ -0,0 +1,59 @@
+/* Lock down the kernel
+ *
+ * Copyright (C) 2016 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowe...@redhat.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public Licence
+ * as published by the Free Software Foundation; either version
+ * 2 of the Licence, or (at your option) any later version.
+ */
+
+#include 
+#include 
+
+static __ro_after_init bool kernel_locked_down;
+
+/*
+ * Put the kernel into lock-down mode.
+ */
+static void __init lock_kernel_down(const char *where)
+{
+   if (!kernel_locked_down) {
+   kernel_locked_down = true;
+   pr_notice("Kernel is locked down from %s; see man 
kernel_lockdown.7\n",
+ where);
+   }
+}
+
+static int __init lockdown_param(char *ignored)
+{
+   lock_kernel_down("command 

[PATCH 02/27] Add a SysRq option to lift kernel lockdown

2019-02-28 Thread Matthew Garrett
From: Kyle McMartin 

Make an option to provide a sysrq key that will lift the kernel lockdown,
thereby allowing the running kernel image to be accessed and modified.

On x86 this is triggered with SysRq+x, but this key may not be available on
all arches, so it is set by setting LOCKDOWN_LIFT_KEY in asm/setup.h.
Since this macro must be defined in an arch to be able to use this facility
for that arch, the Kconfig option is restricted to arches that support it.

Signed-off-by: Kyle McMartin 
Signed-off-by: David Howells 
cc: x...@kernel.org
---
 arch/x86/include/asm/setup.h |  2 ++
 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 +-
 security/Kconfig |  9 +++
 security/lock_down.c | 47 
 8 files changed, 85 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index ed8ec011a9fd..8daf633a5347 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -9,6 +9,8 @@
 #include 
 #include 
 
+#define LOCKDOWN_LIFT_KEY 'x'
+
 #ifdef __i386__
 
 #include 
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index 26ec603fe220..a73e92490286 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -366,6 +366,7 @@ static int uinput_create_device(struct uinput_device *udev)
dev->flush = uinput_dev_flush;
}
 
+   dev->flags |= INPUTDEV_FLAGS_SYNTHETIC;
dev->event = uinput_dev_event;
 
input_set_drvdata(udev->dev, udev);
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 1f03078ec352..0a05d336008e 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -480,6 +480,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 */
@@ -523,7 +524,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;
@@ -543,11 +544,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);
@@ -579,7 +584,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(struct timer_list *t)
 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(>keyreset_timer,
@@ -812,8 +817,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;
}
@@ -1096,7 +1103,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);

[PATCH 02/27] Add a SysRq option to lift kernel lockdown

2019-02-28 Thread Matthew Garrett
From: Kyle McMartin 

Make an option to provide a sysrq key that will lift the kernel lockdown,
thereby allowing the running kernel image to be accessed and modified.

On x86 this is triggered with SysRq+x, but this key may not be available on
all arches, so it is set by setting LOCKDOWN_LIFT_KEY in asm/setup.h.
Since this macro must be defined in an arch to be able to use this facility
for that arch, the Kconfig option is restricted to arches that support it.

Signed-off-by: Kyle McMartin 
Signed-off-by: David Howells 
cc: x...@kernel.org
---
 arch/x86/include/asm/setup.h |  2 ++
 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 +-
 security/Kconfig |  9 +++
 security/lock_down.c | 47 
 8 files changed, 85 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index ed8ec011a9fd..8daf633a5347 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -9,6 +9,8 @@
 #include 
 #include 
 
+#define LOCKDOWN_LIFT_KEY 'x'
+
 #ifdef __i386__
 
 #include 
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index 26ec603fe220..a73e92490286 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -366,6 +366,7 @@ static int uinput_create_device(struct uinput_device *udev)
dev->flush = uinput_dev_flush;
}
 
+   dev->flags |= INPUTDEV_FLAGS_SYNTHETIC;
dev->event = uinput_dev_event;
 
input_set_drvdata(udev->dev, udev);
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 1f03078ec352..0a05d336008e 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -480,6 +480,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 */
@@ -523,7 +524,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;
@@ -543,11 +544,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);
@@ -579,7 +584,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(struct timer_list *t)
 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(>keyreset_timer,
@@ -812,8 +817,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;
}
@@ -1096,7 +1103,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);

[PATCH 01/27] Add the ability to lock down access to the running kernel image

2019-02-28 Thread Matthew Garrett
From: David Howells 

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 registers and disallowing hibernation.

Signed-off-by: David Howells 
Acked-by: James Morris 
---
 include/linux/kernel.h   | 17 
 include/linux/security.h |  9 +-
 security/Kconfig | 15 ++
 security/Makefile|  3 ++
 security/lock_down.c | 59 
 5 files changed, 102 insertions(+), 1 deletion(-)
 create mode 100644 security/lock_down.c

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 8f0e68e250a7..833bf32ce4e6 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -340,6 +340,23 @@ static inline void refcount_error_report(struct pt_regs 
*regs, const char *err)
 { }
 #endif
 
+#ifdef CONFIG_LOCK_DOWN_KERNEL
+extern bool __kernel_is_locked_down(const char *what, bool first);
+#else
+static inline bool __kernel_is_locked_down(const char *what, bool first)
+{
+   return false;
+}
+#endif
+
+#define kernel_is_locked_down(what)\
+   ({  \
+   static bool message_given;  \
+   bool locked_down = __kernel_is_locked_down(what, 
!message_given); \
+   message_given = true;   \
+   locked_down;\
+   })
+
 /* Internal, do not use. */
 int __must_check _kstrtoul(const char *s, unsigned int base, unsigned long 
*res);
 int __must_check _kstrtol(const char *s, unsigned int base, long *res);
diff --git a/include/linux/security.h b/include/linux/security.h
index dbfb5a66babb..35f0be540e0b 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -1793,5 +1793,12 @@ static inline void security_bpf_prog_free(struct 
bpf_prog_aux *aux)
 #endif /* CONFIG_SECURITY */
 #endif /* CONFIG_BPF_SYSCALL */
 
-#endif /* ! __LINUX_SECURITY_H */
+#ifdef CONFIG_LOCK_DOWN_KERNEL
+extern void __init init_lockdown(void);
+#else
+static inline void __init init_lockdown(void)
+{
+}
+#endif
 
+#endif /* ! __LINUX_SECURITY_H */
diff --git a/security/Kconfig b/security/Kconfig
index e4fe2f3c2c65..c2aff0006de2 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -230,6 +230,21 @@ config STATIC_USERMODEHELPER_PATH
  If you wish for all usermode helper programs to be disabled,
  specify an empty string here (i.e. "").
 
+config LOCK_DOWN_KERNEL
+   bool "Allow the kernel to be 'locked down'"
+   help
+ Allow the kernel to be locked down. If lockdown support is enabled
+ and activated, the kernel will impose additional restrictions
+ intended to prevent uid 0 from being able to modify the running
+ kernel. This may break userland applications that rely on low-level
+ access to hardware.
+
+config LOCK_DOWN_KERNEL_FORCE
+bool "Enable kernel lockdown mode automatically"
+depends on LOCK_DOWN_KERNEL
+help
+  Enable the kernel lock down functionality automatically at boot.
+
 source "security/selinux/Kconfig"
 source "security/smack/Kconfig"
 source "security/tomoyo/Kconfig"
diff --git a/security/Makefile b/security/Makefile
index 4d2d3782ddef..507ac8c520ce 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -30,3 +30,6 @@ obj-$(CONFIG_CGROUP_DEVICE)   += device_cgroup.o
 # Object integrity file lists
 subdir-$(CONFIG_INTEGRITY) += integrity
 obj-$(CONFIG_INTEGRITY)+= integrity/
+
+# Allow the kernel to be locked down
+obj-$(CONFIG_LOCK_DOWN_KERNEL) += lock_down.o
diff --git a/security/lock_down.c b/security/lock_down.c
new file mode 100644
index ..13a8228c1034
--- /dev/null
+++ b/security/lock_down.c
@@ -0,0 +1,59 @@
+/* Lock down the kernel
+ *
+ * Copyright (C) 2016 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowe...@redhat.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public Licence
+ * as published by the Free Software Foundation; either version
+ * 2 of the Licence, or (at your option) any later version.
+ */
+
+#include 
+#include 
+
+static __ro_after_init bool kernel_locked_down;
+
+/*
+ * Put the kernel into lock-down mode.
+ */
+static void __init lock_kernel_down(const char *where)
+{
+   if (!kernel_locked_down) {
+   kernel_locked_down = true;
+   pr_notice("Kernel is locked down from %s; see man 
kernel_lockdown.7\n",
+ where);
+   }
+}
+
+static int __init lockdown_param(char *ignored)
+{
+   lock_kernel_down("command 

[PULL REQUEST] Lock down patches

2019-02-28 Thread Matthew Garrett
Hi James,

David is low on cycles at the moment, so I'm taking over for this time
round. This patchset introduces an optional kernel lockdown feature,
intended to strengthen the boundary between UID 0 and the kernel. When
enabled and active (by enabling the config option and passing the
"lockdown" option on the kernel command line), various pieces of
kernel functionality are restricted. Applications that rely on
low-level access to either hardware or the kernel may cease working as
a result - therefore this should not be enabled without appropriate
evaluation beforehand.

The majority of mainstream distributions have been carrying variants
of this patchset for many years now, so there's value in providing a
unified upstream implementation to reduce the delta. This PR probably
doesn't meet every distribution requirement, but gets us much closer
to not requiring external patches.

This PR is mostly the same as the previous attempt, but with the
following changes:

1) The integration between EFI secure boot and the lockdown state has
been removed
2) A new CONFIG_KERNEL_LOCK_DOWN_FORCE kconfig option has been added,
which will always enable lockdown regardless of the kernel command
line
3) The integration with IMA has been dropped for now. Requiring the
use of the IMA secure boot policy when lockdown is enabled isn't
practical for most distributions at the moment, as there's still not a
great deal of infrastructure for shipping packages with appropriate
IMA signatures, and it makes it complicated for end users to manage
custom IMA policies.

The following changes since commit a3b22b9f11d9fbc48b0291ea92259a5a810e9438:

  Linux 5.0-rc7 (2019-02-17 18:46:40 -0800)

are available in the Git repository at:

  https://github.com/mjg59/linux lock_down

for you to fetch changes up to 43e004ecae91bf9159b8e91cd1d613e58b8f63f8:

  lockdown: Print current->comm in restriction messages (2019-02-28
11:19:23 -0800)


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

David Howells (12):
  Add the ability to lock down access to the running kernel image
  Enforce module signatures if the kernel is locked down
  Prohibit PCMCIA CIS storage when the kernel is locked down
  Lock down TIOCSSERIAL
  Lock down module params that specify hardware parameters (eg. ioport)
  x86/mmiotrace: Lock down the testmmiotrace module
  Lock down /proc/kcore
  Lock down kprobes
  bpf: Restrict kernel image access functions when the kernel is locked down
  Lock down perf
  debugfs: Restrict debugfs when the kernel is locked down
  lockdown: Print current->comm in restriction messages

Jiri Bohac (2):
  kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE
  kexec_file: Restrict at runtime if the kernel is locked down

Josh Boyer (2):
  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 lift kernel lockdown

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 (7):
  Restrict /dev/{mem,kmem,port} when the kernel is locked down
  kexec_load: 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/msr: Restrict MSR access when the kernel is locked down
  ACPI: Limit access to custom_method when the kernel is locked down

 arch/x86/Kconfig   |  20 -
 arch/x86/include/asm/setup.h   |   2 ++
 arch/x86/kernel/ioport.c   |   6 --
 arch/x86/kernel/kexec-bzimage64.c  |   1 +
 arch/x86/kernel/msr.c  |  10 +
 arch/x86/mm/testmmiotrace.c|   3 +++
 crypto/asymmetric_keys/verify_pefile.c |   4 +++-
 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 |   2 ++
 drivers/input/misc/uinput.c|   1 +
 drivers/pci/pci-sysfs.c|   9 
 drivers/pci/proc.c |   9 +++-
 drivers/pci/syscall.c  |   3 ++-
 drivers/pcmcia/cistpl.c|   3 +++
 drivers/tty/serial/serial_core.c   |   6 ++
 drivers/tty/sysrq.c|  19 +++--
 fs/debugfs/file.c  |  28 
 fs/debugfs/inode.c |  30 --
 fs/proc/kcore.c|   2 ++
 include/linux/ima.h|   6

[PATCH V5 2/4] tpm: Reserve the TPM final events table

2019-02-27 Thread Matthew Garrett
From: Matthew Garrett 

UEFI systems provide a boot services protocol for obtaining the TPM
event log, but this is unusable after ExitBootServices() is called.
Unfortunately ExitBootServices() itself triggers additional TPM events
that then can't be obtained using this protocol. The platform provides a
mechanism for the OS to obtain these events by recording them to a
separate UEFI configuration table which the OS can then map.

Unfortunately this table isn't self describing in terms of providing its
length, so we need to parse the events inside it to figure out how long
it is. Since the table isn't mapped at this point, we need to extend the
length calculation function to be able to map the event as it goes
along.

Signed-off-by: Matthew Garrett 
---
 drivers/char/tpm/eventlog/tpm2.c |  2 +-
 drivers/firmware/efi/efi.c   |  2 +
 drivers/firmware/efi/tpm.c   | 51 -
 include/linux/efi.h  |  9 +++
 include/linux/tpm_eventlog.h | 94 +---
 5 files changed, 148 insertions(+), 10 deletions(-)

diff --git a/drivers/char/tpm/eventlog/tpm2.c b/drivers/char/tpm/eventlog/tpm2.c
index 1a977bdd3bd2..de1d9f7e5a92 100644
--- a/drivers/char/tpm/eventlog/tpm2.c
+++ b/drivers/char/tpm/eventlog/tpm2.c
@@ -40,7 +40,7 @@
 static size_t calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
   struct tcg_pcr_event *event_header)
 {
-   return __calc_tpm2_event_size(event, event_header);
+   return __calc_tpm2_event_size(event, event_header, false);
 }
 
 static void *tpm2_bios_measurements_start(struct seq_file *m, loff_t *pos)
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 4c46ff6f2242..bf4e9a254e23 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -53,6 +53,7 @@ struct efi __read_mostly efi = {
.mem_attr_table = EFI_INVALID_TABLE_ADDR,
.rng_seed   = EFI_INVALID_TABLE_ADDR,
.tpm_log= EFI_INVALID_TABLE_ADDR,
+   .tpm_final_log  = EFI_INVALID_TABLE_ADDR,
.mem_reserve= EFI_INVALID_TABLE_ADDR,
 };
 EXPORT_SYMBOL(efi);
@@ -485,6 +486,7 @@ static __initdata efi_config_table_type_t common_tables[] = 
{
{EFI_MEMORY_ATTRIBUTES_TABLE_GUID, "MEMATTR", _attr_table},
{LINUX_EFI_RANDOM_SEED_TABLE_GUID, "RNG", _seed},
{LINUX_EFI_TPM_EVENT_LOG_GUID, "TPMEventLog", _log},
+   {LINUX_EFI_TPM_FINAL_LOG_GUID, "TPMFinalLog", _final_log},
{LINUX_EFI_MEMRESERVE_TABLE_GUID, "MEMRESERVE", _reserve},
{NULL_GUID, NULL, NULL},
 };
diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware/efi/tpm.c
index 0cbeb3d46b18..2ccaa6661aaf 100644
--- a/drivers/firmware/efi/tpm.c
+++ b/drivers/firmware/efi/tpm.c
@@ -10,24 +10,50 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
+int efi_tpm_final_log_size;
+EXPORT_SYMBOL(efi_tpm_final_log_size);
+
+static int tpm2_calc_event_log_size(void *data, int count, void *size_info)
+{
+   struct tcg_pcr_event2_head *header;
+   int event_size, size = 0;
+
+   while (count > 0) {
+   header = data + size;
+   event_size = __calc_tpm2_event_size(header, size_info, true);
+   if (event_size == 0)
+   return -1;
+   size += event_size;
+   }
+
+   return size;
+}
+
 /*
  * Reserve the memory associated with the TPM Event Log configuration table.
  */
 int __init efi_tpm_eventlog_init(void)
 {
struct linux_efi_tpm_eventlog *log_tbl;
+   struct efi_tcg2_final_events_table *final_tbl;
unsigned int tbl_size;
 
-   if (efi.tpm_log == EFI_INVALID_TABLE_ADDR)
+   if (efi.tpm_log == EFI_INVALID_TABLE_ADDR) {
+   /*
+* We can't calculate the size of the final events without the
+* first entry in the TPM log, so bail here.
+*/
return 0;
+   }
 
log_tbl = early_memremap(efi.tpm_log, sizeof(*log_tbl));
if (!log_tbl) {
pr_err("Failed to map TPM Event Log table @ 0x%lx\n",
-   efi.tpm_log);
+  efi.tpm_log);
efi.tpm_log = EFI_INVALID_TABLE_ADDR;
return -ENOMEM;
}
@@ -35,6 +61,27 @@ int __init efi_tpm_eventlog_init(void)
tbl_size = sizeof(*log_tbl) + log_tbl->size;
memblock_reserve(efi.tpm_log, tbl_size);
early_memunmap(log_tbl, sizeof(*log_tbl));
+
+   if (efi.tpm_final_log == EFI_INVALID_TABLE_ADDR)
+   return 0;
+
+   final_tbl = early_memremap(efi.tpm_final_log, sizeof(*final_tbl));
+
+   if (!final_tbl) {
+   pr_err("Failed to map TPM Final Event Log table @ 0x%lx\n",
+  efi.tpm_final_log);
+   efi.tpm_final_log = EFI_INVALID_TABLE_ADDR;
+   retur

[PATCH V5 3/4] tpm: Append the final event log to the TPM event log

2019-02-27 Thread Matthew Garrett
From: Matthew Garrett 

Any events that are logged after GetEventsLog() is called are logged to
the EFI Final Events table. These events are defined as being in the
crypto agile log format, so we can just append them directly to the
existing log if it's in the same format. In theory we can also construct
old-style SHA1 log entries for devices that only return logs in that
format, but EDK2 doesn't generate the final event log in that case so
it doesn't seem worth it at the moment.

Signed-off-by: Matthew Garrett 
---
 drivers/char/tpm/eventlog/efi.c | 50 -
 1 file changed, 43 insertions(+), 7 deletions(-)

diff --git a/drivers/char/tpm/eventlog/efi.c b/drivers/char/tpm/eventlog/efi.c
index 3e673ab22cb4..9179cf6bdee9 100644
--- a/drivers/char/tpm/eventlog/efi.c
+++ b/drivers/char/tpm/eventlog/efi.c
@@ -21,10 +21,13 @@
 int tpm_read_log_efi(struct tpm_chip *chip)
 {
 
+   struct efi_tcg2_final_events_table *final_tbl = NULL;
struct linux_efi_tpm_eventlog *log_tbl;
struct tpm_bios_log *log;
u32 log_size;
u8 tpm_log_version;
+   void *tmp;
+   int ret;
 
if (!(chip->flags & TPM_CHIP_FLAG_TPM2))
return -ENODEV;
@@ -52,15 +55,48 @@ int tpm_read_log_efi(struct tpm_chip *chip)
 
/* malloc EventLog space */
log->bios_event_log = kmemdup(log_tbl->log, log_size, GFP_KERNEL);
-   if (!log->bios_event_log)
-   goto err_memunmap;
-   log->bios_event_log_end = log->bios_event_log + log_size;
+   if (!log->bios_event_log) {
+   ret = -ENOMEM;
+   goto out;
+   }
 
+   log->bios_event_log_end = log->bios_event_log + log_size;
tpm_log_version = log_tbl->version;
-   memunmap(log_tbl);
-   return tpm_log_version;
 
-err_memunmap:
+   ret = tpm_log_version;
+
+   if (efi.tpm_final_log == EFI_INVALID_TABLE_ADDR ||
+   efi_tpm_final_log_size == 0 ||
+   tpm_log_version != EFI_TCG2_EVENT_LOG_FORMAT_TCG_2)
+   goto out;
+
+   final_tbl = memremap(efi.tpm_final_log,
+sizeof(*final_tbl) + efi_tpm_final_log_size,
+MEMREMAP_WB);
+   if (!final_tbl) {
+   pr_err("Could not map UEFI TPM final log\n");
+   kfree(log->bios_event_log);
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   tmp = krealloc(log->bios_event_log,
+  log_size + efi_tpm_final_log_size,
+  GFP_KERNEL);
+   if (!tmp) {
+   kfree(log->bios_event_log);
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   log->bios_event_log = tmp;
+   memcpy((void *)log->bios_event_log + log_size,
+  final_tbl->events, efi_tpm_final_log_size);
+   log->bios_event_log_end = log->bios_event_log +
+   log_size + efi_tpm_final_log_size;
+
+out:
+   memunmap(final_tbl);
memunmap(log_tbl);
-   return -ENOMEM;
+   return ret;
 }
-- 
2.21.0.352.gf09ad66450-goog



[PATCH V5 4/4] efi: Attempt to get the TCG2 event log in the boot stub

2019-02-27 Thread Matthew Garrett
From: Matthew Garrett 

Right now we only attempt to obtain the SHA1-only event log. The
protocol also supports a crypto agile log format, which contains digests
for all algorithms in use. Attempt to obtain this first, and fall back
to obtaining the older format if the system doesn't support it. This is
lightly complicated by the event sizes being variable (as we don't know
in advance which algorithms are in use), and the interface giving us
back a pointer to the start of the final entry rather than a pointer to
the end of the log - as a result, we need to parse the final entry to
figure out its length in order to know how much data to copy up to the
OS.

Signed-off-by: Matthew Garrett 
---
 drivers/firmware/efi/libstub/tpm.c | 50 --
 1 file changed, 33 insertions(+), 17 deletions(-)

diff --git a/drivers/firmware/efi/libstub/tpm.c 
b/drivers/firmware/efi/libstub/tpm.c
index a90b0b8fc69a..523cd07c551c 100644
--- a/drivers/firmware/efi/libstub/tpm.c
+++ b/drivers/firmware/efi/libstub/tpm.c
@@ -59,7 +59,7 @@ void efi_enable_reset_attack_mitigation(efi_system_table_t 
*sys_table_arg)
 
 #endif
 
-static void efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg)
+void efi_retrieve_tpm2_eventlog(efi_system_table_t *sys_table_arg)
 {
efi_guid_t tcg2_guid = EFI_TCG2_PROTOCOL_GUID;
efi_guid_t linux_eventlog_guid = LINUX_EFI_TPM_EVENT_LOG_GUID;
@@ -69,6 +69,7 @@ static void efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t 
*sys_table_arg)
unsigned long first_entry_addr, last_entry_addr;
size_t log_size, last_entry_size;
efi_bool_t truncated;
+   int version = EFI_TCG2_EVENT_LOG_FORMAT_TCG_2;
void *tcg2_protocol = NULL;
 
status = efi_call_early(locate_protocol, _guid, NULL,
@@ -76,14 +77,20 @@ static void 
efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg)
if (status != EFI_SUCCESS)
return;
 
-   status = efi_call_proto(efi_tcg2_protocol, get_event_log, tcg2_protocol,
-   EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2,
-   _location, _last_entry, );
-   if (status != EFI_SUCCESS)
-   return;
+   status = efi_call_proto(efi_tcg2_protocol, get_event_log,
+   tcg2_protocol, version, _location,
+   _last_entry, );
+
+   if (status != EFI_SUCCESS || !log_location) {
+   version = EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2;
+   status = efi_call_proto(efi_tcg2_protocol, get_event_log,
+   tcg2_protocol, version, _location,
+   _last_entry, );
+   if (status != EFI_SUCCESS || !log_location)
+   return;
+
+   }
 
-   if (!log_location)
-   return;
first_entry_addr = (unsigned long) log_location;
 
/*
@@ -98,8 +105,23 @@ static void 
efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg)
 * We need to calculate its size to deduce the full size of
 * the logs.
 */
-   last_entry_size = sizeof(struct tcpa_event) +
-   ((struct tcpa_event *) last_entry_addr)->event_size;
+   if (version == EFI_TCG2_EVENT_LOG_FORMAT_TCG_2) {
+   /*
+* The TCG2 log format has variable length entries,
+* and the information to decode the hash algorithms
+* back into a size is contained in the first entry -
+* pass a pointer to the final entry (to calculate its
+* size) and the first entry (so we know how long each
+* digest is)
+*/
+   last_entry_size =
+   __calc_tpm2_event_size((void *)last_entry_addr,
+  (void *)log_location,
+  false);
+   } else {
+   last_entry_size = sizeof(struct tcpa_event) +
+  ((struct tcpa_event *) last_entry_addr)->event_size;
+   }
log_size = log_last_entry - log_location + last_entry_size;
}
 
@@ -116,7 +138,7 @@ static void 
efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg)
 
memset(log_tbl, 0, sizeof(*log_tbl) + log_size);
log_tbl->size = log_size;
-   log_tbl->version = EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2;
+   log_tbl->version = version;
memcpy(log_tbl->log, (void *) first_entry_addr, log_size);
 
status = efi_call_early(install_configuration_table,
@@ -128,9 +150,3 @@ static void 
efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg)
 err_free:
efi_call_early(free_pool, lo

[PATCH V5 1/4] tpm: Abstract crypto agile event size calculations

2019-02-27 Thread Matthew Garrett
From: Matthew Garrett 

We need to calculate the size of crypto agile events in multiple
locations, including in the EFI boot stub. The easiest way to do this is
to put it in a header file as an inline and leave a wrapper to ensure we
don't end up with multiple copies of it embedded in the existing code.

Signed-off-by: Matthew Garrett 
---
 drivers/char/tpm/eventlog/tpm2.c | 47 +-
 include/linux/tpm_eventlog.h | 68 
 2 files changed, 69 insertions(+), 46 deletions(-)

diff --git a/drivers/char/tpm/eventlog/tpm2.c b/drivers/char/tpm/eventlog/tpm2.c
index f824563fc28d..1a977bdd3bd2 100644
--- a/drivers/char/tpm/eventlog/tpm2.c
+++ b/drivers/char/tpm/eventlog/tpm2.c
@@ -40,52 +40,7 @@
 static size_t calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
   struct tcg_pcr_event *event_header)
 {
-   struct tcg_efi_specid_event_head *efispecid;
-   struct tcg_event_field *event_field;
-   void *marker;
-   void *marker_start;
-   u32 halg_size;
-   size_t size;
-   u16 halg;
-   int i;
-   int j;
-
-   marker = event;
-   marker_start = marker;
-   marker = marker + sizeof(event->pcr_idx) + sizeof(event->event_type)
-   + sizeof(event->count);
-
-   efispecid = (struct tcg_efi_specid_event_head *)event_header->event;
-
-   /* Check if event is malformed. */
-   if (event->count > efispecid->num_algs)
-   return 0;
-
-   for (i = 0; i < event->count; i++) {
-   halg_size = sizeof(event->digests[i].alg_id);
-   memcpy(, marker, halg_size);
-   marker = marker + halg_size;
-   for (j = 0; j < efispecid->num_algs; j++) {
-   if (halg == efispecid->digest_sizes[j].alg_id) {
-   marker +=
-   efispecid->digest_sizes[j].digest_size;
-   break;
-   }
-   }
-   /* Algorithm without known length. Such event is unparseable. */
-   if (j == efispecid->num_algs)
-   return 0;
-   }
-
-   event_field = (struct tcg_event_field *)marker;
-   marker = marker + sizeof(event_field->event_size)
-   + event_field->event_size;
-   size = marker - marker_start;
-
-   if ((event->event_type == 0) && (event_field->event_size == 0))
-   return 0;
-
-   return size;
+   return __calc_tpm2_event_size(event, event_header);
 }
 
 static void *tpm2_bios_measurements_start(struct seq_file *m, loff_t *pos)
diff --git a/include/linux/tpm_eventlog.h b/include/linux/tpm_eventlog.h
index 81519f163211..6a86144e13f1 100644
--- a/include/linux/tpm_eventlog.h
+++ b/include/linux/tpm_eventlog.h
@@ -112,4 +112,72 @@ struct tcg_pcr_event2_head {
struct tpm_digest digests[];
 } __packed;
 
+/**
+ * __calc_tpm2_event_size - calculate the size of a TPM2 event log entry
+ * @event:Pointer to the event whose size should be calculated
+ * @event_header: Pointer to the initial event containing the digest lengths
+ *
+ * The TPM2 event log format can contain multiple digests corresponding to
+ * separate PCR banks, and also contains a variable length of the data that
+ * was measured. This requires knowledge of how long each digest type is,
+ * and this information is contained within the first event in the log.
+ *
+ * We calculate the length by examining the number of events, and then looking
+ * at each event in turn to determine how much space is used for events in
+ * total. Once we've done this we know the offset of the data length field,
+ * and can calculate the total size of the event.
+ *
+ * Return: size of the event on success, <0 on failure
+ */
+
+static inline int __calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
+struct tcg_pcr_event *event_header)
+{
+   struct tcg_efi_specid_event_head *efispecid;
+   struct tcg_event_field *event_field;
+   void *marker;
+   void *marker_start;
+   u32 halg_size;
+   size_t size;
+   u16 halg;
+   int i;
+   int j;
+
+   marker = event;
+   marker_start = marker;
+   marker = marker + sizeof(event->pcr_idx) + sizeof(event->event_type)
+   + sizeof(event->count);
+
+   efispecid = (struct tcg_efi_specid_event_head *)event_header->event;
+
+   /* Check if event is malformed. */
+   if (event->count > efispecid->num_algs)
+   return 0;
+
+   for (i = 0; i < event->count; i++) {
+   halg_size = sizeof(event->digests[i].alg_id);
+   memcpy(, marker, halg_size);
+   marker = marker + halg_size;
+   for (j = 0; j < efispecid->num_algs; j++) {
+  

Add support for TCG2 log format on UEFI systems

2019-02-27 Thread Matthew Garrett
Identical to V4, but based on tpmdd-next




Re: [PATCH V4 2/4] tpm: Reserve the TPM final events table

2019-02-27 Thread Matthew Garrett
On Wed, Feb 27, 2019 at 6:03 AM Jarkko Sakkinen
 wrote:
> My guess is that your patches are based a later 5.0-rcX. Unfortunately I
> cannot update my master at this point because my 5.1 PR was taken to
> security tree and rebasing would change the commit IDs of 5.1 content
> because security/next-general does not yet contain those patches.

Bother. I'll rebase against your tree.


[PATCH V4 3/4] tpm: Append the final event log to the TPM event log

2019-02-22 Thread Matthew Garrett
From: Matthew Garrett 

Any events that are logged after GetEventsLog() is called are logged to
the EFI Final Events table. These events are defined as being in the
crypto agile log format, so we can just append them directly to the
existing log if it's in the same format. In theory we can also construct
old-style SHA1 log entries for devices that only return logs in that
format, but EDK2 doesn't generate the final event log in that case so
it doesn't seem worth it at the moment.

Signed-off-by: Matthew Garrett 
---
 drivers/char/tpm/eventlog/efi.c | 50 -
 1 file changed, 43 insertions(+), 7 deletions(-)

diff --git a/drivers/char/tpm/eventlog/efi.c b/drivers/char/tpm/eventlog/efi.c
index 3e673ab22cb4..9179cf6bdee9 100644
--- a/drivers/char/tpm/eventlog/efi.c
+++ b/drivers/char/tpm/eventlog/efi.c
@@ -21,10 +21,13 @@
 int tpm_read_log_efi(struct tpm_chip *chip)
 {
 
+   struct efi_tcg2_final_events_table *final_tbl = NULL;
struct linux_efi_tpm_eventlog *log_tbl;
struct tpm_bios_log *log;
u32 log_size;
u8 tpm_log_version;
+   void *tmp;
+   int ret;
 
if (!(chip->flags & TPM_CHIP_FLAG_TPM2))
return -ENODEV;
@@ -52,15 +55,48 @@ int tpm_read_log_efi(struct tpm_chip *chip)
 
/* malloc EventLog space */
log->bios_event_log = kmemdup(log_tbl->log, log_size, GFP_KERNEL);
-   if (!log->bios_event_log)
-   goto err_memunmap;
-   log->bios_event_log_end = log->bios_event_log + log_size;
+   if (!log->bios_event_log) {
+   ret = -ENOMEM;
+   goto out;
+   }
 
+   log->bios_event_log_end = log->bios_event_log + log_size;
tpm_log_version = log_tbl->version;
-   memunmap(log_tbl);
-   return tpm_log_version;
 
-err_memunmap:
+   ret = tpm_log_version;
+
+   if (efi.tpm_final_log == EFI_INVALID_TABLE_ADDR ||
+   efi_tpm_final_log_size == 0 ||
+   tpm_log_version != EFI_TCG2_EVENT_LOG_FORMAT_TCG_2)
+   goto out;
+
+   final_tbl = memremap(efi.tpm_final_log,
+sizeof(*final_tbl) + efi_tpm_final_log_size,
+MEMREMAP_WB);
+   if (!final_tbl) {
+   pr_err("Could not map UEFI TPM final log\n");
+   kfree(log->bios_event_log);
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   tmp = krealloc(log->bios_event_log,
+  log_size + efi_tpm_final_log_size,
+  GFP_KERNEL);
+   if (!tmp) {
+   kfree(log->bios_event_log);
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   log->bios_event_log = tmp;
+   memcpy((void *)log->bios_event_log + log_size,
+  final_tbl->events, efi_tpm_final_log_size);
+   log->bios_event_log_end = log->bios_event_log +
+   log_size + efi_tpm_final_log_size;
+
+out:
+   memunmap(final_tbl);
memunmap(log_tbl);
-   return -ENOMEM;
+   return ret;
 }
-- 
2.21.0.rc0.258.g878e2cd30e-goog



[PATCH V4 4/4] efi: Attempt to get the TCG2 event log in the boot stub

2019-02-22 Thread Matthew Garrett
From: Matthew Garrett 

Right now we only attempt to obtain the SHA1-only event log. The
protocol also supports a crypto agile log format, which contains digests
for all algorithms in use. Attempt to obtain this first, and fall back
to obtaining the older format if the system doesn't support it. This is
lightly complicated by the event sizes being variable (as we don't know
in advance which algorithms are in use), and the interface giving us
back a pointer to the start of the final entry rather than a pointer to
the end of the log - as a result, we need to parse the final entry to
figure out its length in order to know how much data to copy up to the
OS.

Signed-off-by: Matthew Garrett 
---
 drivers/firmware/efi/libstub/tpm.c | 50 --
 1 file changed, 33 insertions(+), 17 deletions(-)

diff --git a/drivers/firmware/efi/libstub/tpm.c 
b/drivers/firmware/efi/libstub/tpm.c
index a90b0b8fc69a..523cd07c551c 100644
--- a/drivers/firmware/efi/libstub/tpm.c
+++ b/drivers/firmware/efi/libstub/tpm.c
@@ -59,7 +59,7 @@ void efi_enable_reset_attack_mitigation(efi_system_table_t 
*sys_table_arg)
 
 #endif
 
-static void efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg)
+void efi_retrieve_tpm2_eventlog(efi_system_table_t *sys_table_arg)
 {
efi_guid_t tcg2_guid = EFI_TCG2_PROTOCOL_GUID;
efi_guid_t linux_eventlog_guid = LINUX_EFI_TPM_EVENT_LOG_GUID;
@@ -69,6 +69,7 @@ static void efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t 
*sys_table_arg)
unsigned long first_entry_addr, last_entry_addr;
size_t log_size, last_entry_size;
efi_bool_t truncated;
+   int version = EFI_TCG2_EVENT_LOG_FORMAT_TCG_2;
void *tcg2_protocol = NULL;
 
status = efi_call_early(locate_protocol, _guid, NULL,
@@ -76,14 +77,20 @@ static void 
efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg)
if (status != EFI_SUCCESS)
return;
 
-   status = efi_call_proto(efi_tcg2_protocol, get_event_log, tcg2_protocol,
-   EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2,
-   _location, _last_entry, );
-   if (status != EFI_SUCCESS)
-   return;
+   status = efi_call_proto(efi_tcg2_protocol, get_event_log,
+   tcg2_protocol, version, _location,
+   _last_entry, );
+
+   if (status != EFI_SUCCESS || !log_location) {
+   version = EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2;
+   status = efi_call_proto(efi_tcg2_protocol, get_event_log,
+   tcg2_protocol, version, _location,
+   _last_entry, );
+   if (status != EFI_SUCCESS || !log_location)
+   return;
+
+   }
 
-   if (!log_location)
-   return;
first_entry_addr = (unsigned long) log_location;
 
/*
@@ -98,8 +105,23 @@ static void 
efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg)
 * We need to calculate its size to deduce the full size of
 * the logs.
 */
-   last_entry_size = sizeof(struct tcpa_event) +
-   ((struct tcpa_event *) last_entry_addr)->event_size;
+   if (version == EFI_TCG2_EVENT_LOG_FORMAT_TCG_2) {
+   /*
+* The TCG2 log format has variable length entries,
+* and the information to decode the hash algorithms
+* back into a size is contained in the first entry -
+* pass a pointer to the final entry (to calculate its
+* size) and the first entry (so we know how long each
+* digest is)
+*/
+   last_entry_size =
+   __calc_tpm2_event_size((void *)last_entry_addr,
+  (void *)log_location,
+  false);
+   } else {
+   last_entry_size = sizeof(struct tcpa_event) +
+  ((struct tcpa_event *) last_entry_addr)->event_size;
+   }
log_size = log_last_entry - log_location + last_entry_size;
}
 
@@ -116,7 +138,7 @@ static void 
efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg)
 
memset(log_tbl, 0, sizeof(*log_tbl) + log_size);
log_tbl->size = log_size;
-   log_tbl->version = EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2;
+   log_tbl->version = version;
memcpy(log_tbl->log, (void *) first_entry_addr, log_size);
 
status = efi_call_early(install_configuration_table,
@@ -128,9 +150,3 @@ static void 
efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg)
 err_free:
efi_call_early(free_pool, lo

[PATCH V4 1/4] tpm: Abstract crypto agile event size calculations

2019-02-22 Thread Matthew Garrett
From: Matthew Garrett 

We need to calculate the size of crypto agile events in multiple
locations, including in the EFI boot stub. The easiest way to do this is
to put it in a header file as an inline and leave a wrapper to ensure we
don't end up with multiple copies of it embedded in the existing code.

Signed-off-by: Matthew Garrett 
---
 drivers/char/tpm/eventlog/tpm2.c | 47 +-
 include/linux/tpm_eventlog.h | 68 
 2 files changed, 69 insertions(+), 46 deletions(-)

diff --git a/drivers/char/tpm/eventlog/tpm2.c b/drivers/char/tpm/eventlog/tpm2.c
index d8b77133a83a..dc12e1cbd03a 100644
--- a/drivers/char/tpm/eventlog/tpm2.c
+++ b/drivers/char/tpm/eventlog/tpm2.c
@@ -40,52 +40,7 @@
 static int calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
struct tcg_pcr_event *event_header)
 {
-   struct tcg_efi_specid_event_head *efispecid;
-   struct tcg_event_field *event_field;
-   void *marker;
-   void *marker_start;
-   u32 halg_size;
-   size_t size;
-   u16 halg;
-   int i;
-   int j;
-
-   marker = event;
-   marker_start = marker;
-   marker = marker + sizeof(event->pcr_idx) + sizeof(event->event_type)
-   + sizeof(event->count);
-
-   efispecid = (struct tcg_efi_specid_event_head *)event_header->event;
-
-   /* Check if event is malformed. */
-   if (event->count > efispecid->num_algs)
-   return 0;
-
-   for (i = 0; i < event->count; i++) {
-   halg_size = sizeof(event->digests[i].alg_id);
-   memcpy(, marker, halg_size);
-   marker = marker + halg_size;
-   for (j = 0; j < efispecid->num_algs; j++) {
-   if (halg == efispecid->digest_sizes[j].alg_id) {
-   marker +=
-   efispecid->digest_sizes[j].digest_size;
-   break;
-   }
-   }
-   /* Algorithm without known length. Such event is unparseable. */
-   if (j == efispecid->num_algs)
-   return 0;
-   }
-
-   event_field = (struct tcg_event_field *)marker;
-   marker = marker + sizeof(event_field->event_size)
-   + event_field->event_size;
-   size = marker - marker_start;
-
-   if ((event->event_type == 0) && (event_field->event_size == 0))
-   return 0;
-
-   return size;
+   return __calc_tpm2_event_size(event, event_header);
 }
 
 static void *tpm2_bios_measurements_start(struct seq_file *m, loff_t *pos)
diff --git a/include/linux/tpm_eventlog.h b/include/linux/tpm_eventlog.h
index f47342361e87..09c19d506b69 100644
--- a/include/linux/tpm_eventlog.h
+++ b/include/linux/tpm_eventlog.h
@@ -117,4 +117,72 @@ struct tcg_pcr_event2_head {
struct tpm2_digest digests[];
 } __packed;
 
+/**
+ * __calc_tpm2_event_size - calculate the size of a TPM2 event log entry
+ * @event:Pointer to the event whose size should be calculated
+ * @event_header: Pointer to the initial event containing the digest lengths
+ *
+ * The TPM2 event log format can contain multiple digests corresponding to
+ * separate PCR banks, and also contains a variable length of the data that
+ * was measured. This requires knowledge of how long each digest type is,
+ * and this information is contained within the first event in the log.
+ *
+ * We calculate the length by examining the number of events, and then looking
+ * at each event in turn to determine how much space is used for events in
+ * total. Once we've done this we know the offset of the data length field,
+ * and can calculate the total size of the event.
+ *
+ * Return: size of the event on success, <0 on failure
+ */
+
+static inline int __calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
+struct tcg_pcr_event *event_header)
+{
+   struct tcg_efi_specid_event_head *efispecid;
+   struct tcg_event_field *event_field;
+   void *marker;
+   void *marker_start;
+   u32 halg_size;
+   size_t size;
+   u16 halg;
+   int i;
+   int j;
+
+   marker = event;
+   marker_start = marker;
+   marker = marker + sizeof(event->pcr_idx) + sizeof(event->event_type)
+   + sizeof(event->count);
+
+   efispecid = (struct tcg_efi_specid_event_head *)event_header->event;
+
+   /* Check if event is malformed. */
+   if (event->count > efispecid->num_algs)
+   return 0;
+
+   for (i = 0; i < event->count; i++) {
+   halg_size = sizeof(event->digests[i].alg_id);
+   memcpy(, marker, halg_size);
+   marker = marker + halg_size;
+   for (j = 0; j < efispecid->num_algs; j++) {
+  

[PATCH V4 0/4] Add support for TCG2 event logs on EFI systems

2019-02-22 Thread Matthew Garrett
This patchset adds support for obtaining the TCG2 format event log on
EFI systems, along with support for copying up the final event log to
capture events that occur after the primary log is obtained. V4 is
identical to previous versions, except for tpm_read_log_efi() in patch 3
being reworked to reduce nesting.




[PATCH V4 2/4] tpm: Reserve the TPM final events table

2019-02-22 Thread Matthew Garrett
From: Matthew Garrett 

UEFI systems provide a boot services protocol for obtaining the TPM
event log, but this is unusable after ExitBootServices() is called.
Unfortunately ExitBootServices() itself triggers additional TPM events
that then can't be obtained using this protocol. The platform provides a
mechanism for the OS to obtain these events by recording them to a
separate UEFI configuration table which the OS can then map.

Unfortunately this table isn't self describing in terms of providing its
length, so we need to parse the events inside it to figure out how long
it is. Since the table isn't mapped at this point, we need to extend the
length calculation function to be able to map the event as it goes
along.

Signed-off-by: Matthew Garrett 
---
 drivers/char/tpm/eventlog/tpm2.c |  2 +-
 drivers/firmware/efi/efi.c   |  2 +
 drivers/firmware/efi/tpm.c   | 51 -
 include/linux/efi.h  |  9 +++
 include/linux/tpm_eventlog.h | 94 +---
 5 files changed, 148 insertions(+), 10 deletions(-)

diff --git a/drivers/char/tpm/eventlog/tpm2.c b/drivers/char/tpm/eventlog/tpm2.c
index dc12e1cbd03a..2cfdf1db4363 100644
--- a/drivers/char/tpm/eventlog/tpm2.c
+++ b/drivers/char/tpm/eventlog/tpm2.c
@@ -40,7 +40,7 @@
 static int calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
struct tcg_pcr_event *event_header)
 {
-   return __calc_tpm2_event_size(event, event_header);
+   return __calc_tpm2_event_size(event, event_header, false);
 }
 
 static void *tpm2_bios_measurements_start(struct seq_file *m, loff_t *pos)
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 55b77c576c42..6b11c41e0575 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -53,6 +53,7 @@ struct efi __read_mostly efi = {
.mem_attr_table = EFI_INVALID_TABLE_ADDR,
.rng_seed   = EFI_INVALID_TABLE_ADDR,
.tpm_log= EFI_INVALID_TABLE_ADDR,
+   .tpm_final_log  = EFI_INVALID_TABLE_ADDR,
.mem_reserve= EFI_INVALID_TABLE_ADDR,
 };
 EXPORT_SYMBOL(efi);
@@ -485,6 +486,7 @@ static __initdata efi_config_table_type_t common_tables[] = 
{
{EFI_MEMORY_ATTRIBUTES_TABLE_GUID, "MEMATTR", _attr_table},
{LINUX_EFI_RANDOM_SEED_TABLE_GUID, "RNG", _seed},
{LINUX_EFI_TPM_EVENT_LOG_GUID, "TPMEventLog", _log},
+   {LINUX_EFI_TPM_FINAL_LOG_GUID, "TPMFinalLog", _final_log},
{LINUX_EFI_MEMRESERVE_TABLE_GUID, "MEMRESERVE", _reserve},
{NULL_GUID, NULL, NULL},
 };
diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware/efi/tpm.c
index 0cbeb3d46b18..2ccaa6661aaf 100644
--- a/drivers/firmware/efi/tpm.c
+++ b/drivers/firmware/efi/tpm.c
@@ -10,24 +10,50 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
+int efi_tpm_final_log_size;
+EXPORT_SYMBOL(efi_tpm_final_log_size);
+
+static int tpm2_calc_event_log_size(void *data, int count, void *size_info)
+{
+   struct tcg_pcr_event2_head *header;
+   int event_size, size = 0;
+
+   while (count > 0) {
+   header = data + size;
+   event_size = __calc_tpm2_event_size(header, size_info, true);
+   if (event_size == 0)
+   return -1;
+   size += event_size;
+   }
+
+   return size;
+}
+
 /*
  * Reserve the memory associated with the TPM Event Log configuration table.
  */
 int __init efi_tpm_eventlog_init(void)
 {
struct linux_efi_tpm_eventlog *log_tbl;
+   struct efi_tcg2_final_events_table *final_tbl;
unsigned int tbl_size;
 
-   if (efi.tpm_log == EFI_INVALID_TABLE_ADDR)
+   if (efi.tpm_log == EFI_INVALID_TABLE_ADDR) {
+   /*
+* We can't calculate the size of the final events without the
+* first entry in the TPM log, so bail here.
+*/
return 0;
+   }
 
log_tbl = early_memremap(efi.tpm_log, sizeof(*log_tbl));
if (!log_tbl) {
pr_err("Failed to map TPM Event Log table @ 0x%lx\n",
-   efi.tpm_log);
+  efi.tpm_log);
efi.tpm_log = EFI_INVALID_TABLE_ADDR;
return -ENOMEM;
}
@@ -35,6 +61,27 @@ int __init efi_tpm_eventlog_init(void)
tbl_size = sizeof(*log_tbl) + log_tbl->size;
memblock_reserve(efi.tpm_log, tbl_size);
early_memunmap(log_tbl, sizeof(*log_tbl));
+
+   if (efi.tpm_final_log == EFI_INVALID_TABLE_ADDR)
+   return 0;
+
+   final_tbl = early_memremap(efi.tpm_final_log, sizeof(*final_tbl));
+
+   if (!final_tbl) {
+   pr_err("Failed to map TPM Final Event Log table @ 0x%lx\n",
+  efi.tpm_final_log);
+   efi.tpm_final_log = EFI_INVALID_TABLE_ADDR;
+   return -ENOME

[PATCH 2/2] thermal/int340x_thermal: fix mode setting

2018-10-10 Thread Matthew Garrett
int3400 only pushes the UUID into the firmware when the mode is flipped
to "enable". The current code only exposes the mode flag if the firmware
supports the PASSIVE_1 UUID, which not all machines do. Remove the
restriction.

Signed-off-by: Matthew Garrett 
Cc: Zhang Rui 
---
 drivers/thermal/int340x_thermal/int3400_thermal.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/thermal/int340x_thermal/int3400_thermal.c 
b/drivers/thermal/int340x_thermal/int3400_thermal.c
index 51c9097eaf7a..e9d58de8b5da 100644
--- a/drivers/thermal/int340x_thermal/int3400_thermal.c
+++ b/drivers/thermal/int340x_thermal/int3400_thermal.c
@@ -316,10 +316,9 @@ static int int3400_thermal_probe(struct platform_device 
*pdev)
 
platform_set_drvdata(pdev, priv);
 
-   if (priv->uuid_bitmap & 1 << INT3400_THERMAL_PASSIVE_1) {
-   int3400_thermal_ops.get_mode = int3400_thermal_get_mode;
-   int3400_thermal_ops.set_mode = int3400_thermal_set_mode;
-   }
+   int3400_thermal_ops.get_mode = int3400_thermal_get_mode;
+   int3400_thermal_ops.set_mode = int3400_thermal_set_mode;
+
priv->thermal = thermal_zone_device_register("INT3400 Thermal", 0, 0,
priv, _thermal_ops,
_thermal_params, 0, 0);
-- 
2.19.0.605.g01d371f741-goog



Expose all known Intel DPTF policies

2018-10-10 Thread Matthew Garrett
Intel's Dynamic Platform and Thermal Framework is a combination
firmware/OS framework for allowing userland to implement more complex
thermal policies in conjunction with the platform firmware. The rough
gist is that the firmware exposes a set of information describing the
relationships between various heat generating and heat removing
components in the system, the OS makes a reasonable decision about what
sort of policy will work best given the constraints the system is
currently operating under and passes that decision back to the firmware,
and the firmware does some magic (potentially including reprogramming
various CPU MSRs) to match the OS policy. Depending on the policy, the
OS may then be responsible for ensuring that the system stays within the
appropriate thermal envelope.

Linux already has a driver that exposes the firmware interface for
setting the policy, but it's somewhat broken - it only exposes a very
small subset of the defined policies, and most new systems don't
intersect with the exposed ones (strangely, support for some policies
was actively removed in 31908f45a583e8f21db37f402b6e8d5739945afd). It
also doesn't actually /work/ on any new systems, since the PASSIVE_1
policy seems to have been replaced by the PASSIVE_2 policy and therefore
it's impossible to actually trigger a new UUID write.

The consequence of this right now is that various new systems (such as
most current Thinkpads) default to a safe policy that throttles the CPU
at a low temperature, dramatically reducing system performance. Since
Linux provides no mechanism to set any of the other policies the
platform supports, users are stuck. This patchset adds all the UUIDs
I've been able to find from scraping various ACPI tables, and fixes the
mode setting in order to make it possible to actually set the new modes.
It should be noted that this is nowhere near an actual solution - doing
this properly requires appropriate userspace management tooling, and
Intel haven't documented most of the ACPI information required to make
it possible to write such tooling. However, this is a first step in
making it possible to do that work.




[PATCH 2/2] thermal/int340x_thermal: fix mode setting

2018-10-10 Thread Matthew Garrett
int3400 only pushes the UUID into the firmware when the mode is flipped
to "enable". The current code only exposes the mode flag if the firmware
supports the PASSIVE_1 UUID, which not all machines do. Remove the
restriction.

Signed-off-by: Matthew Garrett 
Cc: Zhang Rui 
---
 drivers/thermal/int340x_thermal/int3400_thermal.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/thermal/int340x_thermal/int3400_thermal.c 
b/drivers/thermal/int340x_thermal/int3400_thermal.c
index 51c9097eaf7a..e9d58de8b5da 100644
--- a/drivers/thermal/int340x_thermal/int3400_thermal.c
+++ b/drivers/thermal/int340x_thermal/int3400_thermal.c
@@ -316,10 +316,9 @@ static int int3400_thermal_probe(struct platform_device 
*pdev)
 
platform_set_drvdata(pdev, priv);
 
-   if (priv->uuid_bitmap & 1 << INT3400_THERMAL_PASSIVE_1) {
-   int3400_thermal_ops.get_mode = int3400_thermal_get_mode;
-   int3400_thermal_ops.set_mode = int3400_thermal_set_mode;
-   }
+   int3400_thermal_ops.get_mode = int3400_thermal_get_mode;
+   int3400_thermal_ops.set_mode = int3400_thermal_set_mode;
+
priv->thermal = thermal_zone_device_register("INT3400 Thermal", 0, 0,
priv, _thermal_ops,
_thermal_params, 0, 0);
-- 
2.19.0.605.g01d371f741-goog



Expose all known Intel DPTF policies

2018-10-10 Thread Matthew Garrett
Intel's Dynamic Platform and Thermal Framework is a combination
firmware/OS framework for allowing userland to implement more complex
thermal policies in conjunction with the platform firmware. The rough
gist is that the firmware exposes a set of information describing the
relationships between various heat generating and heat removing
components in the system, the OS makes a reasonable decision about what
sort of policy will work best given the constraints the system is
currently operating under and passes that decision back to the firmware,
and the firmware does some magic (potentially including reprogramming
various CPU MSRs) to match the OS policy. Depending on the policy, the
OS may then be responsible for ensuring that the system stays within the
appropriate thermal envelope.

Linux already has a driver that exposes the firmware interface for
setting the policy, but it's somewhat broken - it only exposes a very
small subset of the defined policies, and most new systems don't
intersect with the exposed ones (strangely, support for some policies
was actively removed in 31908f45a583e8f21db37f402b6e8d5739945afd). It
also doesn't actually /work/ on any new systems, since the PASSIVE_1
policy seems to have been replaced by the PASSIVE_2 policy and therefore
it's impossible to actually trigger a new UUID write.

The consequence of this right now is that various new systems (such as
most current Thinkpads) default to a safe policy that throttles the CPU
at a low temperature, dramatically reducing system performance. Since
Linux provides no mechanism to set any of the other policies the
platform supports, users are stuck. This patchset adds all the UUIDs
I've been able to find from scraping various ACPI tables, and fixes the
mode setting in order to make it possible to actually set the new modes.
It should be noted that this is nowhere near an actual solution - doing
this properly requires appropriate userspace management tooling, and
Intel haven't documented most of the ACPI information required to make
it possible to write such tooling. However, this is a first step in
making it possible to do that work.




[PATCH 1/2] thermal/int340x_thermal: Add additional UUIDs

2018-10-10 Thread Matthew Garrett
Platforms support more DPTF policies than the driver currently exposes.
Add them. This effectively reverts
31908f45a583e8f21db37f402b6e8d5739945afd which removed several UUIDs
without explaining why.

Signed-off-by: Matthew Garrett 
Cc: Zhang Rui 
Cc: Nisha Aram 
---
 drivers/thermal/int340x_thermal/int3400_thermal.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/thermal/int340x_thermal/int3400_thermal.c 
b/drivers/thermal/int340x_thermal/int3400_thermal.c
index e26b01c05e82..51c9097eaf7a 100644
--- a/drivers/thermal/int340x_thermal/int3400_thermal.c
+++ b/drivers/thermal/int340x_thermal/int3400_thermal.c
@@ -22,6 +22,13 @@ enum int3400_thermal_uuid {
INT3400_THERMAL_PASSIVE_1,
INT3400_THERMAL_ACTIVE,
INT3400_THERMAL_CRITICAL,
+   INT3400_THERMAL_ADAPTIVE_PERFORMANCE,
+   INT3400_THERMAL_EMERGENCY_CALL_MODE,
+   INT3400_THERMAL_PASSIVE_2,
+   INT3400_THERMAL_POWER_BOSS,
+   INT3400_THERMAL_VIRTUAL_SENSOR,
+   INT3400_THERMAL_COOLING_MODE,
+   INT3400_THERMAL_HARDWARE_DUTY_CYCLING,
INT3400_THERMAL_MAXIMUM_UUID,
 };
 
@@ -29,6 +36,13 @@ static char 
*int3400_thermal_uuids[INT3400_THERMAL_MAXIMUM_UUID] = {
"42A441D6-AE6A-462b-A84B-4A8CE79027D3",
"3A95C389-E4B8-4629-A526-C52C88626BAE",
"97C68AE7-15FA-499c-B8C9-5DA81D606E0A",
+   "63BE270F-1C11-48FD-A6F7-3AF253FF3E2D",
+   "5349962F-71E6-431D-9AE8-0A635B710AEE",
+   "9E04115A-AE87-4D1C-9500-0F3E340BFE75",
+   "F5A35014-C209-46A4-993A-EB56DE7530A1",
+   "6ED722A7-9240-48A5-B479-31EEF723D7CF",
+   "16CAF1B7-DD38-40ED-B1C1-1B8A1913D531",
+   "BE84BABF-C4D4-403D-B495-3128FD44dAC1",
 };
 
 struct int3400_thermal_priv {
-- 
2.19.0.605.g01d371f741-goog



[PATCH 1/2] thermal/int340x_thermal: Add additional UUIDs

2018-10-10 Thread Matthew Garrett
Platforms support more DPTF policies than the driver currently exposes.
Add them. This effectively reverts
31908f45a583e8f21db37f402b6e8d5739945afd which removed several UUIDs
without explaining why.

Signed-off-by: Matthew Garrett 
Cc: Zhang Rui 
Cc: Nisha Aram 
---
 drivers/thermal/int340x_thermal/int3400_thermal.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/thermal/int340x_thermal/int3400_thermal.c 
b/drivers/thermal/int340x_thermal/int3400_thermal.c
index e26b01c05e82..51c9097eaf7a 100644
--- a/drivers/thermal/int340x_thermal/int3400_thermal.c
+++ b/drivers/thermal/int340x_thermal/int3400_thermal.c
@@ -22,6 +22,13 @@ enum int3400_thermal_uuid {
INT3400_THERMAL_PASSIVE_1,
INT3400_THERMAL_ACTIVE,
INT3400_THERMAL_CRITICAL,
+   INT3400_THERMAL_ADAPTIVE_PERFORMANCE,
+   INT3400_THERMAL_EMERGENCY_CALL_MODE,
+   INT3400_THERMAL_PASSIVE_2,
+   INT3400_THERMAL_POWER_BOSS,
+   INT3400_THERMAL_VIRTUAL_SENSOR,
+   INT3400_THERMAL_COOLING_MODE,
+   INT3400_THERMAL_HARDWARE_DUTY_CYCLING,
INT3400_THERMAL_MAXIMUM_UUID,
 };
 
@@ -29,6 +36,13 @@ static char 
*int3400_thermal_uuids[INT3400_THERMAL_MAXIMUM_UUID] = {
"42A441D6-AE6A-462b-A84B-4A8CE79027D3",
"3A95C389-E4B8-4629-A526-C52C88626BAE",
"97C68AE7-15FA-499c-B8C9-5DA81D606E0A",
+   "63BE270F-1C11-48FD-A6F7-3AF253FF3E2D",
+   "5349962F-71E6-431D-9AE8-0A635B710AEE",
+   "9E04115A-AE87-4D1C-9500-0F3E340BFE75",
+   "F5A35014-C209-46A4-993A-EB56DE7530A1",
+   "6ED722A7-9240-48A5-B479-31EEF723D7CF",
+   "16CAF1B7-DD38-40ED-B1C1-1B8A1913D531",
+   "BE84BABF-C4D4-403D-B495-3128FD44dAC1",
 };
 
 struct int3400_thermal_priv {
-- 
2.19.0.605.g01d371f741-goog



Re: Bugs involving maliciously crafted file system

2018-05-30 Thread Matthew Garrett
On Wed, May 30, 2018 at 1:42 PM Dave Chinner  wrote:
> We've learnt this lesson the hard way over and over again: don't
> parse untrusted input in privileged contexts. How many times do we
> have to make the same mistakes before people start to learn from
> them?

You're not wrong, but we haven't considered root to be fundamentally
trustworthy for years - there are multiple kernel features that can be
configured such that root is no longer able to do certain things (the
one-way trap for requiring module signatures is the most obvious, but
IMA in appraisal mode will also restrict root), and as a result it's
not reasonable to be worried only about users - it's also necessary to
prevent root form being able to deliberately mount a filesystem that
results in arbitrary code execution in the kernel.


Re: Bugs involving maliciously crafted file system

2018-05-30 Thread Matthew Garrett
On Wed, May 30, 2018 at 1:42 PM Dave Chinner  wrote:
> We've learnt this lesson the hard way over and over again: don't
> parse untrusted input in privileged contexts. How many times do we
> have to make the same mistakes before people start to learn from
> them?

You're not wrong, but we haven't considered root to be fundamentally
trustworthy for years - there are multiple kernel features that can be
configured such that root is no longer able to do certain things (the
one-way trap for requiring module signatures is the most obvious, but
IMA in appraisal mode will also restrict root), and as a result it's
not reasonable to be worried only about users - it's also necessary to
prevent root form being able to deliberately mount a filesystem that
results in arbitrary code execution in the kernel.


Re: [PATCH 0/3] kexec: limit kexec_load syscall

2018-05-03 Thread Matthew Garrett
On Thu, May 3, 2018 at 2:59 PM Eric W. Biederman <ebied...@xmission.com>
wrote:

> Matthew Garrett <mj...@google.com> writes:
> > kexec_load gives root arbitrary power to modify the running kernel
image,
> > including the ability to disable enforcement of module signatures.

> No.  It does absolutely nothing to the running kernel image.
> Combined with reboot(..., LINUX_REBOOT_CMD_KEXE, ...) it does allow
> booting something different.  It is argubably a little more efficient
> than writing to a file to direct the bootloader to boot something
> different and then calling reboot.  But it is not fundamentally
> different.

It absolutely does - https://mjg59.dreamwidth.org/28746.html gives an
example. The payload just needs to return.

> > Given
> > that it weakens other security mechanisms that are designed to prevent
root
> > from disabling them, it makes sense to allow the imposition of an
> > equivalent restriction.

> Say what.  You are saying a lot of words without any specifics.  Not a
> specific threat mode.  Not which security mecahnisms you are worried
> about weakening.  Not what classes of problems you are trying to defend
> against.

I have a kernel configured with module.sig_enforce enabled - root is unable
to load kernel modules that are unsigned, and since sig_enforce is
bool_enable_only, root is unable to flip that back. Any number of security
models may be implemented with that assumption. However, root still has
access to kexec_load(), and can therefore kexec into a dummy payload that
flips that byte back to 0 and permits loading unsigned module code.

There may well be other mechanisms that permit root to gain arbitrary
ability to modify kernel code. My argument is that we should treat those as
bugs, not use their existence as a justification for leaving open known
cases.


Re: [PATCH 0/3] kexec: limit kexec_load syscall

2018-05-03 Thread Matthew Garrett
On Thu, May 3, 2018 at 2:59 PM Eric W. Biederman 
wrote:

> Matthew Garrett  writes:
> > kexec_load gives root arbitrary power to modify the running kernel
image,
> > including the ability to disable enforcement of module signatures.

> No.  It does absolutely nothing to the running kernel image.
> Combined with reboot(..., LINUX_REBOOT_CMD_KEXE, ...) it does allow
> booting something different.  It is argubably a little more efficient
> than writing to a file to direct the bootloader to boot something
> different and then calling reboot.  But it is not fundamentally
> different.

It absolutely does - https://mjg59.dreamwidth.org/28746.html gives an
example. The payload just needs to return.

> > Given
> > that it weakens other security mechanisms that are designed to prevent
root
> > from disabling them, it makes sense to allow the imposition of an
> > equivalent restriction.

> Say what.  You are saying a lot of words without any specifics.  Not a
> specific threat mode.  Not which security mecahnisms you are worried
> about weakening.  Not what classes of problems you are trying to defend
> against.

I have a kernel configured with module.sig_enforce enabled - root is unable
to load kernel modules that are unsigned, and since sig_enforce is
bool_enable_only, root is unable to flip that back. Any number of security
models may be implemented with that assumption. However, root still has
access to kexec_load(), and can therefore kexec into a dummy payload that
flips that byte back to 0 and permits loading unsigned module code.

There may well be other mechanisms that permit root to gain arbitrary
ability to modify kernel code. My argument is that we should treat those as
bugs, not use their existence as a justification for leaving open known
cases.


Re: [PATCH 0/3] kexec: limit kexec_load syscall

2018-05-03 Thread Matthew Garrett
On Thu, May 3, 2018 at 1:13 PM Eric W. Biederman 
wrote:

> Mimi Zohar  writes:

> > In environments that require the kexec kernel image to be signed,
prevent
> > using the kexec_load syscall.  In order for LSMs and IMA to
differentiate
> > between kexec_load and kexec_file_load syscalls, this patch set adds a
> > call to security_kernel_read_file() in kexec_load_check().

> Having thought about it some more this justification for these changes
> does not work.  The functionality of kexec_load is already root-only.
> So in environments that require the kernel image to be signed just don't
> use kexec_load.  Possibly even compile kexec_load out to save space
> because you will never need it.  You don't need a new security hook to
> do any of that.  Userspace is a very fine mechanism for being the
> instrument of policy.

> If you don't trust userspace that needs to be spelled out very clearly.
> You need to talk about what your threat models are.

kexec_load gives root arbitrary power to modify the running kernel image,
including the ability to disable enforcement of module signatures. Given
that it weakens other security mechanisms that are designed to prevent root
from disabling them, it makes sense to allow the imposition of an
equivalent restriction.


Re: [PATCH 0/3] kexec: limit kexec_load syscall

2018-05-03 Thread Matthew Garrett
On Thu, May 3, 2018 at 1:13 PM Eric W. Biederman 
wrote:

> Mimi Zohar  writes:

> > In environments that require the kexec kernel image to be signed,
prevent
> > using the kexec_load syscall.  In order for LSMs and IMA to
differentiate
> > between kexec_load and kexec_file_load syscalls, this patch set adds a
> > call to security_kernel_read_file() in kexec_load_check().

> Having thought about it some more this justification for these changes
> does not work.  The functionality of kexec_load is already root-only.
> So in environments that require the kernel image to be signed just don't
> use kexec_load.  Possibly even compile kexec_load out to save space
> because you will never need it.  You don't need a new security hook to
> do any of that.  Userspace is a very fine mechanism for being the
> instrument of policy.

> If you don't trust userspace that needs to be spelled out very clearly.
> You need to talk about what your threat models are.

kexec_load gives root arbitrary power to modify the running kernel image,
including the ability to disable enforcement of module signatures. Given
that it weakens other security mechanisms that are designed to prevent root
from disabling them, it makes sense to allow the imposition of an
equivalent restriction.


Re: [GIT PULL] Kernel lockdown for secure boot

2018-04-05 Thread Matthew Garrett
On Thu, Apr 5, 2018 at 10:59 AM Alan Cox  wrote:
> VT-D

Once Intel provide that on all hardware and actually make it work reliably
with their graphics chipsets it's certainly a solution for the PCI DMA
problem, but right now it's still effectively undeployable for a lot of
real world cases.


Re: [GIT PULL] Kernel lockdown for secure boot

2018-04-05 Thread Matthew Garrett
On Thu, Apr 5, 2018 at 10:59 AM Alan Cox  wrote:
> VT-D

Once Intel provide that on all hardware and actually make it work reliably
with their graphics chipsets it's certainly a solution for the PCI DMA
problem, but right now it's still effectively undeployable for a lot of
real world cases.


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

2018-04-04 Thread Matthew Garrett
On Wed, Apr 4, 2018 at 4:25 PM James Morris  wrote:
> It's surely reasonable to allow an already secure-booted system to be
> debugged without needing to be rebooted.

alt-sysrq-x from a physical console will do that.


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

2018-04-04 Thread Matthew Garrett
On Wed, Apr 4, 2018 at 4:25 PM James Morris  wrote:
> It's surely reasonable to allow an already secure-booted system to be
> debugged without needing to be rebooted.

alt-sysrq-x from a physical console will do that.


Re: [GIT PULL] Kernel lockdown for secure boot

2018-04-04 Thread Matthew Garrett
On Wed, Apr 4, 2018 at 5:05 PM Peter Dolding  wrote:

> > If you don't have secure boot then an attacker with root can modify your
> > bootloader or kernel, and on next boot lockdown can be silently
disabled.

> Stop being narrow minded you don't need secure boot to protect
> bootloader or kernel the classic is only boot from read only media.

And if you use another protected path you can set the appropriate bootparam
flag or pass the appropriate kernel command line argument and gain the same
functionality.


Re: [GIT PULL] Kernel lockdown for secure boot

2018-04-04 Thread Matthew Garrett
On Wed, Apr 4, 2018 at 5:05 PM Peter Dolding  wrote:

> > If you don't have secure boot then an attacker with root can modify your
> > bootloader or kernel, and on next boot lockdown can be silently
disabled.

> Stop being narrow minded you don't need secure boot to protect
> bootloader or kernel the classic is only boot from read only media.

And if you use another protected path you can set the appropriate bootparam
flag or pass the appropriate kernel command line argument and gain the same
functionality.


Re: [GIT PULL] Kernel lockdown for secure boot

2018-04-04 Thread Matthew Garrett
On Wed, Apr 4, 2018 at 1:01 PM Thomas Gleixner  wrote:
> Now where the disagreement lies is the way how the uid/ring0 aspect is
tied
> to secure boot, which makes it impossible to be useful independent of
> Secure Boot.

It doesn't - you can pass a command line parameter that enables it, or your
bootloader can set the bootparams flag. I don't see a fundamental problem
with offering the opportunity to change it at runtime, other than that some
stuff that was previously initialised may have to be torn down. The reason
for having the UEFI boot stub *optionally* check the secure boot state
itself and make a policy decision (rather than having the signed bootloader
do so) is because the kernel can be launched directly by the firmware.


Re: [GIT PULL] Kernel lockdown for secure boot

2018-04-04 Thread Matthew Garrett
On Wed, Apr 4, 2018 at 1:01 PM Thomas Gleixner  wrote:
> Now where the disagreement lies is the way how the uid/ring0 aspect is
tied
> to secure boot, which makes it impossible to be useful independent of
> Secure Boot.

It doesn't - you can pass a command line parameter that enables it, or your
bootloader can set the bootparams flag. I don't see a fundamental problem
with offering the opportunity to change it at runtime, other than that some
stuff that was previously initialised may have to be torn down. The reason
for having the UEFI boot stub *optionally* check the secure boot state
itself and make a policy decision (rather than having the signed bootloader
do so) is because the kernel can be launched directly by the firmware.


<    1   2   3   4   5   6   7   8   9   10   >