.
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
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
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 userspac
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
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.
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
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 t
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
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 att
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
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 boo
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 i
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
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 elabor
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
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.
quot; 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 Pub
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.o
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
David Howells 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
Date: Thu Feb 22 14:01:49 2018 +
kexec_file: Restrict at runtim
I'm intending on inserting the attached patch before this one.
David
---
commit 87a39b258eca2e15884ee90c3fcd5758d6057b17
Author: David Howells
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
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 imag
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
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 imag
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 k
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 sign
David Howells 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'
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
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 unsubscrib
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
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 /
> functi
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
-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
h
MSR registers and disallowing hibernation,
Signed-off-by: David Howells
Acked-by: James Morris
---
include/linux/kernel.h | 17 +
include/linux/security.h |8 ++
security/Kconfig |8 ++
security/Makefile|3 ++
security/lock_down.c |
From: Mimi Zohar
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
Signed-off-by: David Howells
---
security/integrity/ima/ima_polic
.
Signed-off-by: Matthew Garrett
Signed-off-by: David Howells
Acked-by: Dave Young
Reviewed-by: "Lee, Chun-Yi"
Reviewed-by: James Morris
cc: ke...@lists.infradead.org
---
kernel/kexec.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/kernel/kexec.c b/kernel/kex
secure_boot flag in original
kernel.
secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the
stub. Fixing this issue by copying secure_boot flag across kexec reboot.
Signed-off-by: Dave Young
Signed-off-by: David Howells
Reviewed-by: "Lee, Chun-Yi&quo
locked down to prevent this.
Also disallow /dev/port from being opened to prevent raw ioport access and
thus DMA from being used to accomplish the same thing.
Signed-off-by: Matthew Garrett
Signed-off-by: David Howells
Reviewed-by: "Lee, Chun-Yi"
---
drivers/char/mem.c |2 ++
1 file
this for
sufficiently IOMMU-isolated devices.
Signed-off-by: Matthew Garrett
Signed-off-by: David Howells
Acked-by: Bjorn Helgaas
Reviewed-by: "Lee, Chun-Yi"
cc: linux-...@vger.kernel.org
---
drivers/pci/pci-sysfs.c |9 +
drivers/pci/proc.c |9 -
d
tthew Garrett
Signed-off-by: Chun-Yi Lee
Signed-off-by: David Howells
Reviewed-by: James Morris
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 1
From: Matthew Garrett
uswsusp allows a user process to dump and then restore kernel state, which
makes it possible to modify the running kernel. Disable this if the kernel
is locked down.
Signed-off-by: Matthew Garrett
Signed-off-by: David Howells
Reviewed-by: "Lee, Chun-Yi"
R
down the KDADDIO, KDDELIO, KDENABIO and
KDDISABIO console ioctls.
Signed-off-by: Matthew Garrett
Signed-off-by: David Howells
Reviewed-by: Thomas Gleixner
Reviewed-by: "Lee, Chun-Yi"
cc: x...@kernel.org
---
arch/x86/kernel/ioport.c |6 --
1 file changed, 4 insertions(+), 2
tions. Prevent that if the
kernel is locked down.
Signed-off-by: Matthew Garrett
Signed-off-by: David Howells
Reviewed-by: "Lee, Chun-Yi"
cc: acpi4asus-u...@lists.sourceforge.net
cc: platform-driver-...@vger.kernel.org
---
drivers/platform/x86/asus-wmi.c |9 +
1 file change
igned-off-by: Matthew Garrett
Signed-off-by: David Howells
Acked-by: Kees Cook
Reviewed-by: Thomas Gleixner
Reviewed-by: "Lee, Chun-Yi"
cc: x...@kernel.org
---
arch/x86/kernel/msr.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/x86/kernel/msr.c b/arch/x86/ker
From: Matthew Garrett
custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to circumvent restrictions on module loading.
Disable it if the kernel is locked down.
Signed-off-by: Matthew Garrett
Signed-off-by: David Howells
Reviewed-by: &quo
uld disallow any unauthenticated
changes to kernel space. ACPI tables contain code invoked by the kernel,
so do not allow ACPI tables to be overridden if the kernel is locked down.
Signed-off-by: Linn Crosetto
Signed-off-by: David Howells
Reviewed-by: "Lee, Chun-Yi"
cc: linux-a...@vg
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
Signed-off-by: David Howells
cc: Dario
From: Josh Boyer
This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to modify the workings of hardware . Reject
the option when the kernel is locked down.
Signed-off-by: Josh Boyer
Signed-off-by: David Howells
Reviewed-by: "Lee, Ch
unauthenticated privileged code,
the effect of these errors may persist across reboots and affect trust in
the underlying hardware, so disable error injection through EINJ if
the kernel is locked down.
Signed-off-by: Linn Crosetto
Signed-off-by: David Howells
Reviewed-by: "Lee, Chun-Yi"
c
Prohibit replacement of the PCMCIA Card Information Structure when the
kernel is locked down.
Suggested-by: Dominik Brodowski
Signed-off-by: David Howells
cc: linux-pcm...@lists.infradead.org
---
drivers/pcmcia/cistpl.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pcmcia
-Hartman
Signed-off-by: David Howells
cc: Jiri Slaby
---
drivers/tty/serial/serial_core.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 3a14cccbd7ff..41f0922ad842 100644
--- a/drivers/tty/serial
The testmmiotrace module shouldn't be permitted when the kernel is locked
down as it can be used to arbitrarily read and write MMIO space.
Suggested-by: Thomas Gleixner
Signed-off-by: David Howells
cc: Steven Rostedt
cc: Ingo Molnar
cc: "H. Peter Anvin"
cc: x...@kernel.org
--
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
cc: Andy Shevchenko
cc: acpi4asus-u...@lists.sourceforge.net
cc: platform-driver
Provided an annotation for module parameters that specify hardware
parameters (such as io ports, iomem addresses, irqs, dma channels, fixed
dma buffers and other types).
Suggested-by: Alan Cox
Signed-off-by: David Howells
---
kernel/params.c | 26 +-
1 file changed
Disallow access to /proc/kcore when the kernel is locked down to prevent
access to cryptographic data.
Signed-off-by: David Howells
Reviewed-by: James Morris
---
fs/proc/kcore.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 45629f4b5402
t the time, will prevent
data theft by that mechanism also.
Reported-by: Alexei Starovoitov
Signed-off-by: David Howells
---
kernel/trace/ftrace.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 6abfafd7f173..9c
.
Completely prohibit the use of BPF when the kernel is locked down.
Suggested-by: Alexei Starovoitov
Signed-off-by: David Howells
cc: net...@vger.kernel.org
cc: Chun-Yi Lee
cc: Alexei Starovoitov
---
kernel/bpf/syscall.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/bpf/syscall.c b
Disallow the creation of kprobes when the kernel is locked down by
preventing their registration. This prevents kprobes from being used to
access kernel memory, either to make modifications or to steal crypto data.
Reported-by: Alexei Starovoitov
Signed-off-by: David Howells
---
kernel
there.
Suggested-by: Ard Biesheuvel
Signed-off-by: David Howells
Reviewed-by: Ard Biesheuvel
cc: linux-efi@vger.kernel.org
---
arch/x86/kernel/setup.c | 14 +-
drivers/firmware/efi/Makefile |1 +
drivers/firmware/efi/secureboot.c |
- if the kernel is secure-booted.
Signed-off-by: David Howells
Acked-by: Ard Biesheuvel
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
: David Howells
Reviewed-by: "Lee, Chun-Yi"
cc: linux...@vger.kernel.org
---
kernel/power/hibernate.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index a5c36e9c56a6..f2eafefeec50 100644
--- a/kernel/power/h
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
Reviewed-by: "Lee, Chun-Yi"
Reviewed-by: James Morris
---
kernel/module.c | 19 ---
1 file changed, 12
in asm/setup.h.
Since this macro must be defined in an arch to be able to use this facility
for that arch, the Kconfig option is restricted to arches that support it.
Signed-off-by: Kyle McMartin
Signed-off-by: David Howells
cc: x...@kernel.org
---
arch/x86/include/asm/setup.h |2
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
> functi
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_ms
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
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())
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
Signed-off-by: David Howells
Reviewed-by: James Morris
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
Hi Mimi,
I've altered this patch to allow for IMA appraisal on finit_module(). See the
attached.
David
---
commit c0d5336356004e7543314e388755a00e725521da
Author: David Howells
Date: Wed May 24 14:56:01 2017 +0100
Enforce module signatures if the kernel is locked down
I
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 f
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_enabl
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
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 bein
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.
.\&qu
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 enabl
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 lea
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 bo
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 messa
James Morris wrote:
> I have to wonder, though, after everything is locked down, how easy will
> it be for new things to slip in which need to be included in the lockdown,
> but are not.
That's always a possibility, and short of reviewing every change, particularly
in the drivers, I'm not sure
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 ne
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
: David Howells
Reviewed-by: "Lee, Chun-Yi"
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)
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 i
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 t
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.
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 does
I've pushed a new version to git that fixes bugs in patches 1 and 2.
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
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:
h
MSR registers and disallowing hibernation,
Signed-off-by: David Howells
---
include/linux/kernel.h | 17 +
include/linux/security.h |8 ++
security/Kconfig |8 ++
security/Makefile|3 ++
security/lock_down.c |
LOCKDOWN_LIFT_KEY in asm/setup.h.
Signed-off-by: Kyle McMartin
Signed-off-by: David Howells
cc: x...@kernel.org
---
arch/x86/include/asm/setup.h |2 ++
drivers/input/misc/uinput.c |1 +
drivers/tty/sysrq.c | 19 +++--
include/linux/input.h|5
include/linux
If the kernel is locked down, require that all modules have valid
signatures that we can verify.
Signed-off-by: David Howells
---
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
From: Matthew Garrett
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
Signed-off-by: David Howells
---
drivers/char/mem.c
.
Signed-off-by: Matthew Garrett
Signed-off-by: David Howells
Acked-by: Dave Young
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
secure_boot flag in original
kernel.
secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the
stub. Fixing this issue by copying secure_boot flag across kexec reboot.
Signed-off-by: Dave Young
Signed-off-by: David Howells
cc: ke...@lists.infradead.org
---
arch/x86/kernel
igned-off-by: David Howells
cc: ke...@lists.infradead.org
---
kernel/kexec_file.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 9f48f4412297..ff6523f2dcc2 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -255,6 +2
From: Matthew Garrett
uswsusp allows a user process to dump and then restore kernel state, which
makes it possible to modify the running kernel. Disable this if the kernel
is locked down.
Signed-off-by: Matthew Garrett
Signed-off-by: David Howells
cc: linux...@vger.kernel.org
---
kernel
this for
sufficiently IOMMU-isolated devices.
Signed-off-by: Matthew Garrett
Signed-off-by: David Howells
Acked-by: Bjorn Helgaas
cc: linux-...@vger.kernel.org
---
drivers/pci/pci-sysfs.c |9 +
drivers/pci/proc.c |9 -
drivers/pci/syscall.c |3 ++-
3 files
From: Matthew Garrett
Writing to MSRs should not be allowed if the kernel is locked down, since
it could lead to execution of arbitrary code in kernel mode. Based on a
patch by Kees Cook.
Signed-off-by: Matthew Garrett
Signed-off-by: David Howells
Acked-by: Kees Cook
Reviewed-by: Thomas
: David Howells
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
1 - 100 of 222 matches
Mail list logo
