Re: [GIT PULL] Kernel lockdown for secure boot

> How? When there are random DMA-capable PCI devices that are driven by > userland tools that are mmap()ing the BARs out of sysfs, how do we > simultaneously avoid breaking those devices while also preventing the > majority of users from being vulnerable to an attacker just DMAing over the >

Re: [GIT PULL] Kernel lockdown for secure boot

> Furthermore, there is a fundamental deviation from common security > sense here, where things like command line parameters and other > lockdown specific tunables are blacklisted rather than whitelisted, I've been complaining about this from the start but it appears to be a write only authorship

Re: [PATCH 1/2] fs/efivarfs: restrict inode permissions

On Wed, 21 Feb 2018 09:03:00 + > The thing I like about rate limiting (for everyone including root) is > that it does not break anybody's workflow (unless EFI variable access > occurs on a hot path, in which case you're either a) asking for it, or > b) the guy trying to DoS us), and that it

Re: Read-protected UEFI variables

> If the UEFI is as secure as storing an unencrypted file on a hard > drive, I am satisfied. Or do you have a better idea where to store the > SSH keys for a diskless system that boots via network? Store them in the TPM ? If you are booting over a network and not doing some kind of TPM based

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

> I am curious though, is the above notion of having hardware require signed > firmware an implication brought down by UEFI? If so do you have any pointers > to where this is stipulated? Or is it just a best practice we assume some > manufacturers are implementing? It's a mix of best practice and

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

On Tue, 5 Dec 2017 18:01:46 +0800 Gary Lin wrote: > The series of patches introduce Security Version to EFI stub. > > Security Version is a monotonically increasing number and designed to > prevent the user from loading an insecure kernel accidentally. The > bootloader maintains

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

On Mon, 13 Nov 2017 14:09:10 -0800 Linus Torvalds wrote: > On Mon, Nov 13, 2017 at 1:44 PM, David Howells wrote: > > > > Whilst that may be true, we either have to check signatures on every bit of > > firmware that the appropriate driver

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

On Mon, 13 Nov 2017 18:42:50 +0100 "Luis R. Rodriguez" <mcg...@kernel.org> wrote: > On Sat, Nov 11, 2017 at 02:32:40AM +, Alan Cox wrote: > > > My assumption here is: > > > 1) there are some less important and so security-insensitive firmwares, > &g

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

> My assumption here is: > 1) there are some less important and so security-insensitive firmwares, >by which I mean that such firmwares won't be expected to be signed in >terms of vulnerability or integrity. >(I can't give you examples though.) > 2) firmware's signature will be

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

On Thu, 19 Oct 2017 15:52:04 +0100 David Howells wrote: > 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

Re: [PATCH] x86/efi: Only pass mapped RAM regions to free_bootmem_late()

On Thu, 5 Jun 2014 14:27:34 +0100 Matt Fleming m...@console-pimps.org wrote: From: Matt Fleming matt.flem...@intel.com free_bootmem_late() expects to only be passed RAM regions that the kernel can access, and that have a corresponding 'struct page'. It's possible for regions in the EFI

Re: [RFC] [PATCH] X86 MSR read whitelist

What exactly could go wrong with which MSR read? Show me a pair of Intel and AMD architecture documents guaranteeing all undefined, undocumented, and documented MSR reads for all processors have no side effects. I just picked some MSRs I found in turbostat and cpupower. Len: It would be great

Re: Do not allow MSR or Embedded Controller writes from userspace in secure boot case

On Thu, 8 Nov 2012 14:39:19 + Matthew Garrett mj...@srcf.ucam.org wrote: On Thu, Nov 08, 2012 at 10:40:33AM +0100, Thomas Renninger wrote: On Wednesday, November 07, 2012 09:54:03 PM Matthew Garrett wrote: Is there a case where modifying MSRs or EC registers can cause arbitrary code

Re: Do not allow MSR or Embedded Controller writes from userspace in secure boot case

On Wed, 07 Nov 2012 23:51:06 +0100 H. Peter Anvin h...@zytor.com wrote: On 11/07/2012 10:54 PM, Matthew Garrett wrote: Is there a case where modifying MSRs or EC registers can cause arbitrary code execution? For MSRs we could have a whitelist of permitted MSRs, but allowing general MSR

Re: Do not allow MSR or Embedded Controller writes from userspace in secure boot case

On Wed, 7 Nov 2012 22:28:17 +0100 Thomas Renninger tr...@suse.de wrote: Hi, I have seen some patches in this area and I wonder whether MSR and EC write accesses from userspace got closed already. You need to cover read accesses as well I suspect to be completely paranoid safe. I would

Re: [RFC] Second attempt at kernel secure boot support

On Tue, 06 Nov 2012 16:55:25 -0500 Matthew Garrett mj...@srcf.ucam.org wrote: I'm not sure why you think that Fedora PXE installs will automatically wipe disks - they'll do whatever Kickstart tells them to do. The only thing relevant to secure boot here is that you need a signed bootloader,

Re: [PATCH] samsung-laptop: Disable if CONFIG_EFI=y

There is the 'efi_enabled' variable, but it doesn't strictly mean this_is_a_uefi_system(), it actually means Do we have EFI runtime services?. The whole thing is a bit of a mess and I'm planning on cleaning it up this week. As far as I can understand it we should be reserving those areas on

Re: [RFC] Second attempt at kernel secure boot support

On Mon, 5 Nov 2012 12:38:58 + Matthew Garrett mj...@srcf.ucam.org wrote: On Sun, Nov 04, 2012 at 11:24:17PM -0800, Eric W. Biederman wrote: H. Peter Anvin h...@zytor.com writes: That is a hugely different thing from needing a console. Not at all. In the general case user

Re: [PATCH] samsung-laptop: Disable if CONFIG_EFI=y

Acked-by: Corentin Chary corentin.ch...@gmail.com This is totally bogus and prevents users build a kernel which can work in either mode. As such its a regression. Do the detection check at runtime. If it was booted via EFI then don't grovel in places you shouldn't. Indeed its possible EFI

Re: [PATCH v2 01/20] efi: Add support for a UEFI variable filesystem

+ if (datasize remaining_size) { + printk(KERN_ERR efivars: Variable size too big\n); + return -ENOSPC; Why the printk - you've handed back a sensible error code. If you do have a logging result you need to rate limit it as its from the user. I don't think you need

Re: [RFC] Second attempt at kernel secure boot support

You're guaranteed to be able to do this on any Windows 8 certified hardware. Thats not my understanding of the situation. -- 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

Re: [RFC] Second attempt at kernel secure boot support

No reason to? How can I configure an off the shelf system originally sold with windows 8 installed to boot in UEFI secure boot mode using shim without trusting Microsoft's key? Assuming its an x86 and a PC class platform and thus should allow you to disable secure boot mode then you disable

Re: [RFC] Second attempt at kernel secure boot support

I think it make sense because the private key is still protected by signer. Any hacker who modified firmware is still need use private key to generate signature, but hacker's private key is impossible to match with the public key that kernel used to verify firmware. And, I afraid we have no

Re: [RFC] Second attempt at kernel secure boot support

would get keys revoked. If your key is revoke Linux can't boot on a large amount of new hardware without BIOS twiddling. See live free or die. If you want to live in a world where you can't even fart before checking if the man from Microsoft will revoke your key you might as well go home now.

Re: [RFC] Second attempt at kernel secure boot support

is basically DMA-ing arbitrary data over the whole RAM. I am currently not able to imagine a scenario how this could be made secure (without storing private keys to sign the hibernation image on the machine itself which, well, doesn't sound secure either). That's what the TPM is for (in

Re: [PATCH 01/20] efi: Add support for a UEFI variable filesystem

+static ssize_t efivarfs_file_write(struct file *file, + const char __user *userbuf, size_t count, loff_t *ppos) +{ + struct efivar_entry *var = file-private_data; + struct efivars *efivars; + efi_status_t status; + void *data; + u32 attributes; +