[RFC PATCH 29/68] vfs: Convert efivarfs to use the new mount API

[David Howells]

Convert the efivarfs filesystem to the new internal mount API as the old
one will be obsoleted and removed.  This allows greater flexibility in
communication of mount parameters between userspace, the VFS and the
filesystem.

See Documentation/filesystems/mount_api.txt for more information.

Signed-off-by: David Howells 
cc: Matthew Garrett 
cc: Jeremy Kerr 
cc: Ard Biesheuvel 
cc: linux-efi@vger.kernel.org
---

 fs/efivarfs/super.c |   20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c
index 5b68e4294faa..1ea25c7a329a 100644
--- a/fs/efivarfs/super.c
+++ b/fs/efivarfs/super.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -191,7 +192,7 @@ static int efivarfs_destroy(struct efivar_entry *entry, 
void *data)
return 0;
 }
 
-static int efivarfs_fill_super(struct super_block *sb, void *data, int silent)
+static int efivarfs_fill_super(struct super_block *sb, struct fs_context *fc)
 {
struct inode *inode = NULL;
struct dentry *root;
@@ -226,10 +227,19 @@ static int efivarfs_fill_super(struct super_block *sb, 
void *data, int silent)
return err;
 }
 
-static struct dentry *efivarfs_mount(struct file_system_type *fs_type,
-   int flags, const char *dev_name, void *data)
+static int efivarfs_get_tree(struct fs_context *fc)
 {
-   return mount_single(fs_type, flags, data, efivarfs_fill_super);
+   return vfs_get_super(fc, vfs_get_single_super, efivarfs_fill_super);
+}
+
+static const struct fs_context_operations efivarfs_context_ops = {
+   .get_tree   = efivarfs_get_tree,
+};
+
+static int efivarfs_init_fs_context(struct fs_context *fc)
+{
+   fc->ops = _context_ops;
+   return 0;
 }
 
 static void efivarfs_kill_sb(struct super_block *sb)
@@ -244,7 +254,7 @@ static void efivarfs_kill_sb(struct super_block *sb)
 static struct file_system_type efivarfs_type = {
.owner   = THIS_MODULE,
.name= "efivarfs",
-   .mount   = efivarfs_mount,
+   .init_fs_context = efivarfs_init_fs_context,
.kill_sb = efivarfs_kill_sb,
 };
 

[PATCH 26/38] vfs: Convert efivarfs to fs_context

[David Howells]

Signed-off-by: David Howells 
cc: Matthew Garrett 
cc: Jeremy Kerr 
cc: Ard Biesheuvel 
cc: linux-efi@vger.kernel.org
---

 fs/efivarfs/super.c |   20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c
index 5b68e4294faa..1ea25c7a329a 100644
--- a/fs/efivarfs/super.c
+++ b/fs/efivarfs/super.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -191,7 +192,7 @@ static int efivarfs_destroy(struct efivar_entry *entry, 
void *data)
return 0;
 }
 
-static int efivarfs_fill_super(struct super_block *sb, void *data, int silent)
+static int efivarfs_fill_super(struct super_block *sb, struct fs_context *fc)
 {
struct inode *inode = NULL;
struct dentry *root;
@@ -226,10 +227,19 @@ static int efivarfs_fill_super(struct super_block *sb, 
void *data, int silent)
return err;
 }
 
-static struct dentry *efivarfs_mount(struct file_system_type *fs_type,
-   int flags, const char *dev_name, void *data)
+static int efivarfs_get_tree(struct fs_context *fc)
 {
-   return mount_single(fs_type, flags, data, efivarfs_fill_super);
+   return vfs_get_super(fc, vfs_get_single_super, efivarfs_fill_super);
+}
+
+static const struct fs_context_operations efivarfs_context_ops = {
+   .get_tree   = efivarfs_get_tree,
+};
+
+static int efivarfs_init_fs_context(struct fs_context *fc)
+{
+   fc->ops = _context_ops;
+   return 0;
 }
 
 static void efivarfs_kill_sb(struct super_block *sb)
@@ -244,7 +254,7 @@ static void efivarfs_kill_sb(struct super_block *sb)
 static struct file_system_type efivarfs_type = {
.owner   = THIS_MODULE,
.name= "efivarfs",
-   .mount   = efivarfs_mount,
+   .init_fs_context = efivarfs_init_fs_context,
.kill_sb = efivarfs_kill_sb,
 };
 

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

[David Howells]

Jann Horn  wrote:

> > Uh, no.  bpf, for example, can be used to modify kernel memory.
> 
> I'm pretty sure bpf isn't supposed to be able to modify arbitrary
> kernel memory. AFAIU if you can use BPF to write to arbitrary kernel
> memory, that's a bug; with CAP_SYS_ADMIN, you can read from userspace,
> write to userspace, and read from kernelspace, but you shouldn't be
> able to write to kernelspace.

Ah - you may be right.  I seem to have misremembered what Joey Lee wrote in
his patch description.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

Andy Lutomirski  wrote:

> Since this thread has devolved horribly, I'm going to propose a solution.
> 
> 1. Split the "lockdown" state into three levels:  (please don't
> bikeshed about the names right now.)
> 
> LOCKDOWN_NONE: normal behavior
> 
> LOCKDOWN_PROTECT_INTEGREITY: kernel tries to keep root from writing to
> kernel memory
> 
> LOCKDOWN_PROTECT_INTEGRITY_AND_SECRECY: kernel tries to keep root from
> reading or writing kernel memory.

In theory, it's good idea, but in practice it's not as easy to implement as I
think you think.

Let me list here the things that currently get restricted by lockdown:

 (1) Manipulation of devices to access the kernel image:

- Ioports & ioperm
- /dev/ports
- /dev/mem
- PCI Bar
- Some debugfs files
- pcmcia_cis
- Driver hardware parameters
  - ISA drivers
  - TIOCSSERIAL
  - SCSI EATA driver
- testmmiotrace
- firmware

 (2) Direct kernel memory modification:

- /dev/mem
- /dev/kmem
- bpf
- kprobes

 (3) Direct kernel memory reading:

- /dev/mem
- /dev/kmem
- /dev/kcore
- bpf
- kprobes
- perf

 (4) Indirect kernel access:

- Modules
- MSRs
- Suspend to disk
- ACPI (custom_method, RSDP, table override, error injection)

 (5) Kexec.

Note that /dev/mem can be used to access MMIO devices (I'm not sure about
/dev/kmem, though).  Even reads through /dev/mem can do this.  I'm not sure
whether that's sufficient to actually affect a modification, though.

Debugfs is particularly icky.  It contains at least a couple of thousand
files, a few of which provide direct access to hardware, some of which change
driver behaviour and some of which just give information.  Auditing that pile
isn't something I really want to have to do.  I'd rather just turn the whole
lot off, but got persuaded otherwise by people who have been using it to
provide mechanisms that programs rely on - hence the only allow files that
have 0444 (and even that is iffy as some of these files have side effects and
write ops anyway).

> 2. The kexec protocol gets a new flag min_lockdown_level.  A kexeced
> kernel will boot with at least that lockdown level regardless of its
> configuration.  kexec sets min_lockdown_level to the running kernels'
> lockdown_level.  Some future API could allow kexec with a higher
> min_lockdown_level.  An even fancier future API could allow a
> LOCKDOWN_PROTECT_INTEGRITY_AND_SECRECY kernel to kexec with
> min_lockdown_level == LOCKDOWN_PROTECT_INTEGRITY if there's some
> mechanism that guarantees that memory gets zeroed in the process.

Note that on x86 we already have an allocated flag for passing the secure boot
flag from kexec/bootloader to the kernel being booted, and what you're
proposing ought to be redundant.  See boot_params::secure_boot.

> 3. All the bpf and tracing stuf, etc, gets changed so it only takes
> effect when LOCKDOWN_PROTECT_INTEGRITY_AND_SECRECY is set.

Uh, no.  bpf, for example, can be used to modify kernel memory.  I think only
the following are safe from being able to talk directly to devices:

/dev/kmem (O_RDONLY only)
/dev/kcore
perf
some debugfs files

> This removes a giant annoyance on distro kernels that are likely to want to
> enable LOCKDOWN_PROTECT_INTEGRITY.

*shrug* Distros have been running with the full set for a while.  I haven't
seen many complaints.

> If you load a key into the kernel, and you want to keep that key safe, you
> can enable LOCKDOWN_PROTECT_INTEGRITY_AND_SECRECY at that time.  After all,
> if root is compromised before that, root can just remember a copu of the key
> in user memory or email it to someone.

If your key needs to be truly protected, it should never be seen unencrypted
in userspace, rather it should be decrypted in the TPM and then retained in
kernel memory only.

> ...
> 6. There's a way to *decrease* the lockdown level below the configured
> value.  (This ability itself may be gated by a config option.)
> Choices include a UEFI protected variable,

By turning secure boot off, maybe?

> an authenticated flag passed by the bootloader,

Authenticated how?  How do you stop the running system from passing this to
the bootloader next time it is run?  I guess you're thinking of a bootloader
"command" that can only be passed by someone sat at a keyboard and never read
from the config file.

> and even just some special flag in the boot handoff protocol.

We already have that with secure boot.

> It would be really quite useful for a user to be able to ask their
> bootloader to reduce the lockdown level for the purpose of a particular boot
> for debugging.

This I shall grant you - but you have to be able to prevent an attacker inside
the system from making use of it.  There's a SysRq provided to drop out of
lockdown mode - in theory only usable if you're sat at a 

Re: [GIT PULL] Kernel lockdown for secure boot

[David Howells]

Andy Lutomirski  wrote:

> > Andy Lutomirski  wrote:
> >
> >> As far as I can tell, what's really going on here is that there's a
> >> significant contingent here that wants to prevent Linux from
> >> chainloading something that isn't Linux.
> >
> > You have completely the wrong end of the stick.  No one has said that or
> > even implied that.  You are alleging dishonesty on our part.
> 
> I'm alleging that the idea that Linux seems some particular policy to
> avoid being blacklisted keeps being brought up as a justification for
> these patches.

No, you were alleging that "[we want] to prevent Linux from chainloading
something that isn't Linux.".

This is not true - at least, it's not true on my part; I cannot speak for what
other people may think privately.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[David Howells]

Theodore Y. Ts'o  wrote:

> > Lockdown mode restricts kexec to booting an authorised image (where the
> > authorisation may be by signature or by IMA).
> 
> If that's true, then Matthew's assertion that lockdown w/o secure boot
> is insecure goes away, no?

No.

Lockdown prevents the running kernel from being modified (or, at least, that's
the hope).

But it doesn't do anything to prevent the kernel being modified before
lockdown is engaged.

We are trying to use secureboot to protect the system to the point that
lockdown can take over.

David

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[David Howells]

Theodore Y. Ts'o  wrote:

> Whoa.  Why doesn't lockdown prevent kexec?  Put another away, why
> isn't this a problem for people who are fearful that Linux could be
> used as part of a Windows boot virus in a Secure UEFI context?

Lockdown mode restricts kexec to booting an authorised image (where the
authorisation may be by signature or by IMA).

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[David Howells]

Andy Lutomirski  wrote:

> As far as I can tell, what's really going on here is that there's a
> significant contingent here that wants to prevent Linux from
> chainloading something that isn't Linux.

You have completely the wrong end of the stick.  No one has said that or even
implied that.  You are alleging dishonesty on our part.

What we *have* said is that *if* we want to pass the secure boot state across
kexec, then we have to make sure that:

 (1) no one tampers with the intermediate kernel between boot and kexec
 otherwise the secure boot state is effectively invalidated, and

 (2) the image that gets kexec'ed is trusted.

Remember: you cannot know (2) if you don't have (1).

And if someone tampers with the aim of breaking, say, Windows, then someone,
e.g.  Microsoft, might blacklist the shim.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[David Howells]

Linus Torvalds  wrote:

> ...  use the kernel command line to disable things.

An attacker could then modify grub.cfg, say, and cause a reboot (or wait for
the next reboot) to disable lockdown:-/

And whilst we could also distribute a non-locked-down variant of the kernel as
an alternative, the attacker could install and boot that instead since we
can't lock package installation down very easily since it doesn't impinge
directly on the running kernel.

Unfortunately, it's hard to come up with a disablement mechanism in the kernel
that an attacker can't also make use of:-/

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[David Howells]

Linus Torvalds  wrote:

> Be honest now. It wasn't generally users who clamored for it.
> ...
> If the user actually wanted it, and is asking for it, he can enable it.

>From the distributions' point of view, this is a rubbish argument.

Most users haven't even given this a moment's thought, aren't even aware of
the issues, don't even know to ask and, for them, it makes no difference.
They trust their distribution to deal with stuff they don't know about.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[David Howells]

Linus Torvalds  wrote:

> The same thing is true of some lockdown patch. Maybe it's a good thing
> in general. But whether it's a good thing is _entirely_ independent of
> any secure boot issue. I can see using secure boot without it, but I
> can very much also see using lockdown without secure boot.
> 
> The two things are simply entirely orthogonal. They have _zero_
> overlap. I'm not seeing why they'd be linked at all in any way.

I'm not sure I agree.  Here's my reasoning:

 (1) Lockdown mode really needs to activated during kernel boot, before
 userspace has a chance to run, otherwise there's a window of opportunity
 in which the kernel *isn't* locked down.

 (2) If the kernel isn't booted in secure boot mode, then there's the
 opportunity to tamper before the kernel even starts booting.

 (3) There doesn't seem any point in booting in secure boot mode if you don't
 protect the running kernel image against tampering.  What does it mean to
 be in "secure boot mode" in that case?  If the kernel can be tampered
 with, it would seem to be, by definition, insecure.

 (4) You can't validly promise the next OS you kexec that *it* is started in
 secure boot mode if you don't stop your image from being tampered with.
 Note that this doesn't prevent a compromised kernel from lying to the
 next OS.

 (5) Tampering with a running kernel can be achieved in a variety of ways:
 loading of arbitrary modules, loading of modified firmware, direct access
 to devices that can effect DMA, writing to /dev/mem, ...

 (6) We need to be able to load modules and firmware, but these can be signed,
 hashed or measured so we have some idea of their provenance - but signing
 can be worked around if, say, /dev/mem is writable.

 (7) If you told the BIOS[*] that you want to be in secure boot mode, then the
 kernel should honour that and try to prevent tampering with the image.

 (8) Turning lockdown mode on if the kernel is booted in secure boot seems to
 be the way to achieve this.

 (9) BIOS vendors can blacklist any of the components - say the SHIM - to
 prevent an insecure kernel from being used to compromise and kexec
 another OS.

Note that I've provided a kernel command line parameter that will turn
lockdown mode on arbitrarily - but that can be turned off by editing the
parameters in grub.cfg, say.

David

[*] Yeah, I know, this is an x86-centric view.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[David Howells]

Andy Lutomirski  wrote:

> I'm having a very, very hard time coming up with a scenario where I
> can "trust" something if an attacker can get root but can't modify the
> running kernel image but I can't "trust" something if the attacker
> can [modify the running kernel image].

(I think the above is what you meant)

Let's go at this a different way.  How do you decide you can trust something
in this context?  You compare it to something.  Signing it, keeping a hash
whitelist, IMA - these are all ways of comparing something.  Do you agree with
that?

However, the comparison can be subverted if the running kernel image (I might
be better saying running kernel state here since I'm not talking about the
source bzImage file) can be modified arbitrarily by userspace, either by
modifying the data against which the comparison is made - e.g. the public key
set or the hash list - or by modifying the code that makes the comparison.

/dev/mem, direct access to DMA, bpf, etc. all provide ways of modifying the
kernel image arbitrarily, which leads me to this:

> I *don't* buy into the party line about why signed modules should be needed
> for Secure Boot.

Modules are just another way of modifying the kernel image.  If I can just
create an arbitrary module and load it, then I can modify the kernel image
from within the module.

Locking down modules by signing, hashing or IMA practically prevents the
loading of arbitrarily constructed modules and only permits modules from a set
that the provider of the modules somewhat trusts.

What use is secure boot if processes run as root can subvert your kernel?

> > There's no point bothering with UID/GID checking either.
> 
> Give me a break.  There's a *huge* difference between a system where
> only root can load unsigned modules and a system where anyone can load
> unsigned modules.

I don't think we've ever advocated letting just anyone load a module.

But my point is that if you can modify the running kernel, you can nullify all
security checks, including UID/GID checks.

> > However, if /dev/mem can be read, any root process can extract the session
> > key for your disk.
> 
> Any root process can read /dev/mapper/plaintext_disk, lockdown or otherwise.

True - for now - and they can also access the mounted filesystem.  But if they
get their hands on your powered-off computer, no, they can't.

> But I don't think the upstream kernel should apply a patch that ties any of
> this to Secure Boot without a genuine technical reason why it makes sense.

Because unless you turn lockdown on during kernel boot, there exists a window
of opportunity where the kernel isn't locked down and can be accessed, thereby
obviating the fact that you started in Secure Boot mode.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[David Howells]

Andy Lutomirski  wrote:

> > If the user can arbitrarily modify the running kernel image, you cannot
> > trust anything.  You cannot determine the trustworthiness of something
> > because your basis for determining that trust can be compromised.
> 
> I'm having a very, very hard time coming up with a scenario where I
> can "trust" something if an attacker can get root but can't modify the
> running kernel image but I can't "trust" something if the attacker
> can't.

Eh?  If the attacker can't what?  Did you mean to put "can" at the end of that
rather than "can't"?  I don't see why the kernel-level trust would be
compromised if an attacker can't get root and can't modify the running kernel
image.

Here's a simple scenario: You boot your machine.  You have module verification
keys in your kernel.  You have /dev/mem available for root to read/write.  A
program running as root can modify the keys in your kernel or just disable the
checking code entirely.  It can now insmod any module it likes.  You may as
well not bother with signed modules.  In fact, it can modify the running
kernel image in any way it likes, without even having to load modules.
There's no point bothering with UID/GID checking either.

> > Stopping the kernel from being arbitrarily read stops any encryption keys it
> > may be using from being retrieved.
> 
> If I build a server that runs Panera Bread 2.0's website, and the
> attacker exploits my machine to steal tens of millions of customer
> records by getting the machine to talk to some database server using
> keys that are securely stored in the kernel keyring, ...

I was thinking more in terms of preventing access to the encrypted data on
your own disk.  The key for that could be unlocked using a TPM, but the
session key then has to be retained in RAM for performance reasons unless you
can transfer the session key to, say, your SATA controller without it going
through the CPU.

However, if /dev/mem can be read, any root process can extract the session key
for your disk.

But, as you suggest, they could also protect secrets used in communications.
However, the communications themselves have to be exposed to userspace for
userspace to be able to use them.  That is unavoidable.  The kernel keyring,
for example, tries to restrict who can even see a key, much less use it as
much as possible - but ptrace() exists...  You are no less vulnerable if the
key is held in a userspace process; then the attacker can get the key and the
data.

If the kernel is locked down, the aim is to try and make sure that keys
stashed in the kernel cannot be read, though they have to be able to be used,
or there's no point to them.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[David Howells]

Andy Lutomirski  wrote:

> >>> A kernel that allows users arbitrary access to ring 0 is just an
> >>> overfeatured bootloader. Why would you want secure boot in that case?
> >>
> >> To get a chain of trust.
> >
> > You don't have a chain of trust that you can trust in that case.
> >
> Please elaborate on why I can’t trust it.

If the user can arbitrarily modify the running kernel image, you cannot trust
anything.  You cannot determine the trustworthiness of something because your
basis for determining that trust can be compromised.

> Please also elaborate on how lockdown helps at all.

Stopping the kernel from being arbitrarily modified allows you to preserve
your trust.

Stopping the kernel from being arbitrarily read stops any encryption keys it
may be using from being retrieved.

And, if you can't guarantee the trustworthiness of your own image, you can't
pass the trust onto the next image that you kexec.

Now, I can't guarantee that my patches close every hole, they just close all
the holes I know about - including some obscure ones like using DMA-capable
ISA devices to hack/access the kernel image.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[David Howells]

Andy Lutomirski  wrote:

> > A kernel that allows users arbitrary access to ring 0 is just an
> > overfeatured bootloader. Why would you want secure boot in that case?
> 
> To get a chain of trust.

You don't have a chain of trust that you can trust in that case.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Kernel lockdown for secure boot

[David Howells]

James Morris  wrote:

> Are there any known coverage gaps now?

I've covered all the ones I know about.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] Kernel lockdown for secure boot

[David Howells]

Date: Thu, 26 Oct 2017 17:37:38 +0100

Hi James,

Can you pull this patchset into security/next please?  It has been in
linux-next since the beginning of March.

It adds kernel lockdown support for EFI secure boot.

There's a manual page (kernel_lockdown.7) associated with this:

.\"
.\" Copyright (C) 2017 Red Hat, Inc. All Rights Reserved.
.\" Written by David Howells (dhowe...@redhat.com)
.\"
.\" %%%LICENSE_START(GPLv2+_SW_ONEPARA)
.\" This program is free software; you can redistribute it and/or
.\" modify it under the terms of the GNU General Public License
.\" as published by the Free Software Foundation; either version
.\" 2 of the License, or (at your option) any later version.
.\" %%%LICENSE_END
.\"
.TH "KERNEL LOCKDOWN" 7 2017-10-05 Linux "Linux Programmer's Manual"
.SH NAME
Kernel Lockdown \- Kernel image access prevention feature
.SH DESCRIPTION
The Kernel Lockdown feature is designed to prevent both direct and indirect
access to a running kernel image, attempting to protect against unauthorised
modification of the kernel image and to prevent access to security and
cryptographic data located in kernel memory, whilst still permitting driver
modules to be loaded.
.P
Lockdown is typically enabled during boot and may be terminated, if configured,
by typing a special key combination on a directly attached physical keyboard.
.P
If a prohibited or restricted feature is accessed or used, the kernel will emit
a message that looks like:
.P
.RS
Lockdown: X: Y is restricted, see man kernel_lockdown.7
.RE
.P
where X indicates the process name and Y indicates what is restricted.
.P
On an EFI-enabled x86 or arm64 machine, lockdown will be automatically enabled
if the system boots in EFI Secure Boot mode.
.P
If the kernel is appropriately configured, lockdown may be lifted by typing the
appropriate sequence on a directly attached physical keyboard.  For x86
machines, this is
.IR SysRq+x .
.\"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
.SH COVERAGE
When lockdown is in effect, a number of features are disabled or have their use
restricted.  This includes special device files and kernel services that allow
direct access of the kernel image:
.P
.RS
/dev/mem
.br
/dev/kmem
.br
/dev/kcore
.br
/dev/ioports
.br
BPF
.br
kprobes
.RE
.P
and the ability to directly configure and control devices, so as to prevent the
use of a device to access or modify a kernel image:
.P
.RS
The use of module parameters that directly specify hardware parameters to
drivers through the kernel command line or when loading a module.
.P
The use of direct PCI BAR access.
.P
The use of the ioperm and iopl instructions on x86.
.P
The use of the KD*IO console ioctls.
.P
The use of the TIOCSSERIAL serial ioctl.
.P
The alteration of MSR registers on x86.
.P
The replacement of the PCMCIA CIS.
.P
The overriding of ACPI tables.
.P
The use of ACPI error injection.
.P
The specification of the ACPI RDSP address.
.P
The use of ACPI custom methods.
.RE
.P
Certain facilities are restricted:
.P
.RS
Only validly signed modules may be loaded (waived if the module file being
loaded is vouched for by IMA appraisal).
.P
Only validly signed binaries may be kexec'd (waived if the binary image file to
be executed is vouched for by IMA appraisal).
.P
Unencrypted hibernation/suspend to swap are disallowed as the kernel image is
saved to a medium that can then be accessed.
.P
Use of debugfs is not permitted as this allows a whole range of actions
including direct configuration of, access to and driving of hardware.
.P
IMA requires the addition of the "secure_boot" rules to the policy, whether or
not they are specified on the command line, for both the builtin and custom
policies in secure boot lockdown mode.
.RE


David
---
The following changes since commit 6f70eb2b00eb416146247c65003d31f4df983ce0:

  Merge branch 'idr-2018-02-06' of 
git://git.infradead.org/users/willy/linux-dax (2018-02-26 13:22:45 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git 
tags/lockdown-20180330

for you to fetch changes up to 89bcd5b02f125335f74289c5f4ae03e9b893ab7f:

  lockdown: Print current->comm in restriction messages (2018-02-28 14:43:03 
+)


Kernel lockdown


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

David Howells (15):
  Add the ability to lock down access to th

Re: linux-next: UEFI Secure boot lockdown patchset

[David Howells]

I forgot to include the branch URL:


https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lock-down

Thanks for spotting that, Ard!

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

linux-next: UEFI Secure boot lockdown patchset

[David Howells]

Hi Stephen,

Can you pull the following branch into linux-next please?  It does three
things:

 (1) It restricts various accesses userspace may make upon the kernel when the
 kernel is locked down.

 (2) It engages the lockdown if UEFI Secure Boot mode is detected.

 (3) It passes the UEFI Secure Boot mode indication across kexec.

The restrictions include:

 - Enforcing the use of module signatures
 - Enforcing the use of kexec image signatures
 - Requring IMA to use secure boot rules
 - Disabling:
   - The kexec_load() syscall
   - Use of /dev/{mem,kmem,port,kcore}
   - Hibernation
   - PCI BAR access
   - Direct I/O port access
 - Preventing direct port specification in drivers:
   - SCSI EATA
   - TIOCSSERIAL
   - Module parameters
 - Restricting:
   - MSR access
   - Certain ACPI features
   - kprobes
   - BPF
   - Perf
   - Debugfs

The aim of the restrictions is twofold:

  (1) Prevent userspace from altering the kernel image directly (eg. by
  /dev/mem) or indirectly (eg. by manipulating a device to do DMA);

  (2) Prevent userspace from accessing crypto data stored in the kernel
  (eg. filesystem keys).

A warning is logged if a restriction is triggered for which I've written a
manpage that is referenced in the message (see attached).

David

.\"
.\" Copyright (C) 2017 Red Hat, Inc. All Rights Reserved.
.\" Written by David Howells (dhowe...@redhat.com)
.\"
.\" %%%LICENSE_START(GPLv2+_SW_ONEPARA)
.\" This program is free software; you can redistribute it and/or
.\" modify it under the terms of the GNU General Public License
.\" as published by the Free Software Foundation; either version
.\" 2 of the License, or (at your option) any later version.
.\" %%%LICENSE_END
.\"
.TH "KERNEL LOCKDOWN" 7 2017-10-05 Linux "Linux Programmer's Manual"
.SH NAME
Kernel Lockdown \- Kernel image access prevention feature
.SH DESCRIPTION
The Kernel Lockdown feature is designed to prevent both direct and indirect
access to a running kernel image, attempting to protect against unauthorised
modification of the kernel image and to prevent access to security and
cryptographic data located in kernel memory, whilst still permitting driver
modules to be loaded.
.P
Lockdown is typically enabled during boot and may be terminated, if configured,
by typing a special key combination on a directly attached physical keyboard.
.P
If a prohibited or restricted feature is accessed or used, the kernel will emit
a message that looks like:
.P
.RS
	Lockdown: X: Y is restricted, see man kernel_lockdown.7
.RE
.P
where X indicates the process name and Y indicates what is restricted.
.P
On an EFI-enabled x86 or arm64 machine, lockdown will be automatically enabled
if the system boots in EFI Secure Boot mode.
.P
If the kernel is appropriately configured, lockdown may be lifted by typing the
appropriate sequence on a directly attached physical keyboard.  For x86
machines, this is
.IR SysRq+x .
.\"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
.SH COVERAGE
When lockdown is in effect, a number of features are disabled or have their use
restricted.  This includes special device files and kernel services that allow
direct access of the kernel image:
.P
.RS
/dev/mem
.br
/dev/kmem
.br
/dev/kcore
.br
/dev/ioports
.br
BPF
.br
kprobes
.RE
.P
and the ability to directly configure and control devices, so as to prevent the
use of a device to access or modify a kernel image:
.P
.RS
The use of module parameters that directly specify hardware parameters to
drivers through the kernel command line or when loading a module.
.P
The use of direct PCI BAR access.
.P
The use of the ioperm and iopl instructions on x86.
.P
The use of the KD*IO console ioctls.
.P
The use of the TIOCSSERIAL serial ioctl.
.P
The alteration of MSR registers on x86.
.P
The replacement of the PCMCIA CIS.
.P
The overriding of ACPI tables.
.P
The use of ACPI error injection.
.P
The specification of the ACPI RDSP address.
.P
The use of ACPI custom methods.
.RE
.P
Certain facilities are restricted:
.P
.RS
Only validly signed modules may be loaded (waived if the module file being
loaded is vouched for by IMA appraisal).
.P
Only validly signed binaries may be kexec'd (waived if the binary image file to
be executed is vouched for by IMA appraisal).
.P
Unencrypted hibernation/suspend to swap are disallowed as the kernel image is
saved to a medium that can then be accessed.
.P
Use of debugfs is not permitted as this allows a whole range of actions
including direct configuration of, access to and driving of hardware.
.P
IMA requires the addition of the "secure_boot" rules to the policy, whether or
not they are specified on the command line, for both the builtin and custom
policies in secure boot lockdown mode.
.RE

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

[David Howells]

David Howells <dhowe...@redhat.com> wrote:

> I'm intending on inserting the attached patch before this one.

And replacing this patch with the attached.

David
---
commit ed0424c531d7dd25adebdec0ee6a78a5784f207a
Author: David Howells <dhowe...@redhat.com>
Date:   Thu Feb 22 14:01:49 2018 +

kexec_file: Restrict at runtime if the kernel is locked down

When KEXEC_VERIFY_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 <jbo...@suse.cz>
    Signed-off-by: David Howells <dhowe...@redhat.com>
Cc: Matthew Garrett <mj...@srcf.ucam.org>
cc: Chun-Yi Lee <j...@suse.com>
cc: ke...@lists.infradead.org

diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index d5931e392050..c47c4de604cd 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -167,6 +167,14 @@ kimage_file_prepare_segments(struct kimage *image, int 
kernel_fd, int initrd_fd,
}
 
ret = 0;
+   if (is_ima_appraise_enabled())
+   break;
+
+   if (kernel_is_locked_down(reason)) {
+   ret = -EPERM;
+   goto out;
+   }
+
break;
 
/* All other errors are fatal, including nomem, unparseable
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

I'm intending on inserting the attached patch before this one.

David
---
commit 87a39b258eca2e15884ee90c3fcd5758d6057b17
Author: David Howells <dhowe...@redhat.com>
Date:   Thu Feb 22 13:42:04 2018 +

kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

This is a preparatory patch for kexec_file_load() lockdown.  A locked down
kernel needs to prevent unsigned kernel images to be 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 <jbo...@suse.cz>
Signed-off-by: David Howells <dhowe...@redhat.com>
cc: Matthew Garrett <mj...@srcf.ucam.org>
cc: Chun-Yi Lee <j...@suse.com>
cc: ke...@lists.infradead.org

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c1236b187824..cb6e67b7442d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2019,20 +2019,30 @@ config KEXEC_FILE
  for kernel and initramfs as opposed to list of segments as
  accepted by previous system call.
 
-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/arch/x86/kernel/machine_kexec_64.c 
b/arch/x86/kernel/machine_kexec_64.c
index 1f790cf9d38f..3fbe35b923ef 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -406,7 +406,7 @@ int arch_kimage_file_post_load_cleanup(struct kimage *image)
return image->fops->cleanup(image->image_loader_data);
 }
 
-#ifdef CONFIG_KEXEC_VERIFY_SIG
+#ifdef CONFIG_KEXEC_SIG
 int arch_kexec_kernel_verify_sig(struct kimage *image, void *kernel,
 unsigned long kernel_len)
 {
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 signa

Re: [PATCH 04/30] Enforce module signatures if the kernel is locked down

[David Howells]

I'm considering folding the attached changes into this patch.

It adjusts 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.

David
---
diff --git a/kernel/module.c b/kernel/module.c
index 1eb06a0ccbfb..62419cf48ef6 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2769,8 +2769,9 @@ static inline void kmemleak_load_module(const struct 
module *mod,
 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;
 
/*
@@ -2785,18 +2786,42 @@ static int module_sig_check(struct load_info *info, int 
flags,
err = mod_verify_sig(mod, >len);
}
 
-   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 && !sig_enforce &&
-   (!can_do_ima_check || !is_ima_appraise_enabled()) &&
-   !kernel_is_locked_down("Loading of unsigned modules"))
-   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 (sig_enforce) {
+   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,
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08a/30] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

[David Howells]

Jiri Bohac  wrote:

> Key verification may and will fail for lots of reasons which is
> just going to make a user's life harder. E.g. you want to kexec
> an old kernel with an expired key. Or your date is just wrong and
> you get -EKEYEXPIRED.

Note that we can't check for expired keys as we can't trust the system clock
to be correct at this point.

> Also, only now I found that some of the error codes the crypto
> code returns yield really confusing messages (e.g.
> kexec_file_load of an unsigned kernel returns -ELIBBAD which
> makes kexec exit with "kexec_file_load failed: Accessing a
> corrupted shared library").

Yeah, that should be fixed.

> Maybe the error code could be unified to -EKEYREJECTED for all
> sorts of key verification failures?

Things like ENOMEM and EINTR definitely need to stay separate (not that I
allow interruption at the moment).

ENOKEY (couldn't find matching key), EINVAL (didn't recognise identifier),
ENOPKG (couldn't find a crypto algo) and EBADMSG (couldn't parse signature)
are arguable.  I think there's a valid case for treating ENOKEY, EINVAL and
ENOPKG differently to EKEYREJECTED - more so for ENOKEY.  In my opinion,
ENOKEY, EINVAL and ENOPKG are not fatal errors if we're not enforcing
signature checking, but EKEYREJECTED and EBADMSG are.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08a/30] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

[David Howells]

Jiri Bohac  wrote:

> > If sig_err is -EKEYREJECTED, -EKEYEXPIRED or -EKEYREVOKED then it must fail,
> > even if the signature check isn't forced.
> 
> It wasn't my intention to fail in these cases. What additional
> security does this bring? If simply stripping an invalid
> signature from the image before loading will make it pass, why
> should the image with an invalid signature be rejected?

If there is a signature, then if we're checking signatures, in my opinion we
should check it - and fail if the signature can't be parsed, is revoked, we
have a key and the signature doesn't match - or even if we run out of memory.

The cases for which enforcement is required are when (a) there is no
signature, (b) we don't support the algorithms used, or (c) we don't have a
key.

If we're going to completely discard the result, why do your patches even
bother to check the signature at all?

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

Jiri Bohac  wrote:

> > Having said that, I do see your point, I think.  We should still let through
> > validly signed images, even if signatures aren't mandatory in lockdown mode.
> 
> yes, to be clear, the problem I'm trying to fix is:
> - without CONFIG_KEXEC_VERIFY_SIG kexec in a locked down kernel
>   will not work at all -> every distro that wants to support
>   secureboot will need to enable CONFIG_KEXEC_VERIFY_SIG;
> 
> - once CONFIG_KEXEC_VERIFY_SIG is enabled, kexec images need to
>   be signed even if secureboot is not used
>
> The problem is that CONFIG_KEXEC_VERIFY_SIG enables both the
> implementation and the enforcement of the signature checking.

Yep.  I understand that.

> What I'm proposing are new config options that allow a kernel to
> be compiled in such a way that:
> - kexec works even without signatures if secureboot is off
> - kexec works with secureboot but requires signed images

Agreed to both of those.  I also agree with making it possible to
configurationally require signatures, which your first patch does.

> The semantics should be the same as with signed modules, because
> requiring kexec signatures when you can load unsigned modules is
> futile. But with your original patchset, that's exactly what
> distro kernels will be doing when booted with secureboot off,
> MODULE_SIG_FORCE=n and KEXEC_VERIFY_SIG=y.

I should fix that.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08a/30] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

[David Howells]

I think that your code isn't quite right.  Looking at the patched code:

#ifdef CONFIG_KEXEC_SIG
sig_err = arch_kexec_kernel_verify_sig(image, image->kernel_buf,
   image->kernel_buf_len);
if (sig_err)
pr_debug("kernel signature verification failed.\n");
else
pr_debug("kernel signature verification successful.\n");
#endif

if (sig_err && IS_ENABLED(CONFIG_KEXEC_SIG_FORCE)) {
ret = sig_err;
goto out;
}

If the signature check fails because the signature is bad, but
CONFIG_KEXEC_SIG_FORCE=n then it now won't fail when it should.

If sig_err is -EKEYREJECTED, -EKEYEXPIRED or -EKEYREVOKED then it must fail,
even if the signature check isn't forced.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

David Howells <dhowe...@redhat.com> wrote:

> > I don't like the idea that the lockdown (which is a runtime
> > thing) requires a compile time option (KEXEC_VERIFY_SIG) that
> > forces the verification even when the kernel is then not locked
> > down at runtime.
> 
> It doesn't.  The EPERM only triggers if:
> 
>  (1) File signatures aren't mandatory (ie. CONFIG_KEXEC_VERIFY_SIG) is not
>  set, and
> 
>  (2) you're not using IMA appraisal to validate the file contents, and
> 
>  (3) lockdown mode is enabled.
> 
> If file signatures are mandatory or IMA appraisal is in use, then the lockdown
> state doesn't need to be checked.

Having said that, I do see your point, I think.  We should still let through
validly signed images, even if signatures aren't mandatory in lockdown mode.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

Jiri Bohac  wrote:

> I don't like the idea that the lockdown (which is a runtime
> thing) requires a compile time option (KEXEC_VERIFY_SIG) that
> forces the verification even when the kernel is then not locked
> down at runtime.

It doesn't.  The EPERM only triggers if:

 (1) File signatures aren't mandatory (ie. CONFIG_KEXEC_VERIFY_SIG) is not
 set, and

 (2) you're not using IMA appraisal to validate the file contents, and

 (3) lockdown mode is enabled.

If file signatures are mandatory or IMA appraisal is in use, then the lockdown
state doesn't need to be checked.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

[David Howells]

Alan Cox  wrote:

> So you don't actually need to sign a lot of PC class firmware because
> it's already signed.

Whilst that may be true, we either have to check signatures on every bit of
firmware that the appropriate driver doesn't say is meant to be signed or not
bother.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 26/30] Lock down ftrace

[David Howells]

Okay, I've dropped the ftrace lockdown patch for the moment from my git
branch.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 26/30] Lock down ftrace

[David Howells]

Jiri Kosina  wrote:

> > The idea is to prevent cryptographic data for filesystems and other things
> > from being read out of the kernel memory as well as to prevent unauthorised
> > modification of kernel memory.
> 
> Then it would make sense to actually lock down dumping of registers / 
> function arguments (kprobes can currently do that, ftrace eventually could 
> as well I guess), but disabling the whole ftrace altogether seems like a 
> totally unnecessary overkill.

That would be fine by me.  I have a patch that locks down kprobes in this
series.  Steven says that ftrace might acquire the ability to dump registers
in the future.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 26/30] Lock down ftrace

[David Howells]

Jiri Kosina  wrote:

> > This prevents crypto data theft by analysis of execution patterns, and, if
> > in future ftrace also logs the register contents at the time, will prevent
> > data theft by that mechanism also.
> 
> I fail to see how this fits into the secure boot security model, could you 
> please explain?

The idea is to prevent cryptographic data for filesystems and other things
from being read out of the kernel memory as well as to prevent unauthorised
modification of kernel memory.

> Secure boot is about having a constant proof / verification that the code 
> you're running in ring0 can be trusted (IOW is the one that has been 
> signed and verified by the whole boot chain).
> 
> Checking execution patterns doesn't seem to fit at all.

I'll defer this question to Alexei since he suggested I needed to deal with
this too.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/30] security, efi: Add kernel lockdown

[David Howells]

Here's a set of patches to institute a "locked-down mode" in the kernel and
to trigger that mode if the kernel is booted in secure-boot mode or through
the command line.

Enabling CONFIG_LOCK_DOWN_KERNEL makes lockdown mode available.

Enabling CONFIG_ALLOW_LOCKDOWN_LIFT_BY_SYSRQ will allow a SysRq combination
to lift the lockdown.  On x86 this is SysRq+x.  The keys must be pressed on
an attached keyboard.

Enabling CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT will cause EFI secure boot to
trigger kernel lockdown.

Inside the kernel, kernel_is_locked_down() is used to check if the kernel
is in lockdown mode.

Note that the secure boot mode entry doesn't work if the kernel is booted
from older versions of i386/x86_64 Grub as there's a bug in Grub whereby it
doesn't initialise the boot_params correctly.  The incorrect initialisation
causes sanitize_boot_params() to be triggered, thereby zapping the secure
boot flag determined by the EFI boot wrapper.

A manual page, kernel_lockdown.7, is proposed, to which people will be
directed by messages in dmesg.  This lists the features that are restricted
amongst other things.  [Note: I need to update this to mention IMA, so I'll
reply with that later].

Changes:

 (*) Made /dev/mem and /dev/kmem explicitly unopenable in lockdown mode,
 rather than being unopenable as a side effect of /dev/port being made
 unopenable.

 (*) Added lockdowns for ftrace and kprobes.

 (*) Made the bpf lockdown prohibit the use of sys_bpf entirely.

 (*) Made IMA require secure_boot rules in lockdown mode.

 (*) Made module signing and kexec allow unsigned images if IMA has been
 used to validate the image.


The patches can be found here also:


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

David
---
Chun-Yi Lee (1):
  kexec_file: Restrict at runtime if the kernel is locked down

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

David Howells (14):
  Add the ability to lock down access to the running kernel image
  Enforce module signatures if the kernel is locked down
  scsi: Lock down the eata driver
  Prohibit PCMCIA CIS storage when the kernel is locked down
  Lock down TIOCSSERIAL
  Lock down module params that specify hardware parameters (eg. ioport)
  x86/mmiotrace: Lock down the testmmiotrace module
  debugfs: Disallow use of debugfs files when the kernel is locked down
  Lock down /proc/kcore
  Lock down ftrace
  Lock down kprobes
  bpf: Restrict kernel image access functions when the kernel is locked down
  efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode
  efi: Lock down the kernel if booted in secure boot mode

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 (8):
  Restrict /dev/{mem,kmem,port} when the kernel is locked down
  kexec: Disable at runtime if the kernel is locked down
  uswsusp: Disable when the kernel is locked down
  PCI: Lock down BAR access when the kernel is locked down
  x86: Lock down IO port access when the kernel is locked down
  x86/msr: Restrict MSR access when the kernel is locked down
  asus-wmi: Restrict debugfs interface when the kernel is locked down
  ACPI: Limit access to custom_method when the kernel is locked down

Mimi Zohar (1):
  ima: require secure_boot rules in lockdown mode


 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/kernel/setup.c |   18 +-
 arch/x86/mm/testmmiotrace.c |3 +
 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/firmware/efi/Makefile   |1 
 drivers/firmware/efi/secureboot.c   |   38 
 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/platform/x86/asus-wmi.c |9 +++
 drivers/scsi/eata.c |5 +-
 drivers/tty/serial/serial_core.c|6 ++
 drivers/tty/sysrq.c |   19 --
 fs/debugfs/file.c   |6 ++
 fs/proc/kcore.c |2 +
 include/linux/efi.h |   16 +++--
 include/linux/input.h   |5 ++
 inc

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

[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 <dhowe...@redhat.com>
Acked-by: James Morris <james.l.mor...@oracle.com>
---

 include/linux/kernel.h   |   17 +
 include/linux/security.h |8 ++
 security/Kconfig |8 ++
 security/Makefile|3 ++
 security/lock_down.c |   60 ++
 5 files changed, 96 insertions(+)
 create mode 100644 security/lock_down.c

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 0ad4c3044cf9..362da2e4bf53 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -287,6 +287,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 ce6265960d6c..310775476b68 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -1753,5 +1753,13 @@ static inline void free_secdata(void *secdata)
 { }
 #endif /* CONFIG_SECURITY */
 
+#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 e8e449444e65..8e01fd59ae7e 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -205,6 +205,14 @@ 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 under certain circumstances, for
+ instance if UEFI secure boot is enabled.  Locking down the kernel
+ turns off various features that might otherwise allow access to the
+ kernel image (eg. setting MSR registers).
+
 source security/selinux/Kconfig
 source security/smack/Kconfig
 source security/tomoyo/Kconfig
diff --git a/security/Makefile b/security/Makefile
index f2d71cdb8e19..8c4a43e3d4e0 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -29,3 +29,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 ..d8595c0e6673
--- /dev/null
+++ b/security/lock_down.c
@@ -0,0 +1,60 @@
+/* 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 line");
+   return 0;
+}
+
+early_param("lockdown", lockdown_param);
+
+/*
+ * Lock the kernel down from very early in the arch setup.  This must happen
+ * prior to things like ACPI being initialised.
+ */
+void __init init_lockdown(void)
+{
+#ifdef CONFIG_LOCK_D

[PATCH 03/30] ima: require secure_boot rules in lockdown mode

[David Howells]

From: Mimi Zohar <zo...@linux.vnet.ibm.com>

Require the "secure_boot" rules, whether or not it is specified
on the boot command line, for both the builtin and custom policies
in secure boot lockdown mode.

Signed-off-by: Mimi Zohar <zo...@linux.vnet.ibm.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
---

 security/integrity/ima/ima_policy.c |   39 ++-
 1 file changed, 29 insertions(+), 10 deletions(-)

diff --git a/security/integrity/ima/ima_policy.c 
b/security/integrity/ima/ima_policy.c
index 95209a5f8595..49c75e2a1ec5 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -427,14 +427,21 @@ void ima_update_policy_flag(void)
  */
 void __init ima_init_policy(void)
 {
-   int i, measure_entries, appraise_entries, secure_boot_entries;
+   int i;
+   int measure_entries = 0;
+   int appraise_entries = 0;
+   int secure_boot_entries = 0;
+   bool kernel_locked_down = __kernel_is_locked_down(NULL, false);
 
/* if !ima_policy set entries = 0 so we load NO default rules */
-   measure_entries = ima_policy ? ARRAY_SIZE(dont_measure_rules) : 0;
-   appraise_entries = ima_use_appraise_tcb ?
-ARRAY_SIZE(default_appraise_rules) : 0;
-   secure_boot_entries = ima_use_secure_boot ?
-   ARRAY_SIZE(secure_boot_rules) : 0;
+   if (ima_policy)
+   measure_entries = ARRAY_SIZE(dont_measure_rules);
+
+   if (ima_use_appraise_tcb)
+   appraise_entries = ARRAY_SIZE(default_appraise_rules);
+
+   if (ima_use_secure_boot || kernel_locked_down)
+   secure_boot_entries = ARRAY_SIZE(secure_boot_rules);
 
for (i = 0; i < measure_entries; i++)
list_add_tail(_measure_rules[i].list, _default_rules);
@@ -455,11 +462,23 @@ void __init ima_init_policy(void)
 
/*
 * Insert the appraise rules requiring file signatures, prior to
-* any other appraise rules.
+* any other appraise rules.  In secure boot lock-down mode, also
+* require these appraise rules for custom policies.
 */
-   for (i = 0; i < secure_boot_entries; i++)
-   list_add_tail(_boot_rules[i].list,
- _default_rules);
+   for (i = 0; i < secure_boot_entries; i++) {
+   struct ima_rule_entry *entry;
+
+   /* Include for builtin policies */
+   list_add_tail(_boot_rules[i].list, _default_rules);
+
+   /* Include for custom policies */
+   if (kernel_locked_down) {
+   entry = kmemdup(_boot_rules[i], sizeof(*entry),
+   GFP_KERNEL);
+   if (entry)
+   list_add_tail(>list, _policy_rules);
+   }
+   }
 
for (i = 0; i < appraise_entries; i++) {
list_add_tail(_appraise_rules[i].list,

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 06/30] kexec: Disable at runtime if the kernel is locked down

[David Howells]

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

kexec permits the loading and execution of arbitrary code in ring 0, which
is something that lock-down is meant to prevent. It makes sense to disable
kexec in this situation.

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

Signed-off-by: Matthew Garrett <matthew.garr...@nebula.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
Acked-by: Dave Young <dyo...@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <j...@suse.com>
Reviewed-by: James Morris <james.l.mor...@oracle.com>
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 e62ec4dc6620..7dadfed9b676 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -202,6 +202,13 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned 
long, nr_segments,
return -EPERM;
 
/*
+* kexec can be used to circumvent module loading restrictions, so
+* prevent loading in that case
+*/
+   if (kernel_is_locked_down("kexec of unsigned images"))
+   return -EPERM;
+
+   /*
 * Verify we have a legal set of flags
 * This leaves us room for future extensions.
 */

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/30] Copy secure_boot flag in boot params across kexec reboot

[David Howells]

From: Dave Young <dyo...@redhat.com>

Kexec reboot in case secure boot being enabled does not keep the secure
boot mode in new kernel, so later one can load unsigned kernel via legacy
kexec_load.  In this state, the system is missing the protections provided
by secure boot.

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

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

Signed-off-by: Dave Young <dyo...@redhat.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <j...@suse.com>
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 fb095ba0c02f..7d0fac5bcbbe 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;

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

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

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 <matthew.garr...@nebula.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <j...@suse.com>
---

 drivers/char/mem.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 593a8818aca9..0ce5ac0a5c6b 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -762,6 +762,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;
 }
 

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

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

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 <matthew.garr...@nebula.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
Acked-by: Bjorn Helgaas <bhelg...@google.com>
Reviewed-by: "Lee, Chun-Yi" <j...@suse.com>
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 1eecfa301f7f..e1a3b0e765c2 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -881,6 +881,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) {
@@ -1175,6 +1178,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;
 
@@ -1255,6 +1261,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 098360d7ff81..a6c53d855daa 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -116,6 +116,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)
@@ -195,6 +198,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);
@@ -236,7 +242,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 9bf993e1f71e..afa01cc3ceec 100644
--- a/drivers/pci/syscall.c
+++ b/drivers/pci/syscall.c
@@ -92,7 +92,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_bus_and_slot(bus, dfn);

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

From: Chun-Yi Lee <joeyli.ker...@gmail.com>

When KEXEC_VERIFY_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.

This code was showed in Matthew's patch but not in git:
https://lkml.org/lkml/2015/3/13/778

Cc: Matthew Garrett <mj...@srcf.ucam.org>
Signed-off-by: Chun-Yi Lee <j...@suse.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
Reviewed-by: James Morris <james.l.mor...@oracle.com>
cc: ke...@lists.infradead.org
---

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

diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 9f48f4412297..3ba28fc3fab0 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -255,6 +255,14 @@ SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, 
initrd_fd,
if (!capable(CAP_SYS_BOOT) || kexec_load_disabled)
return -EPERM;
 
+   /* Don't permit images to be loaded into trusted kernels if we're not
+* going to verify the signature on them
+*/
+   if (!IS_ENABLED(CONFIG_KEXEC_VERIFY_SIG) &&
+   !is_ima_appraise_enabled() &&
+   kernel_is_locked_down("kexec of unsigned images"))
+   return -EPERM;
+
/* Make sure we have a legal set of flags */
if (flags != (flags & KEXEC_FILE_FLAGS))
return -EINVAL;

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

From: Matthew Garrett <mj...@srcf.ucam.org>

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 <mj...@srcf.ucam.org>
Signed-off-by: David Howells <dhowe...@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <j...@suse.com>
Reviewed-by: James Morris <james.l.mor...@oracle.com>
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 22df9f7ff672..678ade9decfe 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)) {

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

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

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

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

Signed-off-by: Matthew Garrett <matthew.garr...@nebula.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
Reviewed-by: Thomas Gleixner <t...@linutronix.de>
Reviewed-by: "Lee, Chun-Yi" <j...@suse.com>
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 9c3cf0944bce..2c0f058651c5 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -30,7 +30,8 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned long 
num, int turn_on)
 
if ((from + num <= from) || (from + num > IO_BITMAP_BITS))
return -EINVAL;
-   if (turn_on && !capable(CAP_SYS_RAWIO))
+   if (turn_on && (!capable(CAP_SYS_RAWIO) ||
+   kernel_is_locked_down("ioperm")))
return -EPERM;
 
/*
@@ -120,7 +121,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) |

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 14/30] asus-wmi: Restrict debugfs interface when the kernel is locked down

[David Howells]

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

We have no way of validating what all of the Asus WMI methods do on a given
machine - and there's a risk that some will allow hardware state to be
manipulated in such a way that arbitrary code can be executed in the
kernel, circumventing module loading restrictions.  Prevent that if the
kernel is locked down.

Signed-off-by: Matthew Garrett <matthew.garr...@nebula.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <j...@suse.com>
cc: acpi4asus-u...@lists.sourceforge.net
cc: platform-driver-...@vger.kernel.org
---

 drivers/platform/x86/asus-wmi.c |9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 48e1541dc8d4..ef5587469337 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1905,6 +1905,9 @@ static int show_dsts(struct seq_file *m, void *data)
int err;
u32 retval = -1;
 
+   if (kernel_is_locked_down("Asus WMI"))
+   return -EPERM;
+
err = asus_wmi_get_devstate(asus, asus->debug.dev_id, );
 
if (err < 0)
@@ -1921,6 +1924,9 @@ static int show_devs(struct seq_file *m, void *data)
int err;
u32 retval = -1;
 
+   if (kernel_is_locked_down("Asus WMI"))
+   return -EPERM;
+
err = asus_wmi_set_devstate(asus->debug.dev_id, asus->debug.ctrl_param,
);
 
@@ -1945,6 +1951,9 @@ static int show_call(struct seq_file *m, void *data)
union acpi_object *obj;
acpi_status status;
 
+   if (kernel_is_locked_down("Asus WMI"))
+   return -EPERM;
+
status = wmi_evaluate_method(ASUS_WMI_MGMT_GUID,
 0, asus->debug.method_id,
 , );

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

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

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 <matthew.garr...@nebula.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
Acked-by: Kees Cook <keesc...@chromium.org>
Reviewed-by: Thomas Gleixner <t...@linutronix.de>
Reviewed-by: "Lee, Chun-Yi" <j...@suse.com>
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 ef688804f80d..dfb61d358196 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;

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

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

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

Signed-off-by: Matthew Garrett <matthew.garr...@nebula.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <j...@suse.com>
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 c68e72414a67..b33fba70ec51 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))

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

From: Linn Crosetto <l...@hpe.com>

>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 <l...@hpe.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <j...@suse.com>
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 80ce2a7d224b..5cc13c42daf9 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -526,6 +526,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);

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 19/30] scsi: Lock down the eata driver

[David Howells]

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

The eata driver takes a single string parameter that contains a slew of
settings, including hardware resource configuration.  Prohibit use of the
parameter if the kernel is locked down.

Suggested-by: Alan Cox <gno...@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowe...@redhat.com>
cc: Dario Ballabio <ballabio_da...@emc.com>
cc: "James E.J. Bottomley" <j...@linux.vnet.ibm.com>
cc: "Martin K. Petersen" <martin.peter...@oracle.com>
cc: linux-s...@vger.kernel.org
---

 drivers/scsi/eata.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
index 6501c330d8c8..72fceaa8f3da 100644
--- a/drivers/scsi/eata.c
+++ b/drivers/scsi/eata.c
@@ -1552,8 +1552,11 @@ static int eata2x_detect(struct scsi_host_template *tpnt)
 
tpnt->proc_name = "eata2x";
 
-   if (strlen(boot_options))
+   if (strlen(boot_options)) {
+   if (kernel_is_locked_down("Command line-specified device 
addresses, irqs and dma channels"))
+   return -EPERM;
option_setup(boot_options);
+   }
 
 #if defined(MODULE)
/* io_port could have been modified when loading as a module */

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

From: Josh Boyer <jwbo...@redhat.com>

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 <jwbo...@redhat.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <j...@suse.com>
cc: Dave Young <dyo...@redhat.com>
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 db78d353bab1..36c6527c1b0a 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -192,7 +192,7 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
acpi_physical_address pa = 0;
 
 #ifdef CONFIG_KEXEC
-   if (acpi_rsdp)
+   if (acpi_rsdp && !kernel_is_locked_down("ACPI RSDP specification"))
return acpi_rsdp;
 #endif
 

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

From: Linn Crosetto <l...@hpe.com>

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 <l...@hpe.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <j...@suse.com>
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 b38737c83a24..6d71e1e97b20 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)))

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 20/30] Prohibit PCMCIA CIS storage when the kernel is locked down

[David Howells]

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

Suggested-by: Dominik Brodowski <li...@dominikbrodowski.net>
Signed-off-by: David Howells <dhowe...@redhat.com>
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 55ef7d1fd8da..b7a0e42eeb25 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)

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 21/30] Lock down TIOCSSERIAL

[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 <gre...@linuxfoundation.org>
Signed-off-by: David Howells <dhowe...@redhat.com>
cc: Jiri Slaby <jsl...@suse.com>
---

 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 3a14cccbd7ff..41f0922ad842 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 ||

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 23/30] x86/mmiotrace: Lock down the testmmiotrace module

[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 <t...@linutronix.de>
Signed-off-by: David Howells <dhowe...@redhat.com
cc: Thomas Gleixner <t...@linutronix.de>
cc: Steven Rostedt <rost...@goodmis.org>
cc: Ingo Molnar <mi...@kernel.org>
cc: "H. Peter Anvin" <h...@zytor.com>
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");

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 24/30] debugfs: Disallow use of debugfs files when the kernel is locked down

[David Howells]

Disallow opening of debugfs files when the kernel is locked down as various
drivers give raw access to hardware through debugfs.

Accesses to tracefs should use /sys/kernel/tracing/ rather than
/sys/kernel/debug/tracing/.  Possibly a symlink should be emplaced.

Normal device interaction should be done through configfs 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.

Signed-off-by: David Howells <dhowe...@redhat.com>
cc: Andy Shevchenko <andy.shevche...@gmail.com>
cc: acpi4asus-u...@lists.sourceforge.net
cc: platform-driver-...@vger.kernel.org
cc: Matthew Garrett <matthew.garr...@nebula.com>
cc: Thomas Gleixner <t...@linutronix.de>
---

 fs/debugfs/file.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 6dabc4a10396..32b5168a7e91 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -103,6 +103,9 @@ static int open_proxy_open(struct inode *inode, struct file 
*filp)
const struct file_operations *real_fops = NULL;
int srcu_idx, r;
 
+   if (kernel_is_locked_down("debugfs"))
+   return -EPERM;
+
r = debugfs_use_file_start(dentry, _idx);
if (r) {
r = -ENOENT;
@@ -232,6 +235,9 @@ static int full_proxy_open(struct inode *inode, struct file 
*filp)
struct file_operations *proxy_fops = NULL;
int srcu_idx, r;
 
+   if (kernel_is_locked_down("debugfs"))
+   return -EPERM;
+
r = debugfs_use_file_start(dentry, _idx);
if (r) {
r = -ENOENT;

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[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 <gno...@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowe...@redhat.com>
---

 kernel/params.c |   26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/kernel/params.c b/kernel/params.c
index 60b2d8101355..422979adb60a 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_warn("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;
}
@@ -556,6 +564,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,
@@ -568,8 +582,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;

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 25/30] Lock down /proc/kcore

[David Howells]

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

Signed-off-by: David Howells <dhowe...@redhat.com>
Reviewed-by: James Morris <james.l.mor...@oracle.com>
---

 fs/proc/kcore.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 45629f4b5402..176cf749e650 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -549,6 +549,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;
 

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 26/30] Lock down ftrace

[David Howells]

Disallow the use of ftrace when the kernel is locked down.  This patch
turns off ftrace_enabled late in the kernel boot so that the selftest can
still be potentially be run.

The sysctl that controls ftrace_enables is also disallowed when the kernel
is locked down.  If the lockdown is lifted, then the sysctl can be used to
reenable ftrace - if ftrace was compiled with CONFIG_DYNAMIC_FTRACE, that
is; if it wasn't then it won't be possible to reenable it.

This prevents crypto data theft by analysis of execution patterns, and, if
in future ftrace also logs the register contents at the time, will prevent
data theft by that mechanism also.

Reported-by: Alexei Starovoitov <alexei.starovoi...@gmail.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
---

 kernel/trace/ftrace.c |   22 ++
 1 file changed, 22 insertions(+)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 6abfafd7f173..9c7135963d80 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -6508,6 +6508,9 @@ ftrace_enable_sysctl(struct ctl_table *table, int write,
 {
int ret = -ENODEV;
 
+   if (kernel_is_locked_down("Use of ftrace"))
+   return -EPERM;
+
mutex_lock(_lock);
 
if (unlikely(ftrace_disabled))
@@ -6896,3 +6899,22 @@ void ftrace_graph_exit_task(struct task_struct *t)
kfree(ret_stack);
 }
 #endif
+
+#ifdef CONFIG_LOCK_DOWN_KERNEL
+static int __init ftrace_lock_down(void)
+{
+   mutex_lock(_lock);
+
+   if (!ftrace_disabled && ftrace_enabled &&
+   kernel_is_locked_down("Use of ftrace")) {
+   ftrace_enabled = false;
+   last_ftrace_enabled = false;
+   ftrace_trace_function = ftrace_stub;
+   ftrace_shutdown_sysctl();
+   }
+
+   mutex_unlock(_lock);
+   return 0;
+}
+late_initcall(ftrace_lock_down);
+#endif

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[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 <alexei.starovoi...@gmail.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
cc: net...@vger.kernel.org
cc: Chun-Yi Lee <j...@suse.com>
cc: Alexei Starovoitov <alexei.starovoi...@gmail.com>
---

 kernel/bpf/syscall.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 25d074920a00..fa58ad74cde6 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -1458,6 +1458,9 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, 
uattr, unsigned int, siz
if (!capable(CAP_SYS_ADMIN) && sysctl_unprivileged_bpf_disabled)
return -EPERM;
 
+   if (kernel_is_locked_down("BPF"))
+   return -EPERM;
+
err = check_uarg_tail_zero(uattr, sizeof(attr), size);
if (err)
return err;

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 27/30] Lock down kprobes

[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 <alexei.starovoi...@gmail.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
---

 kernel/kprobes.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index a1606a4224e1..f06023b0936c 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1530,6 +1530,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))

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 29/30] efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode

[David Howells]

UEFI machines can be booted in Secure Boot mode.  Add an EFI_SECURE_BOOT
flag that can be passed to efi_enabled() to find out whether secure boot is
enabled.

Move the switch-statement in x86's setup_arch() that inteprets the
secure_boot boot parameter to generic code and set the bit there.

Suggested-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Signed-off-by: David Howells <dhowe...@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
cc: linux-efi@vger.kernel.org
---

 arch/x86/kernel/setup.c   |   14 +-
 drivers/firmware/efi/Makefile |1 +
 drivers/firmware/efi/secureboot.c |   38 +
 include/linux/efi.h   |   16 ++--
 4 files changed, 50 insertions(+), 19 deletions(-)
 create mode 100644 drivers/firmware/efi/secureboot.c

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 0957dd73d127..7c2162f9e769 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1197,19 +1197,7 @@ void __init setup_arch(char **cmdline_p)
/* Allocate bigger log buffer */
setup_log_buf(1);
 
-   if (efi_enabled(EFI_BOOT)) {
-   switch (boot_params.secure_boot) {
-   case efi_secureboot_mode_disabled:
-   pr_info("Secure boot disabled\n");
-   break;
-   case efi_secureboot_mode_enabled:
-   pr_info("Secure boot enabled\n");
-   break;
-   default:
-   pr_info("Secure boot could not be determined\n");
-   break;
-   }
-   }
+   efi_set_secure_boot(boot_params.secure_boot);
 
reserve_initrd();
 
diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index 0329d319d89a..883f9f7eefc6 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_EFI_FAKE_MEMMAP) += fake_mem.o
 obj-$(CONFIG_EFI_BOOTLOADER_CONTROL)   += efibc.o
 obj-$(CONFIG_EFI_TEST) += test/
 obj-$(CONFIG_EFI_DEV_PATH_PARSER)  += dev-path-parser.o
+obj-$(CONFIG_EFI)  += secureboot.o
 obj-$(CONFIG_APPLE_PROPERTIES) += apple-properties.o
 
 arm-obj-$(CONFIG_EFI)  := arm-init.o arm-runtime.o
diff --git a/drivers/firmware/efi/secureboot.c 
b/drivers/firmware/efi/secureboot.c
new file mode 100644
index ..9070055de0a1
--- /dev/null
+++ b/drivers/firmware/efi/secureboot.c
@@ -0,0 +1,38 @@
+/* Core kernel secure boot support.
+ *
+ * Copyright (C) 2017 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.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+
+/*
+ * Decide what to do when UEFI secure boot mode is enabled.
+ */
+void __init efi_set_secure_boot(enum efi_secureboot_mode mode)
+{
+   if (efi_enabled(EFI_BOOT)) {
+   switch (mode) {
+   case efi_secureboot_mode_disabled:
+   pr_info("Secure boot disabled\n");
+   break;
+   case efi_secureboot_mode_enabled:
+   set_bit(EFI_SECURE_BOOT, );
+   pr_info("Secure boot enabled\n");
+   break;
+   default:
+   pr_warning("Secure boot could not be determined (mode 
%u)\n",
+  mode);
+   break;
+   }
+   }
+}
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 66f4a4e79f4b..7c7a7e33e4d1 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -1103,6 +1103,14 @@ extern int __init efi_setup_pcdp_console(char *);
 #define EFI_DBG8   /* Print additional debug info 
at runtime */
 #define EFI_NX_PE_DATA 9   /* Can runtime data regions be mapped 
non-executable? */
 #define EFI_MEM_ATTR   10  /* Did firmware publish an 
EFI_MEMORY_ATTRIBUTES table? */
+#define EFI_SECURE_BOOT11  /* Are we in Secure Boot mode? 
*/
+
+enum efi_secureboot_mode {
+   efi_secureboot_mode_unset,
+   efi_secureboot_mode_unknown,
+   efi_secureboot_mode_disabled,
+   efi_secureboot_mode_enabled,
+};
 
 #ifdef CONFIG_EFI
 /*
@@ -1115,6 +1123,7 @@ static inline bool efi_enabled(int feature)
 extern void efi_reboot(enum reboot_mode reboot_mode, const char *__unused);
 
 extern bool efi_is_table_address(unsigned long phys_addr);
+extern void __init efi_set_secure_boot(enum efi_secureboot_mode mode);
 #else

[PATCH 30/30] efi: Lock down the kernel if booted in secure boot mode

[David Howells]

UEFI Secure Boot provides a mechanism for ensuring that the firmware will
only load signed bootloaders and kernels.  Certain use cases may also
require that all kernel modules also be signed.  Add a configuration option
that to lock down the kernel - which includes requiring validly signed
modules - if the kernel is secure-booted.

Signed-off-by: David Howells <dhowe...@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
cc: linux-efi@vger.kernel.org
---

 arch/x86/kernel/setup.c |6 --
 security/Kconfig|   14 ++
 security/lock_down.c|1 +
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 7c2162f9e769..4e38327efb2e 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -64,6 +64,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1039,6 +1040,9 @@ void __init setup_arch(char **cmdline_p)
if (efi_enabled(EFI_BOOT))
efi_init();
 
+   efi_set_secure_boot(boot_params.secure_boot);
+   init_lockdown();
+
dmi_scan_machine();
dmi_memdev_walk();
dmi_set_dump_stack_arch_desc();
@@ -1197,8 +1201,6 @@ void __init setup_arch(char **cmdline_p)
/* Allocate bigger log buffer */
setup_log_buf(1);
 
-   efi_set_secure_boot(boot_params.secure_boot);
-
reserve_initrd();
 
acpi_table_upgrade();
diff --git a/security/Kconfig b/security/Kconfig
index 1e997be94ba2..a4fa8b826039 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -222,6 +222,20 @@ config ALLOW_LOCKDOWN_LIFT_BY_SYSRQ
  Allow the lockdown on a kernel to be lifted, by pressing a SysRq key
  combination on a wired keyboard.
 
+config LOCK_DOWN_IN_EFI_SECURE_BOOT
+   bool "Lock down the kernel in EFI Secure Boot mode"
+   default n
+   select LOCK_DOWN_KERNEL
+   depends on EFI
+   help
+ UEFI Secure Boot provides a mechanism for ensuring that the firmware
+ will only load signed bootloaders and kernels.  Secure boot mode may
+ be determined from EFI variables provided by the system firmware if
+ not indicated by the boot parameters.
+
+ Enabling this option turns on results in kernel lockdown being
+ triggered if EFI Secure Boot is set.
+
 
 source security/selinux/Kconfig
 source security/smack/Kconfig
diff --git a/security/lock_down.c b/security/lock_down.c
index 2c6b00f0c229..527f7e51dc8d 100644
--- a/security/lock_down.c
+++ b/security/lock_down.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #ifdef CONFIG_ALLOW_LOCKDOWN_LIFT_BY_SYSRQ

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

From: Josh Boyer <jwbo...@fedoraproject.org>

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 <jwbo...@fedoraproject.org>
Signed-off-by: David Howells <dhowe...@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <j...@suse.com>
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 a5c36e9c56a6..f2eafefeec50 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");
 }
 
 /**

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 04/30] Enforce module signatures if the kernel is locked down

[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.

Signed-off-by: David Howells <dhowe...@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <j...@suse.com>
Reviewed-by: James Morris <james.l.mor...@oracle.com>
---

 kernel/module.c |   19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index de66ec825992..0ce29c8aa75a 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -64,6 +64,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "module-internal.h"
 
@@ -2757,7 +2758,8 @@ 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;
const unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
@@ -2781,13 +2783,16 @@ static int module_sig_check(struct load_info *info, int 
flags)
}
 
/* Not having a signature is only an error if we're strict. */
-   if (err == -ENOKEY && !sig_enforce)
+   if (err == -ENOKEY && !sig_enforce &&
+   (!can_do_ima_check || !is_ima_appraise_enabled()) &&
+   !kernel_is_locked_down("Loading of unsigned modules"))
err = 0;
 
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;
 }
@@ -3630,13 +3635,13 @@ 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;
char *after_dashes;
 
-   err = module_sig_check(info, flags);
+   err = module_sig_check(info, flags, can_do_ima_check);
if (err)
goto free_copy;
 
@@ -3830,7 +3835,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)
@@ -3857,7 +3862,7 @@ SYSCALL_DEFINE3(finit_module, int, fd, const char __user 
*, uargs, int, flags)
info.hdr = hdr;
info.len = size;
 
-   return load_module(, uargs, flags);
+   return load_module(, uargs, flags, true);
 }
 
 static inline int within(unsigned long addr, void *start, unsigned long size)

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

From: Kyle McMartin <k...@redhat.com>

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 <k...@redhat.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
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 |   10 +
 security/lock_down.c |   47 ++
 8 files changed, 86 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index a65cf544686a..863f77582c09 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -8,6 +8,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 443151de90c6..45a1f5460805 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -408,6 +408,7 @@ static int uinput_allocate_device(struct uinput_device 
*udev)
if (!udev->dev)
return -ENOMEM;
 
+   udev->dev->flags |= INPUTDEV_FLAGS_SYNTHETIC;
udev->dev->event = uinput_dev_event;
input_set_drvdata(udev->dev, udev);
 
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 3ffc1ce29023..8b766dbad6dd 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -481,6 +481,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 */
@@ -524,7 +525,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;
@@ -544,11 +545,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);
@@ -580,7 +585,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);
 
@@ -661,7 +666,7 @@ static void sysrq_do_reset(unsigned long _state)
 static void sysrq_handle_reset_request(struct sysrq_state *state)
 {
if (state->reset_requested)
-   __handle_sysrq(sysrq_xlate[KEY_B], false);
+   __handle_sysrq(sysrq_xlate[KEY_B], SYSRQ_FROM_KERNEL);
 
if (sysrq_reset_downtime_ms)
mod_timer(>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);
}
   

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

[David Howells]

Alexei Starovoitov  wrote:

> > TBH, I've no idea how bpf does anything, so I can't say whether this is
> > better, overkill or insufficient.
> 
> ok. To make it clear:
> Nacked-by: Alexei Starovoitov 
> For the current patch.
> Unnecessary checks for no good reason in performance critical
> functions are not acceptable.

They aren't unnecessary checks.

Can you please suggest if there's some way more suitable than just killing bpf
entirely?  I don't know the code, and I presume you do.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

Thiago Jung Bauermann  wrote:

> On non-x86 platforms (tested on powerpc) this fails to build with:
> 
> security/lock_down.c: In function ‘lockdown_lift_sysrq’:
> security/lock_down.c:100:40: error: ‘LOCKDOWN_LIFT_KEY’ undeclared (first use 
> in this function)
>lockdown_lift_sysrq_op.help_msg[5] = LOCKDOWN_LIFT_KEY;
> ^
> security/lock_down.c:100:40: note: each undeclared identifier is reported 
> only once for each function it appears in

I've added an arch dependency in the Kconfig file in my local branch.  I'll
try to get it pushed again.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

[David Howells]

Mimi Zohar  wrote:

> > Only validly signed device firmware may be loaded.
> 
> fw_get_filesystem_firmware() calls kernel_read_file_from_path() to
> read the firmware, which calls into the security hooks. Is there
> another place that validates the firmware signatures.  I'm not seeing
> which patch requires firmware to be signed?

Luis has a set of patches for this.  However, I'm not sure if that's going
anywhere at the moment.  Possibly I should remove this from the manpage for
the moment.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

Mimi Zohar  wrote:

> Right, it would never get here if the IMA signature verification
> fails.  If sig_enforce is not enabled, then it will also work.  So the
> only case is if sig_enforced is enabled and there is no key.
> 
> eg.
>          else if (can_do_ima_check && is_ima_appraise_enabled())
>                 err = 0;

I'm not sure where you want to put that, but I can't just do this:

/* Not having a signature is only an error if we're strict. */
if (err == -ENOKEY && !sig_enforce &&
(!can_do_ima_check || !is_ima_appraise_enabled()) &&
!kernel_is_locked_down("Loading of unsigned modules"))
err = 0;
else if (can_do_ima_check && is_ima_appraise_enabled())
err = 0;

because that'll print out a message in lockdown mode saying that you're not
allowed to do that and then maybe do it anyway.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

Mimi Zohar  wrote:

> By this point, IMA-appraisal has already verified the kernel module
> signature back in kernel_read_file_from_fd(), if it was required.
>  Having a key with which to verify the appended signature or requiring
> an appended signature, should not be required as well.

I guess I don't need to put in any support for IMA here, then, and you've
taken care of it in your patchset such that it won't actually go into
module_sig_check() in that case (or will at least return immediately).

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

[David Howells]

Hi Mimi,

I've adjusted the patch as below.

David
---
commit bf33218ad2bf04f1b92f5c32499ab906f107864c
Author: Chun-Yi Lee <joeyli.ker...@gmail.com>
Date:   Wed May 24 14:56:03 2017 +0100

kexec_file: Restrict at runtime if the kernel is locked down

When KEXEC_VERIFY_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.

This code was showed in Matthew's patch but not in git:
https://lkml.org/lkml/2015/3/13/778

Cc: Matthew Garrett <mj...@srcf.ucam.org>
Signed-off-by: Chun-Yi Lee <j...@suse.com>
    Signed-off-by: David Howells <dhowe...@redhat.com>
Reviewed-by: James Morris <james.l.mor...@oracle.com>
cc: ke...@lists.infradead.org

diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 9f48f4412297..3ba28fc3fab0 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -255,6 +255,14 @@ SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, 
initrd_fd,
if (!capable(CAP_SYS_BOOT) || kexec_load_disabled)
return -EPERM;
 
+   /* Don't permit images to be loaded into trusted kernels if we're not
+* going to verify the signature on them
+*/
+   if (!IS_ENABLED(CONFIG_KEXEC_VERIFY_SIG) &&
+   !is_ima_appraise_enabled() &&
+   kernel_is_locked_down("kexec of unsigned images"))
+   return -EPERM;
+
/* Make sure we have a legal set of flags */
if (flags != (flags & KEXEC_FILE_FLAGS))
return -EINVAL;
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

Hi Mimi,

I've altered this patch to allow for IMA appraisal on finit_module().  See the
attached.

David
---
commit c0d5336356004e7543314e388755a00e725521da
Author: David Howells <dhowe...@redhat.com>
Date:   Wed May 24 14:56:01 2017 +0100

Enforce module signatures if the kernel is locked down

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

Signed-off-by: David Howells <dhowe...@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <j...@suse.com>
Reviewed-by: James Morris <james.l.mor...@oracle.com>

diff --git a/kernel/module.c b/kernel/module.c
index de66ec825992..0ce29c8aa75a 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -64,6 +64,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "module-internal.h"
 
@@ -2757,7 +2758,8 @@ 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;
const unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
@@ -2781,13 +2783,16 @@ static int module_sig_check(struct load_info *info, int 
flags)
}
 
/* Not having a signature is only an error if we're strict. */
-   if (err == -ENOKEY && !sig_enforce)
+   if (err == -ENOKEY && !sig_enforce &&
+   (!can_do_ima_check || !is_ima_appraise_enabled()) &&
+   !kernel_is_locked_down("Loading of unsigned modules"))
err = 0;
 
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;
 }
@@ -3630,13 +3635,13 @@ 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;
char *after_dashes;
 
-   err = module_sig_check(info, flags);
+   err = module_sig_check(info, flags, can_do_ima_check);
if (err)
goto free_copy;
 
@@ -3830,7 +3835,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)
@@ -3857,7 +3862,7 @@ SYSCALL_DEFINE3(finit_module, int, fd, const char __user 
*, uargs, int, flags)
info.hdr = hdr;
info.len = size;
 
-   return load_module(, uargs, flags);
+   return load_module(, uargs, flags, true);
 }
 
 static inline int within(unsigned long addr, void *start, unsigned long size)
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

[David Howells]

Mimi Zohar  wrote:

> At some point, we'll want to also require the initramfs be signed as well.

That could be tricky.  In Fedora, at least, that's assembled on the fly to
include just the drivers you need to be able to mount your root fs and find
the rest of your modules.  (Unless you mean just for the installer)

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

Mimi Zohar  wrote:

> This kernel_is_locked_down() check is being called for both the
> original and new module_load syscalls.  We need to be able
> differentiate them.  This is fine for the original syscall, but for
> the new syscall we would need an additional IMA check -
> !is_ima_appraise_enabled().

IMA can only be used with finit_module()?

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

[David Howells]

Mimi Zohar  wrote:

> Huh?!  With the "secure_boot" policy enabled on the boot command line,
> IMA-appraisal would verify the kexec kernel image, firmware, kernel
> modules, and custom IMA policy signatures.

What happens if the "secure_boot" policy isn't enabled on the boot command
line?  Can you sum up both cases in a paragraph I can add to the patch
description?

> Other patches in this patch series need to be updated as well to check
> if IMA-appraisal is enabled.

Which exactly?  I've added your "!is_ima_appraise_enabled() &&" line to
kexec_file() and module_sig_check().  Anything else?

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

[David Howells]

Mimi Zohar  wrote:

> Yes, that works.  Thanks!  Remember is_ima_appraise_enabled() is
> dependent on the "ima: require secure_boot rules in lockdown mode"
> patch - http://kernsec.org/pipermail/linux-security-module-archive/201
> 7-October/003910.html.

What happens if the file in question is being accessed from a filesystem that
doesn't have xattrs and doesn't provide support for appraisal?  Is it rejected
outright or just permitted?

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] Kernel lockdown for secure boot

[David Howells]

Hi James,

Can you pull this patchset into security/next please?

It adds kernel lockdown support for EFI secure boot.  Note that it doesn't yet
cover:

bpf - No agreement as to how
ftrace  - Recently suggested, query sent to maintainer
perf- Not looked at yet.

and there are some changes recently proposed that make it work with IMA that
I'll pass on as a follow up when we've fully worked them out.

There's a manual page (kernel_lockdown.7) associated with this:

.\"
.\" Copyright (C) 2017 Red Hat, Inc. All Rights Reserved.
.\" Written by David Howells (dhowe...@redhat.com)
.\"
.\" %%%LICENSE_START(GPLv2+_SW_ONEPARA)
.\" This program is free software; you can redistribute it and/or
.\" modify it under the terms of the GNU General Public License
.\" as published by the Free Software Foundation; either version
.\" 2 of the License, or (at your option) any later version.
.\" %%%LICENSE_END
.\"
.TH "KERNEL LOCKDOWN" 7 2017-10-05 Linux "Linux Programmer's Manual"
.SH NAME
Kernel Lockdown \- Kernel image access prevention feature
.SH DESCRIPTION
The Kernel Lockdown feature is designed to prevent both direct and indirect
access to a running kernel image, attempting to protect against unauthorised
modification of the kernel image and to prevent access to security and
cryptographic data located in kernel memory, whilst still permitting driver
modules to be loaded.
.P
Lockdown is typically enabled during boot and may be terminated, if configured,
by typing a special key combination on a directly attached physical keyboard.
.P
If a prohibited or restricted feature is accessed or used, the kernel will emit
a message that looks like:
.P
.RS
Lockdown: X is restricted, see man kernel_lockdown.7
.RE
.P
where X indicates what is restricted.
.P
On an EFI-enabled x86 or arm64 machine, lockdown will be automatically enabled
if the system boots in EFI Secure Boot mode.
.P
If the kernel is appropriately configured, lockdown may be lifted by typing the
appropriate sequence on a directly attached physical keyboard.  For x86
machines, this is
.IR SysRq+x .
.\"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
.SH COVERAGE
When lockdown is in effect, a number of things are disabled or restricted in
use.  This includes special device files and kernel services that allow direct
access of the kernel image:
.P
.RS
/dev/mem
.br
/dev/kmem
.br
/dev/kcore
.br
/dev/ioports
.RE
.P
and the ability to directly configure and control devices, so as to prevent the
use of a device to access or modify a kernel image:
.P
.RS
The use of module parameters that directly specify hardware parameters to
drivers through the kernel command line or when loading a module.
.P
The use of direct PCI BAR access.
.P
The use of the ioperm and iopl instructions on x86.
.P
The use of the KD*IO console ioctls.
.P
The use of the TIOCSSERIAL serial ioctl.
.P
The alteration of MSR registers on x86.
.P
The replacement of the PCMCIA CIS.
.P
The overriding of ACPI tables.
.P
The use of ACPI error injection.
.P
The specification of the ACPI RDSP address.
.P
The use of ACPI custom methods.
.RE
.P
The following facilities are restricted:
.P
.RS
Only validly signed modules may be loaded.
.P
Only validly signed binaries may be kexec'd.
.P
Only validly signed device firmware may be loaded.
.P
Unencrypted hibernation/suspend to swap are disallowed as the kernel image is
saved to a medium that can then be accessed.
.P
Use of debugfs is not permitted as this allows a whole range of actions
including direct configuration of, access to and driving of hardware.
.RE
.\"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
.SH SEE ALSO
.ad l
.nh


David
---
The following changes since commit 25eabb13c7d67ae32298015c5e28d00f604f412c:

  Merge tag 'v4.14-rc2' into next-general (2017-09-24 22:41:55 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git 
tags/lockdown-20171026

for you to fetch changes up to 163d6a313399a4d50c5c7e42e3dd642ca8d495d7:

  efi: Lock down the kernel if booted in secure boot mode (2017-10-26 16:03:19 
+0100)

-

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

[David Howells]

joeyli  wrote:

> + if (!IS_ENABLED(CONFIG_KEXEC_VERIFY_SIG) &&
> + !is_ima_appraise_enabled() &&
> + kernel_is_locked_down("kexec of unsigned images"))

This doesn't seem right.  It seems that you can then kexec unsigned images
into a locked-down kernel if IMA appraise is enabled.

I think the commit message needs expansion as to why it's okay.  Can you also
do it as an additional patch rather than altering the original IMA-less patch
7?

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

[David Howells]

Mimi Zohar  wrote:

> The patch title and description needs to be updated to refer to
> lockdown, not securelevel.

Fixed, thanks.

> An additional patch could force these rules to be added to the custom
> policy, if lockdown is enabled.

I'll have a look at your patch, though at this point I'm leaning towards
passing the current series to James for security/next and then passing your
patch along afterwards, if that's okay with you.  It should still get in the
next merge window if that's the case.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down

[David Howells]

Ethan Zhao  wrote:

> May I ask a question here -- Is it intentionally enabling the
> read-only mode, so userspace
> tools like dmidecode could work with kernel_is_locked_down ?  while it
> was impossible to work
> with the attached patch applied. Is it a security policy change with
> secure boot ?

I removed readability on /dev/mem, /dev/kmem and /proc/kcore so that userspace
can't use this to gain access to cryptographic material in use by the kernel.

Readability was removed on /dev/port because reading from an I/O port register
might have a side effect or might allow you to snoop h/w interactions, such as
keyboard input.

I can provide an additional config option to allow /dev/mem and similar to
remain readable - but it needs to be a temporary affair.

I can also log accesses to these interfaces so that we can find out what
breaks and fix it.

Note that dmidecode doesn't necessarily use /dev/mem:

[root@andromeda ~]# strace -f -eopen dmidecode  >/dev/null
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/sys/firmware/dmi/tables/smbios_entry_point", O_RDONLY) = 3
open("/sys/firmware/dmi/tables/DMI", O_RDONLY) = 3
+++ exited with 0 +++

Indeed, my Fedora 24 test system boots without a /dev/mem file being present
(I'm not sure *why* /dev/mem isn't present, but I hadn't noticed till now).

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 26/27] efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode

[David Howells]

James Morris  wrote:

> > +   default:
> > +   pr_info("Secure boot could not be determined\n");
> 
> Perhaps make this pr_warning and include the unknown mode value?

Done.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

j...@suse.com wrote:

> hm... patch 4 only prevents write_mem() but not read_mem().
> Or I missed anything?

Actually, yes, as it happens, patch 11 prevents you from even opening /dev/mem
and /dev/kmem by locking down open of /dev/port.  So I've moved this bit to
patch 4, simplified and posted a new variant for patch 4.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

Alan Cox  wrote:

> There are a load of standard tools that use this so I think you are going
> to need a whitelist. Can you at least log *which* MSR in the failing case
> so a whitelist can be built over time ?

Will the attached change work for you?

David
---
diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index a05a97863286..f18cadbc31ce 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -84,8 +84,10 @@ 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"))
+   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 +137,7 @@ static long msr_ioctl(struct file *file, unsigned int ioc, 
unsigned long arg)
break;
}
if (kernel_is_locked_down("Direct MSR access")) {
+   pr_info("Direct access to MSR %x\n", reg[1]); /* 
Display %ecx */
err = -EPERM;
break;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down

[David Howells]

I think I should replace this patch with the attached.  This will prevent
/dev/mem, /dev/kmem and /dev/port from being *opened*, and thereby preventing
read, write and ioctl.

David
---
commit e68daa2256986932b9a7d6709cf9e24b30d93583
Author: Matthew Garrett <matthew.garr...@nebula.com>
Date:   Wed May 24 14:56:02 2017 +0100

Restrict /dev/{mem,kmem,port} when the kernel is locked down

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 <matthew.garr...@nebula.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <j...@suse.com>

diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 593a8818aca9..0ce5ac0a5c6b 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -762,6 +762,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;
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

Alan Cox  wrote:

> There are a load of standard tools that use this so I think you are going
> to need a whitelist. Can you at least log *which* MSR in the failing case
> so a whitelist can be built over time ?

Probably.  Is it just the file position for msr_write()?  Should the register
number increment with the copy loop?

What about for the X86_IOC_WRMSR_REGS ioctl?  What's the reg number there?

And do you know where wrmsr_safe_regs() might be found?  I can see things
using it and exporting it, but no implementation, so I'm guessing it's
macroised somewhere.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

j...@suse.com wrote:

> I think that we don't need to lock down sys_bpf() now because
> we didn't lock down other interfaces for reading arbitrary
> address like /dev/mem and /dev/kmem.

Ummm...  See patch 4.  You even gave me a Reviewed-by for it ;-)

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

Hi Joey,

Should I just lock down sys_bpf() entirely for now?  We can always free it up
somewhat later.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

Alexei Starovoitov  wrote:

> > @@ -65,6 +65,11 @@ BPF_CALL_3(bpf_probe_read, void *, dst, u32, size, const 
> > void *, unsafe_ptr)
> >  {
> > int ret;
> >  
> > +   if (kernel_is_locked_down("BPF")) {
> > +   memset(dst, 0, size);
> > +   return -EPERM;
> > +   }
>
> That doesn't help the lockdown purpose.
> If you don't trust the root the only way to prevent bpf read
> memory is to disable the whole thing.
> Have a single check in sys_bpf() to disallow everything if 
> kernel_is_locked_down()
> and don't add overhead to critical path like bpf_probe_read().

TBH, I've no idea how bpf does anything, so I can't say whether this is
better, overkill or insufficient.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

Randy Dunlap  wrote:

> > +config ALLOW_LOCKDOWN_LIFT
> > +   bool
> > +   help
> > + Allow the lockdown on a kernel to be lifted, thereby restoring the
> > + ability of userspace to access the kernel image (eg. by SysRq+x under
> 
> how about:on
> 
> > + x86).

I'll just get rid of this config option, I think - it doesn't make anything
available outside of lock_down.c.

> > +#ifdef CONFIG_ALLOW_LOCKDOWN_LIFT_BY_KEY
> 
> is that the same as: CONFIG_ALLOW_LOCKDOWN_LIFT_BY_SYSRQ ?
> tested?

My test machine doesn't have a physical keyboard attached, but you're right.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[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 <dhowe...@redhat.com>
---

 include/linux/kernel.h   |   17 +
 include/linux/security.h |8 ++
 security/Kconfig |8 ++
 security/Makefile|3 ++
 security/lock_down.c |   60 ++
 5 files changed, 96 insertions(+)
 create mode 100644 security/lock_down.c

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 0ad4c3044cf9..362da2e4bf53 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -287,6 +287,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 ce6265960d6c..f9a894b42d4c 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -1753,5 +1753,13 @@ static inline void free_secdata(void *secdata)
 { }
 #endif /* CONFIG_SECURITY */
 
+#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 e8e449444e65..8e01fd59ae7e 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -205,6 +205,14 @@ 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 under certain circumstances, for
+ instance if UEFI secure boot is enabled.  Locking down the kernel
+ turns off various features that might otherwise allow access to the
+ kernel image (eg. setting MSR registers).
+
 source security/selinux/Kconfig
 source security/smack/Kconfig
 source security/tomoyo/Kconfig
diff --git a/security/Makefile b/security/Makefile
index f2d71cdb8e19..8c4a43e3d4e0 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -29,3 +29,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 ..d8595c0e6673
--- /dev/null
+++ b/security/lock_down.c
@@ -0,0 +1,60 @@
+/* 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 line");
+   return 0;
+}
+
+early_param("lockdown", lockdown_param);
+
+/*
+ * Lock the kernel down from very early in the arch setup.  This must happen
+ * prior to things like ACPI being initialised.
+ */
+void __init init_lockdown(void)
+{
+#ifdef CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT
+   if (efi_enabled(EFI_SECURE_

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

[David Howells]

From: Kyle McMartin <k...@redhat.com>

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_64 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.

Signed-off-by: Kyle McMartin <k...@redhat.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
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 |   15 +
 security/lock_down.c |   48 ++
 8 files changed, 92 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index a65cf544686a..863f77582c09 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -8,6 +8,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 443151de90c6..45a1f5460805 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -408,6 +408,7 @@ static int uinput_allocate_device(struct uinput_device 
*udev)
if (!udev->dev)
return -ENOMEM;
 
+   udev->dev->flags |= INPUTDEV_FLAGS_SYNTHETIC;
udev->dev->event = uinput_dev_event;
input_set_drvdata(udev->dev, udev);
 
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 3ffc1ce29023..8b766dbad6dd 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -481,6 +481,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 */
@@ -524,7 +525,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;
@@ -544,11 +545,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);
@@ -580,7 +585,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);
 
@@ -661,7 +666,7 @@ static void sysrq_do_reset(unsigned long _state)
 static void sysrq_handle_reset_request(struct sysrq_state *state)
 {
if (state->reset_requested)
-   __handle_sysrq(sysrq_xlate[KEY_B], false);
+   __handle_sysrq(sysrq_xlate[KEY_B], SYSRQ_FROM_KERNEL);
 
if (sysrq_reset_downtime_ms)
mod_timer(>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;
}
@@ -1097,7 +1104,7 @@ static ssize_t write_sysrq_trigger(struct file *file, 
const char __user *buf,
 
if (get_user(c,

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

[David Howells]

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

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

 kernel/module.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/module.c b/kernel/module.c
index de66ec825992..3d9a3270c179 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2781,7 +2781,8 @@ static int module_sig_check(struct load_info *info, int 
flags)
}
 
/* Not having a signature is only an error if we're strict. */
-   if (err == -ENOKEY && !sig_enforce)
+   if (err == -ENOKEY && !sig_enforce &&
+   !kernel_is_locked_down("Loading of unsigned modules"))
err = 0;
 
return err;

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down

[David Howells]

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

Allowing users to write to address space makes it possible for the kernel to
be subverted, avoiding module loading restrictions.  Prevent this when the
kernel has been locked down.

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

 drivers/char/mem.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 593a8818aca9..b7c36898b689 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -179,6 +179,9 @@ static ssize_t write_mem(struct file *file, const char 
__user *buf,
if (p != *ppos)
return -EFBIG;
 
+   if (kernel_is_locked_down("/dev/mem"))
+   return -EPERM;
+
if (!valid_phys_addr_range(p, count))
return -EFAULT;
 
@@ -540,6 +543,9 @@ static ssize_t write_kmem(struct file *file, const char 
__user *buf,
char *kbuf; /* k-addr because vwrite() takes vmlist_lock rwlock */
int err = 0;
 
+   if (kernel_is_locked_down("/dev/kmem"))
+   return -EPERM;
+
if (p < (unsigned long) high_memory) {
unsigned long to_write = min_t(unsigned long, count,
   (unsigned long)high_memory - p);

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

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

kexec permits the loading and execution of arbitrary code in ring 0, which
is something that lock-down is meant to prevent. It makes sense to disable
kexec in this situation.

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

Signed-off-by: Matthew Garrett <matthew.garr...@nebula.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
Acked-by: Dave Young <dyo...@redhat.com>
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 e62ec4dc6620..7dadfed9b676 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -202,6 +202,13 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned 
long, nr_segments,
return -EPERM;
 
/*
+* kexec can be used to circumvent module loading restrictions, so
+* prevent loading in that case
+*/
+   if (kernel_is_locked_down("kexec of unsigned images"))
+   return -EPERM;
+
+   /*
 * Verify we have a legal set of flags
 * This leaves us room for future extensions.
 */

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

From: Dave Young <dyo...@redhat.com>

Kexec reboot in case secure boot being enabled does not keep the secure
boot mode in new kernel, so later one can load unsigned kernel via legacy
kexec_load.  In this state, the system is missing the protections provided
by secure boot.

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

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

Signed-off-by: Dave Young <dyo...@redhat.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
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 fb095ba0c02f..7d0fac5bcbbe 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;

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

From: Matthew Garrett <mj...@srcf.ucam.org>

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 <mj...@srcf.ucam.org>
Signed-off-by: David Howells <dhowe...@redhat.com>
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 22df9f7ff672..678ade9decfe 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)) {

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

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

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

Signed-off-by: Matthew Garrett <matthew.garr...@nebula.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
Acked-by: Kees Cook <keesc...@chromium.org>
Reviewed-by: Thomas Gleixner <t...@linutronix.de>
cc: x...@kernel.org
---

 arch/x86/kernel/msr.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index ef688804f80d..a05a97863286 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -84,6 +84,9 @@ 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"))
+   return -EPERM;
+
if (count % 8)
return -EINVAL; /* Invalid chunk size */
 
@@ -131,6 +134,10 @@ static long msr_ioctl(struct file *file, unsigned int ioc, 
unsigned long arg)
err = -EBADF;
break;
}
+   if (kernel_is_locked_down("Direct MSR access")) {
+   err = -EPERM;
+   break;
+   }
if (copy_from_user(, uregs, sizeof regs)) {
err = -EFAULT;
break;

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

From: Josh Boyer <jwbo...@fedoraproject.org>

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 <jwbo...@fedoraproject.org>
Signed-off-by: David Howells <dhowe...@redhat.com>
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 a5c36e9c56a6..f2eafefeec50 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");
 }
 
 /**

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

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

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

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

Signed-off-by: Matthew Garrett <matthew.garr...@nebula.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
Reviewed-by: Thomas Gleixner <t...@linutronix.de>
cc: x...@kernel.org
---

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

diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index 9c3cf0944bce..2c0f058651c5 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -30,7 +30,8 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned long 
num, int turn_on)
 
if ((from + num <= from) || (from + num > IO_BITMAP_BITS))
return -EINVAL;
-   if (turn_on && !capable(CAP_SYS_RAWIO))
+   if (turn_on && (!capable(CAP_SYS_RAWIO) ||
+   kernel_is_locked_down("ioperm")))
return -EPERM;
 
/*
@@ -120,7 +121,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) |
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index b7c36898b689..0875b3d47773 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -768,6 +768,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("Direct ioport access"))
+   return -EPERM;
return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
 }
 

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 13/27] asus-wmi: Restrict debugfs interface when the kernel is locked down

[David Howells]

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

We have no way of validating what all of the Asus WMI methods do on a given
machine - and there's a risk that some will allow hardware state to be
manipulated in such a way that arbitrary code can be executed in the
kernel, circumventing module loading restrictions.  Prevent that if the
kernel is locked down.

Signed-off-by: Matthew Garrett <matthew.garr...@nebula.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
cc: acpi4asus-u...@lists.sourceforge.net
cc: platform-driver-...@vger.kernel.org
---

 drivers/platform/x86/asus-wmi.c |9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 48e1541dc8d4..ef5587469337 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1905,6 +1905,9 @@ static int show_dsts(struct seq_file *m, void *data)
int err;
u32 retval = -1;
 
+   if (kernel_is_locked_down("Asus WMI"))
+   return -EPERM;
+
err = asus_wmi_get_devstate(asus, asus->debug.dev_id, );
 
if (err < 0)
@@ -1921,6 +1924,9 @@ static int show_devs(struct seq_file *m, void *data)
int err;
u32 retval = -1;
 
+   if (kernel_is_locked_down("Asus WMI"))
+   return -EPERM;
+
err = asus_wmi_set_devstate(asus->debug.dev_id, asus->debug.ctrl_param,
);
 
@@ -1945,6 +1951,9 @@ static int show_call(struct seq_file *m, void *data)
union acpi_object *obj;
acpi_status status;
 
+   if (kernel_is_locked_down("Asus WMI"))
+   return -EPERM;
+
status = wmi_evaluate_method(ASUS_WMI_MGMT_GUID,
 0, asus->debug.method_id,
 , );

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

From: Josh Boyer <jwbo...@redhat.com>

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 <jwbo...@redhat.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
cc: Dave Young <dyo...@redhat.com>
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 db78d353bab1..36c6527c1b0a 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -192,7 +192,7 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
acpi_physical_address pa = 0;
 
 #ifdef CONFIG_KEXEC
-   if (acpi_rsdp)
+   if (acpi_rsdp && !kernel_is_locked_down("ACPI RSDP specification"))
return acpi_rsdp;
 #endif
 

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

From: Linn Crosetto <l...@hpe.com>

>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 <l...@hpe.com>
Signed-off-by: David Howells <dhowe...@redhat.com>
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 80ce2a7d224b..5cc13c42daf9 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -526,6 +526,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);

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html