* Re: [PATCH 24/24] debugfs: Restrict debugfs when the kernel is locked down
From: Eric W. Biederman @ 2018-04-11 18:50 UTC (permalink / raw)
To: David Howells
Cc: torvalds, linux-man, linux-api, jmorris, linux-kernel,
linux-security-module
In-Reply-To: <152346403637.4030.15247096217928429102.stgit@warthog.procyon.org.uk>
David Howells <dhowells@redhat.com> writes:
> Disallow opening of debugfs files that might be used to muck around when
> the kernel is locked down as various drivers give raw access to hardware
> through debugfs. Given the effort of auditing all 2000 or so files and
> manually fixing each one as necessary, I've chosen to apply a heuristic
> instead. The following changes are made:
>
> (1) chmod and chown are disallowed on debugfs objects (though the root dir
> can be modified by mount and remount, but I'm not worried about that).
>
> (2) When the kernel is locked down, only files with the following criteria
> are permitted to be opened:
>
> - The file must have mode 00444
> - The file must not have ioctl methods
> - The file must not have mmap
>
> (3) When the kernel is locked down, files may only be opened for reading.
>
> Normal device interaction should be done through configfs, sysfs or a
> miscdev, not debugfs.
> Note that this makes it unnecessary to specifically lock down show_dsts(),
> show_devs() and show_call() in the asus-wmi driver.
>
> I would actually prefer to lock down all files by default and have the
> the files unlocked by the creator. This is tricky to manage correctly,
> though, as there are 19 creation functions and ~1600 call sites (some of
> them in loops scanning tables).
Why is mounting debugfs allowed at all? Last I checked (it has been a while)
the code quality of debugfs was fine for debugging but debugfs was not
safe to mount on a production system.
Maybe the code quality is better now but for a filesystem that is
not supposed to be needed for developers letting us mount debugfs
seems odd.
Eric
^ permalink raw reply
* Re: [PATCH 01/24] Add the ability to lock down access to the running kernel image
From: Miguel Ojeda @ 2018-04-11 18:50 UTC (permalink / raw)
To: Randy Dunlap
Cc: David Howells, Linus Torvalds, linux-man, linux-api, jmorris,
linux-kernel, linux-security-module
In-Reply-To: <6a37b428-d9fb-12d5-8d36-8a032984af8c@infradead.org>
On Wed, Apr 11, 2018 at 7:37 PM, Randy Dunlap <rdunlap@infradead.org> wrote:
> On 04/11/2018 09:24 AM, David Howells wrote:
>
>> diff --git a/security/lock_down.c b/security/lock_down.c
>> new file mode 100644
>> index 000000000000..f35ffdd096ad
>> --- /dev/null
>> +++ b/security/lock_down.c
>> @@ -0,0 +1,65 @@
>> +/* Lock down the kernel
>> + *
>> + * Copyright (C) 2016 Red Hat, Inc. All Rights Reserved.
>> + * Written by David Howells (dhowells@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.
>
> fsf.org spells that Licence word as License. :)
Given this is a new file, simply use the SPF identifier on top.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH 01/24] Add the ability to lock down access to the running kernel image
From: Justin Forbes @ 2018-04-11 18:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Howells, linux-man, Linux API, James Morris,
Linux Kernel Mailing List, LSM List
In-Reply-To: <CA+55aFzPo-dip8dgyo0U+g5qai9SAJU+D1c+AFJ0zV9_PBAB8Q@mail.gmail.com>
On Wed, Apr 11, 2018 at 1:09 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Apr 11, 2018 at 9:24 AM, David Howells <dhowells@redhat.com> wrote:
>> Provide a single call to allow kernel code to determine whether the system
>> should be locked down, thereby disallowing various accesses that might
>> allow the running kernel image to be changed, including:
>>
>> - /dev/mem and similar
>> - Loading of unauthorised modules
>> - Fiddling with MSR registers
>> - Suspend to disk managed by the kernel
>> - Use of device DMA
>
> So what I stlll absolutely detest about this series is that I think
> many of these things should simply be done as separate config options.
>
> For example, if the distro is sure that it doesn't need /dev/mem, then
> why the hell is this tied to "lockdown" that then may have to be
> disabled because *other* changes may not be acceptable (eg people may
> need that device DMA, or whatever).
>
> If that /dev/mem access prevention was just instead done as an even
> stricter mode of the existing CONFIG_STRICT_DEVMEM, it could just be
> enabled unconditionally.
>
> So none of these patches raise my hackles per se. But what continues
> to makes me very very uncomfortable is how this is all tied together.
>
> Why is this one magical mode that then - because it has such a big
> impact - has to be enabled/disabled as a single magical mode and with
> very odd rules?
>
> I think a lot of people would be happier if this wasn't so incestuous
> and mixing together independent things under one name, and one flag.
>
> I think a lot of the secure boot problems were exacerbated by that mixup.
>
> So I would seriously ask that the distros that have been using these
> patches look at which parts of lockdown they could make unconditional
> (because it doesn't break machines), and which ones need that escape
> clause.
>
Optionally, it might make sense to add separate config options for
each of these pieces which can be unconditionally enabled, and a
separate option for secure boot which selects all of them? As much as
I hate select, it might make sense here. Of course the flip side to
that, is users no longer have one big switch "turn off secure boot"
which turns it all off in case of trouble.
Justin
^ permalink raw reply
* Re: [PATCH 01/24] Add the ability to lock down access to the running kernel image
From: Linus Torvalds @ 2018-04-11 18:09 UTC (permalink / raw)
To: David Howells
Cc: linux-man, Linux API, James Morris, Linux Kernel Mailing List,
LSM List
In-Reply-To: <152346388583.4030.15146667041427303547.stgit@warthog.procyon.org.uk>
On Wed, Apr 11, 2018 at 9:24 AM, David Howells <dhowells@redhat.com> wrote:
> Provide a single call to allow kernel code to determine whether the system
> should be locked down, thereby disallowing various accesses that might
> allow the running kernel image to be changed, including:
>
> - /dev/mem and similar
> - Loading of unauthorised modules
> - Fiddling with MSR registers
> - Suspend to disk managed by the kernel
> - Use of device DMA
So what I stlll absolutely detest about this series is that I think
many of these things should simply be done as separate config options.
For example, if the distro is sure that it doesn't need /dev/mem, then
why the hell is this tied to "lockdown" that then may have to be
disabled because *other* changes may not be acceptable (eg people may
need that device DMA, or whatever).
If that /dev/mem access prevention was just instead done as an even
stricter mode of the existing CONFIG_STRICT_DEVMEM, it could just be
enabled unconditionally.
So none of these patches raise my hackles per se. But what continues
to makes me very very uncomfortable is how this is all tied together.
Why is this one magical mode that then - because it has such a big
impact - has to be enabled/disabled as a single magical mode and with
very odd rules?
I think a lot of people would be happier if this wasn't so incestuous
and mixing together independent things under one name, and one flag.
I think a lot of the secure boot problems were exacerbated by that mixup.
So I would seriously ask that the distros that have been using these
patches look at which parts of lockdown they could make unconditional
(because it doesn't break machines), and which ones need that escape
clause.
Linus
^ permalink raw reply
* Re: [RFC bpf-next v2 7/8] bpf: add documentation for eBPF helpers (51-57)
From: Quentin Monnet @ 2018-04-11 18:01 UTC (permalink / raw)
To: Yonghong Song, daniel, ast
Cc: netdev, oss-drivers, linux-doc, linux-man, Lawrence Brakmo,
Josef Bacik, Andrey Ignatov
In-Reply-To: <7e388b10-ccea-a2b0-e776-5420c8e7f521@netronome.com>
2018-04-11 16:44 UTC+0100 ~ Quentin Monnet <quentin.monnet@netronome.com>
> 2018-04-10 09:58 UTC-0700 ~ Yonghong Song <yhs@fb.com>
>> On 4/10/18 7:41 AM, Quentin Monnet wrote:
>>> Add documentation for eBPF helper functions to bpf.h user header file.
>>> This documentation can be parsed with the Python script provided in
>>> another commit of the patch series, in order to provide a RST document
>>> that can later be converted into a man page.
>>>
>>> The objective is to make the documentation easily understandable and
>>> accessible to all eBPF developers, including beginners.
>>>
>>> This patch contains descriptions for the following helper functions:
>>>
>>> Helpers from Lawrence:
>>> - bpf_setsockopt()
>>> - bpf_getsockopt()
>>> - bpf_sock_ops_cb_flags_set()
>>>
>>> Helpers from Yonghong:
>>> - bpf_perf_event_read_value()
>>> - bpf_perf_prog_read_value()
>>>
>>> Helper from Josef:
>>> - bpf_override_return()
>>>
>>> Helper from Andrey:
>>> - bpf_bind()
>>>
>>> Cc: Lawrence Brakmo <brakmo@fb.com>
>>> Cc: Yonghong Song <yhs@fb.com>
>>> Cc: Josef Bacik <jbacik@fb.com>
>>> Cc: Andrey Ignatov <rdna@fb.com>
>>> Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
>>> ---
> [...]
>
> Thanks Yonghong for the review!
>
> I have a favor to ask of you. I got a bounce for Kaixu Xia's email
> address, and I don't know what alternative email address I could use. I
> CC-ed to have a review for helper bpf_perf_event_read() (in patch 6 of
> this series), which is rather close to bpf_perf_event_read_value().
> Would you mind having a look at that one too, please? The description is
> not long.
Well I read again the description I wrote, and actually the one for
bpf_perf_evnet_read() is nearly a subset of the one for
perf_event_read_value(). So the same comments that you raised earlier
apply, there's probably nothing more to review. But if you notice that
some important info is missing for bpf_perf_event_read(), I'm interested
too!
Quentin
^ permalink raw reply
* Re: [PATCH 01/24] Add the ability to lock down access to the running kernel image
From: David Howells @ 2018-04-11 17:49 UTC (permalink / raw)
To: Randy Dunlap
Cc: dhowells, torvalds, linux-man, linux-api, jmorris, linux-kernel,
linux-security-module
In-Reply-To: <6a37b428-d9fb-12d5-8d36-8a032984af8c@infradead.org>
Randy Dunlap <rdunlap@infradead.org> wrote:
> > + drivers from functioning because allowing manual configuration of
> > + hardware parameters is forbidden, lest a device be used to access the
> > + kernel by DMA. This mostly applies to ISA devices.
>
> Is DMA from non-ISA devices OK, or did I miss seeing that patch?
The issue is where you can directly command a device to do DMA, possibly by
using the wrong driver. Ask Alan Cox.
David
^ permalink raw reply
* Re: [PATCH 01/24] Add the ability to lock down access to the running kernel image
From: Randy Dunlap @ 2018-04-11 17:37 UTC (permalink / raw)
To: David Howells, torvalds
Cc: linux-man, linux-api, jmorris, linux-kernel,
linux-security-module
In-Reply-To: <152346388583.4030.15146667041427303547.stgit@warthog.procyon.org.uk>
On 04/11/2018 09:24 AM, David Howells wrote:
> ---
>
> arch/x86/kernel/setup.c | 2 +
> include/linux/kernel.h | 32 +++++++++++++++++++++++
> security/Kconfig | 23 ++++++++++++++++-
> security/Makefile | 3 ++
> security/lock_down.c | 65 +++++++++++++++++++++++++++++++++++++++++++++++
> 5 files changed, 124 insertions(+), 1 deletion(-)
> create mode 100644 security/lock_down.c
> diff --git a/security/Kconfig b/security/Kconfig
> index c4302067a3ad..a68e5bdebad5 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -231,6 +231,28 @@ 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. Locking down the kernel turns
> + off various features that might otherwise allow access to the kernel
s/turns off/disables/
> + image (eg. setting MSR registers).
e.g.
> +
> + Note, however, that locking down your kernel will prevent some
the kernel
a kernel
> + drivers from functioning because allowing manual configuration of
> + hardware parameters is forbidden, lest a device be used to access the
> + kernel by DMA. This mostly applies to ISA devices.
Is DMA from non-ISA devices OK, or did I miss seeing that patch?
> + The kernel lockdown can be triggered by adding lockdown=1 to the
> + kernel command line.
> diff --git a/security/lock_down.c b/security/lock_down.c
> new file mode 100644
> index 000000000000..f35ffdd096ad
> --- /dev/null
> +++ b/security/lock_down.c
> @@ -0,0 +1,65 @@
> +/* Lock down the kernel
> + *
> + * Copyright (C) 2016 Red Hat, Inc. All Rights Reserved.
> + * Written by David Howells (dhowells@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.
fsf.org spells that Licence word as License. :)
> + */
--
~Randy
^ permalink raw reply
* Re: [PATCH 24/24] debugfs: Restrict debugfs when the kernel is locked down
From: Randy Dunlap @ 2018-04-11 17:26 UTC (permalink / raw)
To: David Howells, torvalds
Cc: linux-man, linux-api, jmorris, linux-kernel,
linux-security-module
In-Reply-To: <152346403637.4030.15247096217928429102.stgit@warthog.procyon.org.uk>
On 04/11/2018 09:27 AM, David Howells wrote:
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Andy Shevchenko <andy.shevchenko@gmail.com>
> cc: acpi4asus-user@lists.sourceforge.net
> cc: platform-driver-x86@vger.kernel.org
> cc: Matthew Garrett <mjg59@srcf.ucam.org>
> cc: Thomas Gleixner <tglx@linutronix.de>
> ---
meta-comment:
I have been dinged for not spelling "cc:" as "Cc:". I really think that
either way should be acceptable.
--
~Randy
^ permalink raw reply
* Re: [PATCH 18/24] Lock down module params that specify hardware parameters (eg. ioport)
From: Randy Dunlap @ 2018-04-11 17:22 UTC (permalink / raw)
To: David Howells, torvalds
Cc: linux-man, linux-api, jmorris, linux-kernel,
linux-security-module
In-Reply-To: <152346399627.4030.8043878470312297727.stgit@warthog.procyon.org.uk>
On 04/11/2018 09:26 AM, David Howells wrote:
> 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 <gnomes@lxorguk.ukuu.org.uk>
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
>
> kernel/params.c | 26 +++++++++++++++++++++-----
> 1 file changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/params.c b/kernel/params.c
> index cc9108c2a1fd..2c08c4aa376b 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"))
s/dma/DMA/
Other patches use PCI instead of pci, CIS instead of cis, MMIO instead of mmio,
BPF instead of bpf, MSR instead of msr, etc...
> + return false;
> + return true;
> }
>
> static int parse_one(char *param,
--
~Randy
^ permalink raw reply
* Re: [PATCH 02/24] Add a SysRq option to lift kernel lockdown
From: Jann Horn @ 2018-04-11 17:05 UTC (permalink / raw)
To: David Howells
Cc: Linus Torvalds, linux-man, Linux API, James Morris, kernel list,
linux-security-module
In-Reply-To: <152346389240.4030.11187964053014260180.stgit@warthog.procyon.org.uk>
On Wed, Apr 11, 2018 at 6:24 PM, David Howells <dhowells@redhat.com> wrote:
> From: Kyle McMartin <kyle@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.
In the current form, this is probably incompatible with USB/IP (which
Debian seems to be shipping as a module by default), right? And
perhaps also with dummy_hcd (if I understand correctly what it's
doing)?
^ permalink raw reply
* Re: [PATCH 01/24] Add the ability to lock down access to the running kernel image
From: Jann Horn @ 2018-04-11 16:44 UTC (permalink / raw)
To: David Howells
Cc: Linus Torvalds, linux-man, Linux API, James Morris, kernel list,
linux-security-module
In-Reply-To: <152346388583.4030.15146667041427303547.stgit@warthog.procyon.org.uk>
On Wed, Apr 11, 2018 at 6:24 PM, David Howells <dhowells@redhat.com> wrote:
> Provide a single call to allow kernel code to determine whether the system
> should be locked down, thereby disallowing various accesses that might
> allow the running kernel image to be changed, including:
>
> - /dev/mem and similar
> - Loading of unauthorised modules
> - Fiddling with MSR registers
> - Suspend to disk managed by the kernel
> - Use of device DMA
>
> Two kernel configuration options are provided:
>
> (*) CONFIG_LOCK_DOWN_KERNEL
>
> This makes lockdown available and applies it to all the points that
> need to be locked down if the mode is set. Lockdown mode can be
> enabled by providing:
>
> lockdown=1
>
> on the command line.
>
> (*) CONFIG_LOCK_DOWN_MANDATORY
>
> This forces lockdown on at compile time, overriding the command line
> option.
>
> init_lockdown() is used as a hook from which lockdown can be managed in
> future. It has to be called from arch setup code before things like ACPI
> are enabled.
>
> Note that, with the other changes in this series, if lockdown mode is
> enabled, the kernel will not be able to use certain drivers as the ability
> to manually configure hardware parameters would then be prohibited. This
> primarily applies to ISA hardware devices.
>
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
[...]
> diff --git a/security/lock_down.c b/security/lock_down.c
> new file mode 100644
> index 000000000000..f35ffdd096ad
> --- /dev/null
> +++ b/security/lock_down.c
[...]
> +/*
> + * Lock the kernel down from very early in the arch setup. This must happen
> + * prior to things like ACPI being initialised.
> + */
Pedantic nit: I think this comment is wrong now? This function
actually just prints stuff.
> +void __init init_lockdown(void)
> +{
> +#ifdef CONFIG_LOCK_DOWN_MANDATORY
> + pr_notice("Kernel is locked down from config; see man kernel_lockdown.7\n");
> +#endif
> +}
^ permalink raw reply
* [PATCH 24/24] debugfs: Restrict debugfs when the kernel is locked down
From: David Howells @ 2018-04-11 16:27 UTC (permalink / raw)
To: torvalds
Cc: linux-man, linux-api, jmorris, linux-kernel, dhowells,
linux-security-module
In-Reply-To: <152346387861.4030.4408662483445703127.stgit@warthog.procyon.org.uk>
Disallow opening of debugfs files that might be used to muck around when
the kernel is locked down as various drivers give raw access to hardware
through debugfs. Given the effort of auditing all 2000 or so files and
manually fixing each one as necessary, I've chosen to apply a heuristic
instead. The following changes are made:
(1) chmod and chown are disallowed on debugfs objects (though the root dir
can be modified by mount and remount, but I'm not worried about that).
(2) When the kernel is locked down, only files with the following criteria
are permitted to be opened:
- The file must have mode 00444
- The file must not have ioctl methods
- The file must not have mmap
(3) When the kernel is locked down, files may only be opened for reading.
Normal device interaction should be done through configfs, sysfs or a
miscdev, not debugfs.
Note that this makes it unnecessary to specifically lock down show_dsts(),
show_devs() and show_call() in the asus-wmi driver.
I would actually prefer to lock down all files by default and have the
the files unlocked by the creator. This is tricky to manage correctly,
though, as there are 19 creation functions and ~1600 call sites (some of
them in loops scanning tables).
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Andy Shevchenko <andy.shevchenko@gmail.com>
cc: acpi4asus-user@lists.sourceforge.net
cc: platform-driver-x86@vger.kernel.org
cc: Matthew Garrett <mjg59@srcf.ucam.org>
cc: Thomas Gleixner <tglx@linutronix.de>
---
fs/debugfs/file.c | 28 ++++++++++++++++++++++++++++
fs/debugfs/inode.c | 30 ++++++++++++++++++++++++++++--
2 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 1f99678ff5d3..51cb894c21f2 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -136,6 +136,25 @@ void debugfs_file_put(struct dentry *dentry)
}
EXPORT_SYMBOL_GPL(debugfs_file_put);
+/*
+ * Only permit access to world-readable files when the kernel is locked down.
+ * We also need to exclude any file that has ways to write or alter it as root
+ * can bypass the permissions check.
+ */
+static bool debugfs_is_locked_down(struct inode *inode,
+ struct file *filp,
+ const struct file_operations *real_fops)
+{
+ if ((inode->i_mode & 07777) == 0444 &&
+ !(filp->f_mode & FMODE_WRITE) &&
+ !real_fops->unlocked_ioctl &&
+ !real_fops->compat_ioctl &&
+ !real_fops->mmap)
+ return false;
+
+ return kernel_is_locked_down("debugfs");
+}
+
static int open_proxy_open(struct inode *inode, struct file *filp)
{
struct dentry *dentry = F_DENTRY(filp);
@@ -147,6 +166,11 @@ static int open_proxy_open(struct inode *inode, struct file *filp)
return r == -EIO ? -ENOENT : r;
real_fops = debugfs_real_fops(filp);
+
+ r = -EPERM;
+ if (debugfs_is_locked_down(inode, filp, real_fops))
+ goto out;
+
real_fops = fops_get(real_fops);
if (!real_fops) {
/* Huh? Module did not clean up after itself at exit? */
@@ -272,6 +296,10 @@ static int full_proxy_open(struct inode *inode, struct file *filp)
return r == -EIO ? -ENOENT : r;
real_fops = debugfs_real_fops(filp);
+ r = -EPERM;
+ if (debugfs_is_locked_down(inode, filp, real_fops))
+ goto out;
+
real_fops = fops_get(real_fops);
if (!real_fops) {
/* Huh? Module did not cleanup after itself at exit? */
diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 13b01351dd1c..4daec17b8215 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -32,6 +32,31 @@ static struct vfsmount *debugfs_mount;
static int debugfs_mount_count;
static bool debugfs_registered;
+/*
+ * Don't allow access attributes to be changed whilst the kernel is locked down
+ * so that we can use the file mode as part of a heuristic to determine whether
+ * to lock down individual files.
+ */
+static int debugfs_setattr(struct dentry *dentry, struct iattr *ia)
+{
+ if ((ia->ia_valid & (ATTR_MODE | ATTR_UID | ATTR_GID)) &&
+ kernel_is_locked_down("debugfs"))
+ return -EPERM;
+ return simple_setattr(dentry, ia);
+}
+
+static const struct inode_operations debugfs_file_inode_operations = {
+ .setattr = debugfs_setattr,
+};
+static const struct inode_operations debugfs_dir_inode_operations = {
+ .lookup = simple_lookup,
+ .setattr = debugfs_setattr,
+};
+static const struct inode_operations debugfs_symlink_inode_operations = {
+ .get_link = simple_get_link,
+ .setattr = debugfs_setattr,
+};
+
static struct inode *debugfs_get_inode(struct super_block *sb)
{
struct inode *inode = new_inode(sb);
@@ -356,6 +381,7 @@ static struct dentry *__debugfs_create_file(const char *name, umode_t mode,
inode->i_mode = mode;
inode->i_private = data;
+ inode->i_op = &debugfs_file_inode_operations;
inode->i_fop = proxy_fops;
dentry->d_fsdata = (void *)((unsigned long)real_fops |
DEBUGFS_FSDATA_IS_REAL_FOPS_BIT);
@@ -513,7 +539,7 @@ struct dentry *debugfs_create_dir(const char *name, struct dentry *parent)
return failed_creating(dentry);
inode->i_mode = S_IFDIR | S_IRWXU | S_IRUGO | S_IXUGO;
- inode->i_op = &simple_dir_inode_operations;
+ inode->i_op = &debugfs_dir_inode_operations;
inode->i_fop = &simple_dir_operations;
/* directory inodes start off with i_nlink == 2 (for "." entry) */
@@ -608,7 +634,7 @@ struct dentry *debugfs_create_symlink(const char *name, struct dentry *parent,
return failed_creating(dentry);
}
inode->i_mode = S_IFLNK | S_IRWXUGO;
- inode->i_op = &simple_symlink_inode_operations;
+ inode->i_op = &debugfs_symlink_inode_operations;
inode->i_link = link;
d_instantiate(dentry, inode);
return end_creating(dentry);
^ permalink raw reply related
* [PATCH 23/24] Lock down perf
From: David Howells @ 2018-04-11 16:27 UTC (permalink / raw)
To: torvalds
Cc: linux-man, linux-api, jmorris, linux-kernel, dhowells,
linux-security-module
In-Reply-To: <152346387861.4030.4408662483445703127.stgit@warthog.procyon.org.uk>
Disallow the use of certain perf facilities that might allow userspace to
access kernel data.
Signed-off-by: David Howells <dhowells@redhat.com>
---
kernel/events/core.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index fc1c330c6bd6..1922f2e0980a 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -10407,6 +10407,11 @@ SYSCALL_DEFINE5(perf_event_open,
return -EINVAL;
}
+ if ((attr.sample_type & PERF_SAMPLE_REGS_INTR) &&
+ kernel_is_locked_down("PERF_SAMPLE_REGS_INTR"))
+ /* REGS_INTR can leak data, lockdown must prevent this */
+ return -EPERM;
+
/* Only privileged users can get physical addresses */
if ((attr.sample_type & PERF_SAMPLE_PHYS_ADDR) &&
perf_paranoid_kernel() && !capable(CAP_SYS_ADMIN))
^ permalink raw reply related
* [PATCH 22/24] bpf: Restrict kernel image access functions when the kernel is locked down
From: David Howells @ 2018-04-11 16:27 UTC (permalink / raw)
To: torvalds
Cc: linux-man, linux-api, jmorris, linux-kernel, dhowells,
linux-security-module
In-Reply-To: <152346387861.4030.4408662483445703127.stgit@warthog.procyon.org.uk>
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.
Completely prohibit the use of BPF when the kernel is locked down.
Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: netdev@vger.kernel.org
cc: Chun-Yi Lee <jlee@suse.com>
cc: Alexei Starovoitov <alexei.starovoitov@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 0244973ee544..7457f2676c6d 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -2031,6 +2031,9 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, uattr, unsigned int, siz
if (sysctl_unprivileged_bpf_disabled && !capable(CAP_SYS_ADMIN))
return -EPERM;
+ if (kernel_is_locked_down("BPF"))
+ return -EPERM;
+
err = check_uarg_tail_zero(uattr, sizeof(attr), size);
if (err)
return err;
^ permalink raw reply related
* [PATCH 21/24] Lock down kprobes
From: David Howells @ 2018-04-11 16:26 UTC (permalink / raw)
To: torvalds
Cc: linux-man, linux-api, jmorris, linux-kernel, dhowells,
linux-security-module
In-Reply-To: <152346387861.4030.4408662483445703127.stgit@warthog.procyon.org.uk>
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.starovoitov@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
---
kernel/kprobes.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 102160ff5c66..4f5757732553 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1561,6 +1561,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))
^ permalink raw reply related
* [PATCH 20/24] Lock down /proc/kcore
From: David Howells @ 2018-04-11 16:26 UTC (permalink / raw)
To: torvalds
Cc: linux-man, linux-api, jmorris, linux-kernel, dhowells,
linux-security-module
In-Reply-To: <152346387861.4030.4408662483445703127.stgit@warthog.procyon.org.uk>
Disallow access to /proc/kcore when the kernel is locked down to prevent
access to cryptographic data.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <james.l.morris@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 d1e82761de81..cdebdee81719 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -546,6 +546,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;
^ permalink raw reply related
* [PATCH 19/24] x86/mmiotrace: Lock down the testmmiotrace module
From: David Howells @ 2018-04-11 16:26 UTC (permalink / raw)
To: torvalds
Cc: linux-man, linux-api, jmorris, linux-kernel, dhowells,
linux-security-module
In-Reply-To: <152346387861.4030.4408662483445703127.stgit@warthog.procyon.org.uk>
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 <tglx@linutronix.de>
Signed-off-by: David Howells <dhowells@redhat.com
cc: Thomas Gleixner <tglx@linutronix.de>
cc: Steven Rostedt <rostedt@goodmis.org>
cc: Ingo Molnar <mingo@kernel.org>
cc: "H. Peter Anvin" <hpa@zytor.com>
cc: x86@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");
^ permalink raw reply related
* [PATCH 18/24] Lock down module params that specify hardware parameters (eg. ioport)
From: David Howells @ 2018-04-11 16:26 UTC (permalink / raw)
To: torvalds
Cc: linux-man, linux-api, jmorris, linux-kernel, dhowells,
linux-security-module
In-Reply-To: <152346387861.4030.4408662483445703127.stgit@warthog.procyon.org.uk>
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 <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
---
kernel/params.c | 26 +++++++++++++++++++++-----
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/kernel/params.c b/kernel/params.c
index cc9108c2a1fd..2c08c4aa376b 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(¶ms[i]);
- err = params[i].ops->set(val, ¶ms[i]);
+ if (param_check_unsafe(¶ms[i], doing))
+ err = params[i].ops->set(val, ¶ms[i]);
+ else
+ err = -EPERM;
kernel_param_unlock(params[i].mod);
return err;
}
@@ -553,6 +561,12 @@ static ssize_t param_attr_show(struct module_attribute *mattr,
return count;
}
+#ifdef CONFIG_MODULES
+#define mod_name(mod) (mod)->name
+#else
+#define mod_name(mod) "unknown"
+#endif
+
/* sysfs always hands a nul-terminated string in buf. We rely on that. */
static ssize_t param_attr_store(struct module_attribute *mattr,
struct module_kobject *mk,
@@ -565,8 +579,10 @@ static ssize_t param_attr_store(struct module_attribute *mattr,
return -EPERM;
kernel_param_lock(mk->mod);
- param_check_unsafe(attribute->param);
- err = attribute->param->ops->set(buf, attribute->param);
+ if (param_check_unsafe(attribute->param, mod_name(mk->mod)))
+ err = attribute->param->ops->set(buf, attribute->param);
+ else
+ err = -EPERM;
kernel_param_unlock(mk->mod);
if (!err)
return len;
^ permalink raw reply related
* [PATCH 17/24] Lock down TIOCSSERIAL
From: David Howells @ 2018-04-11 16:26 UTC (permalink / raw)
To: torvalds
Cc: linux-man, linux-api, jmorris, linux-kernel, dhowells,
linux-security-module
In-Reply-To: <152346387861.4030.4408662483445703127.stgit@warthog.procyon.org.uk>
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 <gregkh@linuxfoundation.org>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Jiri Slaby <jslaby@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 0466f9f08a91..360f8e4416c4 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -829,6 +829,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 ||
^ permalink raw reply related
* [PATCH 16/24] Prohibit PCMCIA CIS storage when the kernel is locked down
From: David Howells @ 2018-04-11 16:26 UTC (permalink / raw)
To: torvalds
Cc: linux-man, linux-api, jmorris, linux-kernel, dhowells,
linux-security-module
In-Reply-To: <152346387861.4030.4408662483445703127.stgit@warthog.procyon.org.uk>
Prohibit replacement of the PCMCIA Card Information Structure when the
kernel is locked down.
Suggested-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-pcmcia@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 102646fedb56..e46c948d7246 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)
^ permalink raw reply related
* [PATCH 15/24] acpi: Disable APEI error injection if the kernel is locked down
From: David Howells @ 2018-04-11 16:26 UTC (permalink / raw)
To: torvalds
Cc: linux-man, linux-api, jmorris, linux-kernel, dhowells,
linux-security-module
In-Reply-To: <152346387861.4030.4408662483445703127.stgit@warthog.procyon.org.uk>
From: Linn Crosetto <linn@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 <linn@hpe.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: linux-acpi@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)))
^ permalink raw reply related
* [PATCH 14/24] acpi: Disable ACPI table override if the kernel is locked down
From: David Howells @ 2018-04-11 16:26 UTC (permalink / raw)
To: torvalds
Cc: linux-man, linux-api, jmorris, linux-kernel, dhowells,
linux-security-module
In-Reply-To: <152346387861.4030.4408662483445703127.stgit@warthog.procyon.org.uk>
From: Linn Crosetto <linn@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 <linn@hpe.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: linux-acpi@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 849c4fb19b03..6c5ee7e66842 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -527,6 +527,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);
^ permalink raw reply related
* [PATCH 13/24] acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down
From: David Howells @ 2018-04-11 16:26 UTC (permalink / raw)
To: torvalds
Cc: linux-man, linux-api, jmorris, linux-kernel, dhowells,
linux-security-module
In-Reply-To: <152346387861.4030.4408662483445703127.stgit@warthog.procyon.org.uk>
From: Josh Boyer <jwboyer@redhat.com>
This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to modify the workings of hardware . Reject
the option when the kernel is locked down.
Signed-off-by: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: Dave Young <dyoung@redhat.com>
cc: linux-acpi@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 7ca41bf023c9..34e4ce7939f4 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;
#ifdef CONFIG_KEXEC
- if (acpi_rsdp)
+ if (acpi_rsdp && !kernel_is_locked_down("ACPI RSDP specification"))
return acpi_rsdp;
#endif
pa = acpi_arch_get_root_pointer();
^ permalink raw reply related
* [PATCH 12/24] ACPI: Limit access to custom_method when the kernel is locked down
From: David Howells @ 2018-04-11 16:25 UTC (permalink / raw)
To: torvalds
Cc: linux-man, linux-api, jmorris, linux-kernel, dhowells,
linux-security-module
In-Reply-To: <152346387861.4030.4408662483445703127.stgit@warthog.procyon.org.uk>
From: Matthew Garrett <mjg59@srcf.ucam.org>
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 <mjg59@srcf.ucam.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: linux-acpi@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 e967c1173ba3..a07fbe999eb6 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))
^ permalink raw reply related
* [PATCH 11/24] x86/msr: Restrict MSR access when the kernel is locked down
From: David Howells @ 2018-04-11 16:25 UTC (permalink / raw)
To: torvalds
Cc: linux-man, linux-api, jmorris, linux-kernel, dhowells,
linux-security-module
In-Reply-To: <152346387861.4030.4408662483445703127.stgit@warthog.procyon.org.uk>
From: Matthew Garrett <mjg59@srcf.ucam.org>
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 <mjg59@srcf.ucam.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: x86@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;
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox