Re: [GIT PULL] Kernel lockdown for secure boot

On Sun, Apr 08, 2018 at 08:40:10PM -0700, Alexei Starovoitov wrote: > On Sun, Apr 08, 2018 at 04:07:42PM +0800, joeyli wrote: > > > > > If the only thing that folks are paranoid about is reading > > > arbitrary kernel memory with bpf_probe_read() helper > > > then preferred patch would be to

Re: [GIT PULL] Kernel lockdown for secure boot

On 04/09/2018 05:40 AM, Alexei Starovoitov wrote: > On Sun, Apr 08, 2018 at 04:07:42PM +0800, joeyli wrote: [...] >>> If the only thing that folks are paranoid about is reading >>> arbitrary kernel memory with bpf_probe_read() helper >>> then preferred patch would be to disable it during

Re: [GIT PULL] Kernel lockdown for secure boot

On Sun, Apr 08, 2018 at 04:07:42PM +0800, joeyli wrote: > > > If the only thing that folks are paranoid about is reading > > arbitrary kernel memory with bpf_probe_read() helper > > then preferred patch would be to disable it during verification > > when in lockdown mode > > Sorry for I didn't

Re: [GIT PULL] Kernel lockdown for secure boot

Hi! > > What I'm afraid of is this turning into a "security" feature that ends up > > being circumvented in most scenarios where it's currently deployed - eg, > > module signatures are mostly worthless in the non-lockdown case because you > > can just grab the sig_enforce symbol address and then

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed 2018-04-04 00:39:05, David Howells wrote: > 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

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 03, 2018 at 07:34:25PM -0700, Alexei Starovoitov wrote: > On Tue, Apr 3, 2018 at 9:26 AM, Andy Lutomirski wrote: > > On Tue, Apr 3, 2018 at 8:41 AM, Alexei Starovoitov > > wrote: > >> On Tue, Apr 03, 2018 at 08:11:07AM -0700, Andy

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 04, 2018 at 04:31:46AM +, Matthew Garrett wrote: > On Tue, Apr 3, 2018 at 7:34 PM Alexei Starovoitov < > alexei.starovoi...@gmail.com> wrote: > > If the only thing that folks are paranoid about is reading > > arbitrary kernel memory with bpf_probe_read() helper > > then preferred

Re: [GIT PULL] Kernel lockdown for secure boot

> > There's no inherent difference, in terms of the trust chain, between > compromising it to use the machine as a toaster or to run a botnet - the > trust chain is compromised either way. But you're much more likely to > notice if your desktop starts producing bread products than if it hides >

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 11:42 AM, Peter Jones wrote: > On Tue, Apr 03, 2018 at 02:51:23PM -0700, Andy Lutomirski wrote: >> On Tue, Apr 3, 2018 at 12:29 PM, Matthew Garrett wrote: >> Can someone please explain why the UEFI crowd cares so much about "as >> a

Re: [GIT PULL] Kernel lockdown for secure boot

On Thu, Apr 5, 2018 at 10:59 AM Alan Cox wrote: > VT-D Once Intel provide that on all hardware and actually make it work reliably with their graphics chipsets it's certainly a solution for the PCI DMA problem, but right now it's still effectively undeployable for a

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: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot)

Hi Mimi, On Thu, Apr 05, 2018 at 10:01:09AM -0400, Mimi Zohar wrote: > On Thu, 2018-04-05 at 10:16 +0800, joeyli wrote: > > Hi David, > > > > On Wed, Apr 04, 2018 at 05:17:24PM +0100, David Howells wrote: > > > Andy Lutomirski wrote: > > > > > > > Since this thread has

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

On Thu, 2018-04-05 at 10:16 +0800, joeyli wrote: > Hi David, > > On Wed, Apr 04, 2018 at 05:17:24PM +0100, David Howells wrote: > > Andy Lutomirski wrote: > > > > > Since this thread has devolved horribly, I'm going to propose a solution. > > > > > > 1. Split the "lockdown"

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

Hi David, On Wed, Apr 04, 2018 at 05:17:24PM +0100, David Howells wrote: > 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

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

On Wed, Apr 04, 2018 at 11:19:27PM +0100, David Howells wrote: > 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

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

Hi Andy, On Wed, Apr 04, 2018 at 07:49:12AM -0700, Andy Lutomirski wrote: > Since this thread has devolved horribly, I'm going to propose a solution. ... > 6. There's a way to *decrease* the lockdown level below the configured > value. (This ability itself may be gated by a config option.) >

Re: [GIT PULL] Kernel lockdown for secure boot

On Thu, Apr 5, 2018 at 2:26 AM, Matthew Garrett wrote: > On Tue, Apr 3, 2018 at 11:56 PM Peter Dolding wrote: >> On Wed, Apr 4, 2018 at 11:13 AM, Matthew Garrett wrote: > >> > There are four cases: >> > >> > Verified Boot off, lockdown off:

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

On Wed, Apr 4, 2018 at 4:25 PM James Morris wrote: > It's surely reasonable to allow an already secure-booted system to be > debugged without needing to be rebooted. alt-sysrq-x from a physical console will do that. -- To unsubscribe from this list: send the line "unsubscribe

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 5:05 PM Peter Dolding wrote: > > If you don't have secure boot then an attacker with root can modify your > > bootloader or kernel, and on next boot lockdown can be silently disabled. > Stop being narrow minded you don't need secure boot to protect >

Re: [GIT PULL] Kernel lockdown for secure boot

> If you don't have secure boot then an attacker with root can modify your > bootloader or kernel, and on next boot lockdown can be silently disabled. Stop being narrow minded you don't need secure boot to protect bootloader or kernel the classic is only boot from read only media. Another is

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

On Wed, 4 Apr 2018, David Howells wrote: > > 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? It's surely reasonable to

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

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

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 1:01 PM Thomas Gleixner wrote: > Now where the disagreement lies is the way how the uid/ring0 aspect is tied > to secure boot, which makes it impossible to be useful independent of > Secure Boot. It doesn't - you can pass a command line parameter that

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, 4 Apr 2018, Peter Jones wrote: > That is to say, as a result of the way malware has been written, our way > of thinking about it is often that it's a way to build a boot loader for > a malicious kernel, so that's how we wind up talking about it. Are we > concerned with malware stealing

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 03, 2018 at 02:51:23PM -0700, Andy Lutomirski wrote: > On Tue, Apr 3, 2018 at 12:29 PM, Matthew Garrett wrote: > > On Tue, Apr 3, 2018 at 9:46 AM Andy Lutomirski wrote: > >> On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett wrote: >

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 11:39 AM, Andy Lutomirski wrote: > On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett wrote: >> On Wed, Apr 4, 2018 at 6:52 AM Theodore Y. Ts'o wrote: >> >>> On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote: >>>

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 9:39 AM Andy Lutomirski wrote: > On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett wrote: > > If you don't have secure boot then an attacker with root can modify your > > bootloader or kernel, and on next boot lockdown can be silently

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 11:56 PM Peter Dolding wrote: > On Wed, Apr 4, 2018 at 11:13 AM, Matthew Garrett wrote: > > There are four cases: > > > > Verified Boot off, lockdown off: Status quo in distro and mainline kernels > > Verified Boot off, lockdown on:

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

+a...@kernel.org On Wed, Apr 4, 2018 at 6:17 PM, David Howells wrote: > Andy Lutomirski wrote: [...] >> 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

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 6:52 AM Theodore Y. Ts'o wrote: > On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote: > > Theodore Y. Ts'o wrote: > > > > > Whoa. Why doesn't lockdown prevent kexec? Put another away, why > > > isn't this a problem for people who

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 5:57 AM Theodore Y. Ts'o wrote: > On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote: > > What I'm afraid of is this turning into a "security" feature that ends up > > being circumvented in most scenarios where it's currently deployed - eg, > >

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 9:09 AM Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 9:30 PM, Matthew Garrett wrote: > > > > Bear in mind that I'm talking about defaults here > Mattyhew, I really want you to look yourself in the mirror. > Those

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

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:

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 9:30 PM, Matthew Garrett wrote: > > Bear in mind that I'm talking about defaults here Mattyhew, I really want you to look yourself in the mirror. Those defaults are really horrible defautls for real technical reasons. You asked me why when I questioned

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

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

Re: [GIT PULL] Kernel lockdown for secure boot

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

Re: [GIT PULL] Kernel lockdown for secure boot

I've reordered your email to make my email more coherent. > On Apr 4, 2018, at 1:05 AM, David Howells wrote: > > > What we *have* said is that *if* we want to pass the secure boot state across > kexec, then we have to make sure that: > What do you even mean "pass the

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 04, 2018 at 09:34:11AM -0400, Theodore Y. Ts'o wrote: > On Wed, Apr 04, 2018 at 03:02:33PM +0200, Greg Kroah-Hartman wrote: > > On Wed, Apr 04, 2018 at 08:57:43AM -0400, Theodore Y. Ts'o wrote: > > > On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote: > > > > What I'm

Re: [GIT PULL] Kernel lockdown for secure boot

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

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote: > 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

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 04, 2018 at 03:02:33PM +0200, Greg Kroah-Hartman wrote: > On Wed, Apr 04, 2018 at 08:57:43AM -0400, Theodore Y. Ts'o wrote: > > On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote: > > > What I'm afraid of is this turning into a "security" feature that ends up > > > being

Re: [GIT PULL] Kernel lockdown for secure boot

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

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, 2018-04-04 at 08:57 -0400, Theodore Y. Ts'o wrote: > On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote: > > What I'm afraid of is this turning into a "security" feature that ends up > > being circumvented in most scenarios where it's currently deployed - eg, > > module

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 04, 2018 at 08:57:43AM -0400, Theodore Y. Ts'o wrote: > On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote: > > What I'm afraid of is this turning into a "security" feature that ends up > > being circumvented in most scenarios where it's currently deployed - eg, > > module

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 04, 2018 at 04:30:18AM +, Matthew Garrett wrote: > What I'm afraid of is this turning into a "security" feature that ends up > being circumvented in most scenarios where it's currently deployed - eg, > module signatures are mostly worthless in the non-lockdown case because you >

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 04, 2018 at 12:19:35AM +, Matthew Garrett wrote: > On Tue, Apr 3, 2018 at 5:18 PM Andy Lutomirski wrote: > > > if your secure boot-enabled bootloader can't prevent a bad guy from > > using malicious kernel command line parameters, then fix it. > > How is a

Re: [GIT PULL] Kernel lockdown for secure boot

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

Re: [GIT PULL] Kernel lockdown for secure boot

. On Wed, Apr 4, 2018 at 11:13 AM, Matthew Garrett wrote: > There are four cases: > > Verified Boot off, lockdown off: Status quo in distro and mainline kernels > Verified Boot off, lockdown on: Perception of security improvement that's > trivially circumvented (and so bad) >

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 7:34 PM Alexei Starovoitov < alexei.starovoi...@gmail.com> wrote: > If the only thing that folks are paranoid about is reading > arbitrary kernel memory with bpf_probe_read() helper > then preferred patch would be to disable it during verification > when in lockdown mode. >

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 6:43 PM Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 6:13 PM, Matthew Garrett wrote: > > > > There are four cases: > No. > Matthew., stop with the agenda already. > This shit is what I'm talking about: > > Verified

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 9:26 AM, Andy Lutomirski wrote: > On Tue, Apr 3, 2018 at 8:41 AM, Alexei Starovoitov > wrote: >> On Tue, Apr 03, 2018 at 08:11:07AM -0700, Andy Lutomirski wrote: >>> > >>> >> "bpf: Restrict kernel image access functions when

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 6:30 PM, Justin Forbes wrote: >> >> If there actually was a good explanation for the tie-in, it should >> have been front-and-center and explained as such. >> > Honestly, yes, the major distros have been shipping this patch set for years > now, and every

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 6:13 PM, Matthew Garrett wrote: > > There are four cases: No. Matthew., stop with the agenda already. This shit is what I'm talking about: > Verified Boot off, lockdown on: Perception of security improvement that's > trivially circumvented (and so bad)

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 7:56 PM, Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 5:46 PM, Matthew Garrett wrote: >> >> The generic distros have been shipping this policy for the past 5 years. > > .. so apparently it doesn't actually break things?

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 5:56 PM Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 5:46 PM, Matthew Garrett wrote: > > > > The generic distros have been shipping this policy for the past 5 years. > .. so apparently it doesn't actually break things?

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 5:25 PM, Linus Torvalds wrote: > > Honestly, I don't think the patchset is viable at all in that case. .. or rather, it's probably viable only for distributions that already have reasons to only care about controlled hardware environments, ie

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 5:16 PM, Matthew Garrett wrote: > > I ignored it because it's not a viable option. Part of the patchset > disables various kernel command line options. If there's a kernel command > line option that disables the patchset then it's pointless. Honestly, I

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 5:17 PM, Jann Horn wrote: > On Wed, Apr 4, 2018 at 2:06 AM, Linus Torvalds > wrote: >> On Tue, Apr 3, 2018 at 4:59 PM, Matthew Garrett wrote: >>> >>> Ok. So we can build distribution kernels that *always*

Re: [GIT PULL] Kernel lockdown for secure boot

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

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 5:18 PM Andy Lutomirski wrote: > if your secure boot-enabled bootloader can't prevent a bad guy from > using malicious kernel command line parameters, then fix it. How is a bootloader supposed to know what the set of malicious kernel command line

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 5:16 PM, Matthew Garrett wrote: > On Tue, Apr 3, 2018 at 5:15 PM Linus Torvalds > > wrote: >> On Tue, Apr 3, 2018 at 5:10 PM, Matthew Garrett wrote: >> > >> >> Exactly like EVERY OTHER KERNEL CONFIG

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 2:06 AM, Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 4:59 PM, Matthew Garrett wrote: >> >> Ok. So we can build distribution kernels that *always* have this on, and to >> turn it off you have to disable Secure Boot and

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 5:15 PM Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 5:10 PM, Matthew Garrett wrote: > > > >> Exactly like EVERY OTHER KERNEL CONFIG OPTION. > > > > So your argument is that we should make the user experience worse?

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 5:10 PM, Matthew Garrett wrote: > >> Exactly like EVERY OTHER KERNEL CONFIG OPTION. > > So your argument is that we should make the user experience worse? Without > some sort of verified boot mechanism, lockdown is just security theater. > There's no good

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 5:08 PM Linus Torvalds wrote: > Still better than telling them to disable/enable secure boot, which > they may or may not even be able to to. Users who can boot a non-vendor Linux distribution on their platform can disable Secure Boot 100% of

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 5:06 PM Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 4:59 PM, Matthew Garrett wrote: > > > > Ok. So we can build distribution kernels that *always* have this on, and to > > turn it off you have to disable Secure Boot and

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 5:04 PM, Matthew Garrett wrote: > > 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 >

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:59 PM, Matthew Garrett wrote: > > Ok. So we can build distribution kernels that *always* have this on, and to > turn it off you have to disable Secure Boot and install a different kernel. Bingo. Exactly like EVERY OTHER KERNEL CONFIG OPTION. Just like

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 5:02 PM Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 4:47 PM, Matthew Garrett wrote: > >> Another way of looking at this: if lockdown is a good idea to enable > >> when you booted using secure boot, then why isn't it a

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:47 PM, Matthew Garrett wrote: >> Another way of looking at this: if lockdown is a good idea to enable >> when you booted using secure boot, then why isn't it a good idea when >> you *didn't* boot using secure boot? > > Because it's then trivial to

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:55 PM Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 4:45 PM, Matthew Garrett wrote: > >> Be honest now. It wasn't generally users who clamored for it. > > > > If you ask a user whether they want a system that lets an

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:56 PM, David Howells wrote: => > 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

Re: [GIT PULL] Kernel lockdown for secure boot

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

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:45 PM, Matthew Garrett wrote: >> Be honest now. It wasn't generally users who clamored for it. > > If you ask a user whether they want a system that lets an attacker replace > their kernel or one that doesn't, what do you think their answer is likely >

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:39 PM, David Howells wrote: > 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

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:39 PM Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 4:26 PM, Linus Torvalds > wrote: > > > > Magically changing kernel behavior depending on some subtle and often > > unintentional bootup behavior detail is

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:26 PM Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 4:17 PM, Matthew Garrett wrote: > > > > 1) Secure Boot is intended to permit the construction of a boot chain that > > only runs ring 0 code that the user considers

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:12 PM, David Howells wrote: > 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

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:26 PM, Linus Torvalds wrote: > > Magically changing kernel behavior depending on some subtle and often > unintentional bootup behavior detail is completely idiotic. Another way of looking at this: if lockdown is a good idea to enable when

Re: [GIT PULL] Kernel lockdown for secure boot

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

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:12 PM, David Howells wrote: > > What use is secure boot if processes run as root can subvert your kernel? Stop this idiocy. The above has now been answered multiple times, several different ways. The "point" of secure boot may be that you had no

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:17 PM, Matthew Garrett wrote: > > 1) Secure Boot is intended to permit the construction of a boot chain that > only runs ring 0 code that the user considers trustworthy No. That may be *one* intention, for some people. It's not an a-priori one for the

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:08 PM Linus Torvalds wrote: > That's not the right approach to begin with, Matthew. The onus is on > *you* to explain why you tied them together, not on others to explain > to you - over and over - that they have nothing to do with each

Re: [GIT PULL] Kernel lockdown for secure boot

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

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 4:08 PM, Linus Torvalds wrote: > > This discussion is over until you give an actual honest-to-goodness > reason for why you tied the two features together. No more "Why not?" > crap. Side note: I suspect the reason is something along the

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 3:53 PM Andy Lutomirski wrote: > On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett wrote: > > Lockdown is clearly useful without Secure Boot (and I intend to deploy it > > that way for various things), but I still don't understand why you

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett wrote: > > Lockdown is clearly useful without Secure Boot (and I intend to deploy it > that way for various things), but I still don't understand why you feel > that the common case of booting a kernel from a boot chain that's

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett wrote: > On Tue, Apr 3, 2018 at 3:46 PM Linus Torvalds > > wrote: > >> For example, I love signed kernel modules. The fact that I love them >> has absolutely zero to do with secure boot, though.

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 3:46 PM Linus Torvalds wrote: > For example, I love signed kernel modules. The fact that I love them > has absolutely zero to do with secure boot, though. There is > absolutely no linkage between the two issues: I use (self-)signed > kernel

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 3:39 PM, Andy Lutomirski wrote: > > Sure. I have no problem with having an upstream kernel have a > lockdown feature, although I think that feature should distinguish > between reads and writes. But I don't think the upstream kernel > should apply a patch

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 3:32 PM, David Howells wrote: > 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

Re: [GIT PULL] Kernel lockdown for secure boot

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

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 12:49 PM, David Howells wrote: > 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

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 12:29 PM, Matthew Garrett wrote: > On Tue, Apr 3, 2018 at 9:46 AM Andy Lutomirski wrote: >> On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett wrote: >> > A kernel that allows users arbitrary access to ring 0 is just an >>

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, 3 Apr 2018, Ard Biesheuvel wrote: > [snip] Thanks for the input -- there are obviously still issues to be resolved. I'll now not be pushing these to Linus for v4.17. -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 2:21 PM Al Viro wrote: > On Tue, Apr 03, 2018 at 09:08:54PM +, Matthew Garrett wrote: > > If you don't want Secure Boot, turn it off. If you want Secure Boot, use a > > kernel that behaves in a way that actually increases your security. > That

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 2:26 PM Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 2:08 PM, Matthew Garrett wrote: > > > > Secure Boot ensures that the firmware will only load signed bootloaders. If > > a signed bootloader loads a kernel that's

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 2:08 PM, Matthew Garrett wrote: > > Secure Boot ensures that the firmware will only load signed bootloaders. If > a signed bootloader loads a kernel that's effectively an unsigned > bootloader, there's no point in using Secure Boot Bullshit. I may want

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 03, 2018 at 09:08:54PM +, Matthew Garrett wrote: > > The fact is, some hardware pushes secure boot pretty hard. That has > > *nothing* to do with some "lockdown" mode. > > Secure Boot ensures that the firmware will only load signed bootloaders. If > a signed bootloader loads a

  1   2   >