* Re: [GIT PULL] Kernel lockdown for secure boot
From: David Howells @ 2018-04-03 23:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: dhowells, Andy Lutomirski, Matthew Garrett, Ard Biesheuvel,
James Morris, Alan Cox, Greg Kroah-Hartman,
Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli,
LSM List, Linux API, Kees Cook, linux-efi
In-Reply-To: <CA+55aFxKzxdRZthzaokaGPAsWCp3a-p3aVfJSutF+9Fp9sbaVA@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> The same thing is true of some lockdown patch. Maybe it's a good thing
> in general. But whether it's a good thing is _entirely_ independent of
> any secure boot issue. I can see using secure boot without it, but I
> can very much also see using lockdown without secure boot.
>
> The two things are simply entirely orthogonal. They have _zero_
> overlap. I'm not seeing why they'd be linked at all in any way.
I'm not sure I agree. Here's my reasoning:
(1) Lockdown mode really needs to activated during kernel boot, before
userspace has a chance to run, otherwise there's a window of opportunity
in which the kernel *isn't* locked down.
(2) If the kernel isn't booted in secure boot mode, then there's the
opportunity to tamper before the kernel even starts booting.
(3) There doesn't seem any point in booting in secure boot mode if you don't
protect the running kernel image against tampering. What does it mean to
be in "secure boot mode" in that case? If the kernel can be tampered
with, it would seem to be, by definition, insecure.
(4) You can't validly promise the next OS you kexec that *it* is started in
secure boot mode if you don't stop your image from being tampered with.
Note that this doesn't prevent a compromised kernel from lying to the
next OS.
(5) Tampering with a running kernel can be achieved in a variety of ways:
loading of arbitrary modules, loading of modified firmware, direct access
to devices that can effect DMA, writing to /dev/mem, ...
(6) We need to be able to load modules and firmware, but these can be signed,
hashed or measured so we have some idea of their provenance - but signing
can be worked around if, say, /dev/mem is writable.
(7) If you told the BIOS[*] that you want to be in secure boot mode, then the
kernel should honour that and try to prevent tampering with the image.
(8) Turning lockdown mode on if the kernel is booted in secure boot seems to
be the way to achieve this.
(9) BIOS vendors can blacklist any of the components - say the SHIM - to
prevent an insecure kernel from being used to compromise and kexec
another OS.
Note that I've provided a kernel command line parameter that will turn
lockdown mode on arbitrarily - but that can be turned off by editing the
parameters in grub.cfg, say.
David
[*] Yeah, I know, this is an x86-centric view.
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Linus Torvalds @ 2018-04-03 23:39 UTC (permalink / raw)
To: Matthew Garrett
Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List,
Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook,
linux-efi
In-Reply-To: <CA+55aFyWNok1K-Jo3TQAXGXHvFOTvuOb-Hw977B9RGjBa7prrg@mail.gmail.com>
On Tue, Apr 3, 2018 at 4:26 PM, Linus Torvalds
<torvalds@linux-foundation.org> 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 you booted using secure boot, then why isn't it a good idea when
you *didn't* boot using secure boot?
That's the flip side of this whole argument.
People who boot without secure boot may be wanting all the same
protections. Maybe you have to disable it when you build your own
kernel, for example. Does that suddenly mean that lockdown is now a
bad idea?
And if it does, explain it. Explain why it's a bad idea to enable
without secure boot, but is a good idea to enable *with* secure boot.
In other words: explain the tie-in.
Because I really don't see it. All I see is illogical blathering that
tries to conflate issues that have nothing to do with each other.
Please explain to me why a distro or a user would want lockdown to be
disabled just because the user didn't use secure boot, but suddenly if
it's booted on another machine, it's not just a good idea, but
mandatory in your world view?
Honestly, if I were a distro maintainer, the *last* thing I'd want is
the kernel to act fundamentally differently in some security context
depending on some random bootup condition.
Linus
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Andy Lutomirski @ 2018-04-03 23:42 UTC (permalink / raw)
To: David Howells
Cc: Andy Lutomirski, Matthew Garrett, Ard Biesheuvel, James Morris,
Alan Cox, Linus Torvalds, Greg Kroah-Hartman,
Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli,
LSM List, Linux API, Kees Cook, linux-efi
In-Reply-To: <10232.1522797179@warthog.procyon.org.uk>
On Tue, Apr 3, 2018 at 4:12 PM, David Howells <dhowells@redhat.com> wrote:
> Andy Lutomirski <luto@kernel.org> wrote:
>
>> I'm having a very, very hard time coming up with a scenario where I
>> can "trust" something if an attacker can get root but can't modify the
>> running kernel image but I can't "trust" something if the attacker
>> can [modify the running kernel image].
>
> (I think the above is what you meant)
>
> Let's go at this a different way. How do you decide you can trust something
> in this context? You compare it to something. Signing it, keeping a hash
> whitelist, IMA - these are all ways of comparing something. Do you agree with
> that?
I trust or distrust a system as a whole. I don't make that decision
by comparing it to anything. I make it by evaluating how the system
works and deciding whether it's trustworthy.
>
> What use is secure boot if processes run as root can subvert your kernel?
>
Secure boot serves several purposes:
1. Anti-competitive purposes. It's intentionally difficult to run
non-Windows OSes on Windows ARM machines, for example.
2. Allowing me to use a stock UEFI machine to have a verified boot chain.
The latter has nothing whatsoever to do with CPL0. The former,
however, does. If I could easily write some Windows program to run
CPL0 code, then I could chainload Linux using the Windows image, and
I've subverted the purpose.
Cynical? Yes.
>> > There's no point bothering with UID/GID checking either.
>>
>> Give me a break. There's a *huge* difference between a system where
>> only root can load unsigned modules and a system where anyone can load
>> unsigned modules.
>
> I don't think we've ever advocated letting just anyone load a module.
>
> But my point is that if you can modify the running kernel, you can nullify all
> security checks, including UID/GID checks.
>
>> > However, if /dev/mem can be read, any root process can extract the session
>> > key for your disk.
>>
>> Any root process can read /dev/mapper/plaintext_disk, lockdown or otherwise.
>
> True - for now - and they can also access the mounted filesystem. But if they
> get their hands on your powered-off computer, no, they can't.
This is, IMO, a silly argument. You're saying that some bad guy has
managed to run code as root on my laptop. Then, next week, the bad
guy steals my laptop while it's powered off, and Lockdown is supposed
to protect me against that bad guy. If this happens, I've already
lost completely, lockdown or no.
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Matthew Garrett @ 2018-04-03 23:45 UTC (permalink / raw)
To: Linus Torvalds
Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox,
Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man,
jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <CA+55aFyWNok1K-Jo3TQAXGXHvFOTvuOb-Hw977B9RGjBa7prrg@mail.gmail.com>
On Tue, Apr 3, 2018 at 4:26 PM Linus Torvalds
<torvalds@linux-foundation.org>
wrote:
> On Tue, Apr 3, 2018 at 4:17 PM, Matthew Garrett <mjg59@google.com> 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 actual user.
Secure Boot is intended to *permit* that. Without Secure Boot you're unable
to do that. Some users want that. Some users don't.
> > 2) Allowing arbitrary user code to run in ring 0 without affirmative
> > consent on the part of the user is therefore incompatible with the
goals of
> > Secure Boot
> Again, that has absolutely zero relevance.
> Those goals are not the *users* goals.
> 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
to be?
> If the user actually wanted it, and is asking for it, he can enable
> it. Independently of secure boot, which the user generally has little
> control over.
How? If the bootloader will boot kernels that don't impose this restriction
then an attacker just replaces whatever's enabling that feature. And, uh,
seriously, I've been asking for *years* for someone to point me at a PC on
the market that doesn't give the user control over Secure Boot, but Shim
was expressly designed to ensure that the user would have the ability to
enroll additional trusted keys (or disable signature validation entirely),
so which cases are you thinking of where the user doesn't have control?
> > 3) This patchset provides a mechanism to alter the behaviour of the
kernel
> > such that it is significantly more difficult for arbitrary user code to
run
> > in ring 0 without affirmative user consent
> That difficulty already exists, the new thing isn't somehow related to
> that at all.
> Look at our "uyou can only load modules if you're root" rules. Or the
> "you can only load modules if they are signed".
> See a pattern there? They don't magically enable themselves (or
> disable themselves) depending on whether you booted with secure boot
> or not.
What's the benefit of "You can only load modules if they are signed" if
root is able to just overwrite that policy bit in the kernel? The split
between unprivileged users and root is real, but right now module
signatures are theater - there's no significant security benefit from them.
But the reason to tie this to Secure Boot is that without that an attacker
who has root can just replace the kernel on disk (or patch the bootloader
to live-patch the kernel on boot, and yes that's an attack we've seen in
the real world), so while it's a feature that is arguably beneficial under
all circumstances it's a feature that only has significant benefit if you
have some way to actually validate what you're booting in the first place.
> > 4) Providing a mechanism for automatically enabling this behaviour when
> > running in a context that is intended to restrict access to ring 0 is a
> > rational thing to do, because otherwise it is difficult to achieve the
> > objective in (1)
> No. See why it's *NOT* rational, as explained already several times.
> Magically changing kernel behavior depending on some subtle and often
> unintentional bootup behavior detail is completely idiotic.
> It would be idiotic if it was that "check kernel module signatures"
> check. This is no less idiotic.
> Seriously, listen to your own arguments. If they don't make sense for
> checking kernel module signatures, why the hell would they make sense
> for something like lockdown.
> THE TWO THINGS ARE ENTIRELY INDEPENDENT.
Again, what is your proposed mechanism for ensuring that off the shelf
systems can be configured in a way that makes this possible?
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Matthew Garrett @ 2018-04-03 23:47 UTC (permalink / raw)
To: Linus Torvalds
Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox,
Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man,
jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <CA+55aFx9u-O81MwSq8zpb+MKaWYjYvtEcFu1NLP1_s63ED6_3Q@mail.gmail.com>
On Tue, Apr 3, 2018 at 4:39 PM Linus Torvalds
<torvalds@linux-foundation.org>
wrote:
> On Tue, Apr 3, 2018 at 4:26 PM, Linus Torvalds
> <torvalds@linux-foundation.org> 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 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 circumvent and the restrictions aren't worth
the benefit.
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Andy Lutomirski @ 2018-04-03 23:48 UTC (permalink / raw)
To: David Howells
Cc: Linus Torvalds, Andy Lutomirski, Matthew Garrett, Ard Biesheuvel,
James Morris, Alan Cox, Greg Kroah-Hartman,
Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli,
LSM List, Linux API, Kees Cook, linux-efi
In-Reply-To: <10718.1522798745@warthog.procyon.org.uk>
On Tue, Apr 3, 2018 at 4:39 PM, David Howells <dhowells@redhat.com> wrote:
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> The same thing is true of some lockdown patch. Maybe it's a good thing
>> in general. But whether it's a good thing is _entirely_ independent of
>> any secure boot issue. I can see using secure boot without it, but I
>> can very much also see using lockdown without secure boot.
>>
>> The two things are simply entirely orthogonal. They have _zero_
>> overlap. I'm not seeing why they'd be linked at all in any way.
>
> I'm not sure I agree. Here's my reasoning:
>
> (1) Lockdown mode really needs to activated during kernel boot, before
> userspace has a chance to run, otherwise there's a window of opportunity
> in which the kernel *isn't* locked down.
That's simply not true. A sensible verified boot chain (a la Chrome
OS) is likely to load, as one verified chunk, a kernel and initramfs.
Then initramfs can flip on lockdown all by itself before it enables
networking or any other attack vectors.
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Linus Torvalds @ 2018-04-03 23:55 UTC (permalink / raw)
To: Matthew Garrett
Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List,
Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook,
linux-efi
In-Reply-To: <CACdnJutZFKX+izBxRYbyxefT5KrKhVV0XsymU=vBhywd+TOE3A@mail.gmail.com>
On Tue, Apr 3, 2018 at 4:45 PM, Matthew Garrett <mjg59@google.com> 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
> to be?
Goddamnit.
We both know what the answer will be.
And it will have *nothing* to do with secure boot.
So *you* be honest now.
Because you clearly aren't.
Seriously. Go ask that question to a random person:
"Do you want a system that lets an attacker replace their kernel or
one that doesn't?"
and don't ask anything else.
Do you really think they'll answer "no, I don't want an attacker to
replace my kernel, but only if I booted with secure boot"?
Honestly, now.
> Again, what is your proposed mechanism for ensuring that off the shelf
> systems can be configured in a way that makes this possible?
If you think lockdown is a good idea, and you enabled it, then IT IS ENABLED.
No idiotic "secure boot or not" garbage.
Because secure boot or not isn't *relevant*.
Christ, we already have things like
- CONFIG_STRICT_KERNEL_RWX
- CONFIG_STRICT_DEVMEM
- CONFIG_HARDENED_USERCOPY
- CONFIG_MODULE_SIG_ALL (and friends)
and absolutely *NONE* of them depend on whether the kernel was booted
with secure boot or not.
And I claim that it would be completely idiotic and broken if they did.
And - not entirely unrelated - I claim that it is COMPLETELY IDIOTIC
AND BROKEN to make some new "lockdown" option depend on it.
Comprende?
Really. Your arguments make no sense. They are all fundamentally
broken for the simple reason that all your "but secure boot implies
XYZ" are pure and utter bullshit, because all your arguments are valid
whether secure boot happened or not.
See? Secure boot has *NOTHING* do to with anything. It has nothing to
do with loading only signed kernel modules. It has nothing to do with
your lockdown patches.
Either lockdown is good or not. It's that simple. But the goodness has
nothing to do with secure boot.
Linus
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: David Howells @ 2018-04-03 23:56 UTC (permalink / raw)
To: Linus Torvalds
Cc: dhowells, Matthew Garrett, Andrew Lutomirski, Ard Biesheuvel,
James Morris, Alan Cox, Greg Kroah-Hartman,
Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli,
LSM List, Linux API, Kees Cook, linux-efi
In-Reply-To: <CA+55aFyWNok1K-Jo3TQAXGXHvFOTvuOb-Hw977B9RGjBa7prrg@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Be honest now. It wasn't generally users who clamored for it.
> ...
> If the user actually wanted it, and is asking for it, he can enable it.
>From the distributions' point of view, this is a rubbish argument.
Most users haven't even given this a moment's thought, aren't even aware of
the issues, don't even know to ask and, for them, it makes no difference.
They trust their distribution to deal with stuff they don't know about.
David
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Linus Torvalds @ 2018-04-03 23:58 UTC (permalink / raw)
To: David Howells
Cc: Matthew Garrett, Andrew Lutomirski, Ard Biesheuvel, James Morris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List,
Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook,
linux-efi
In-Reply-To: <11444.1522799762@warthog.procyon.org.uk>
On Tue, Apr 3, 2018 at 4:56 PM, David Howells <dhowells@redhat.com> 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 about.
Right.
Like perhaps trusting the distribution to just enable all those
security measures _regaredless_ of whether they booted in using secure
boot or not?
See?
If lockdown breaks something, the distro would need to fix it
regardless of secure boot.
So why is the enablement dependent on it again?
I'm not arguing "lockdown shouldn't be on".
I'm arguing "lockdown being on or off has _nothing_ to do with whether
the machine was booted in EFI mode with secure boot or not".
You don't seem to get it.
Linus
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Matthew Garrett @ 2018-04-03 23:59 UTC (permalink / raw)
To: Linus Torvalds
Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox,
Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man,
jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <CA+55aFwVUmjZ+Swe9xUdDOEE+EOoaU3dh7BcrH74BOLCi8y_Kw@mail.gmail.com>
On Tue, Apr 3, 2018 at 4:55 PM Linus Torvalds
<torvalds@linux-foundation.org>
wrote:
> On Tue, Apr 3, 2018 at 4:45 PM, Matthew Garrett <mjg59@google.com> 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
> > to be?
> Goddamnit.
> We both know what the answer will be.
> And it will have *nothing* to do with secure boot.
Right, because they care about outcome rather than mechanism. Secure Boot
is the mechanism we have to make that outcome possible.
> > Again, what is your proposed mechanism for ensuring that off the shelf
> > systems can be configured in a way that makes this possible?
> If you think lockdown is a good idea, and you enabled it, then IT IS
ENABLED.
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.
Or we can build distribution kernels that only have this on when you're
booting in a context that makes sense, and you can disable it by just
disabling Secure Boot (by running mokutil --disable-validation) and not
have to install a new kernel. Which outcome do you prefer?
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Linus Torvalds @ 2018-04-04 0:02 UTC (permalink / raw)
To: Matthew Garrett
Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List,
Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook,
linux-efi
In-Reply-To: <CACdnJutkO9dgz=HZpPRR9PZC=+cHh97dRUiGB+D3gruZr6U9Kg@mail.gmail.com>
On Tue, Apr 3, 2018 at 4:47 PM, Matthew Garrett <mjg59@google.com> 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 circumvent and the restrictions aren't worth
> the benefit.
Bullshit.
If there those restrictions cause problems, they need to be fixed regardless.
In fact, from a debuggability standpoint, you want to find the
problems early, on those kernel development machines that had secure
boot explicitly turned off because it's such a pain.
And if they can't be fixed, then the user is going to disable lockdown
regardless of how he booted the machine.
In no situation is "depending on how you booted" a good choice.
Either you can enable it or you can't. If you can, good. And if you
can't, it has nothing to do with secure boot.
Linus
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Matthew Garrett @ 2018-04-04 0:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox,
Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man,
jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <CA+55aFxZN_p_cU94z7QN8=HnPanRrpRHH7UUkOBaFDSjfrivnQ@mail.gmail.com>
On Tue, Apr 3, 2018 at 5:02 PM Linus Torvalds
<torvalds@linux-foundation.org>
wrote:
> On Tue, Apr 3, 2018 at 4:47 PM, Matthew Garrett <mjg59@google.com> 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 circumvent and the restrictions aren't
worth
> > the benefit.
> Bullshit.
> If there those restrictions cause problems, they need to be fixed
regardless.
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
kernel?
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Linus Torvalds @ 2018-04-04 0:06 UTC (permalink / raw)
To: Matthew Garrett
Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List,
Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook,
linux-efi
In-Reply-To: <CACdnJuvqQQ+hidokY5GA7g-yrAs5-358it0cs+m_d4RFDMuB_w@mail.gmail.com>
On Tue, Apr 3, 2018 at 4:59 PM, Matthew Garrett <mjg59@google.com> 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 all the ones that I've mentioned several times.
Or, like a lot of other kernel options, maybe have a way to just
disable it on the kernel command line, and let the user know about it.
That would still be better than disabling secure boot entirely in your
world view, so it's (a) more convenient and (b) better.
Again, in no case does it make sense to tie it into "how did we boot".
Because that's just inconvenient for everybody.
Linus
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Linus Torvalds @ 2018-04-04 0:08 UTC (permalink / raw)
To: Matthew Garrett
Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List,
Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook,
linux-efi
In-Reply-To: <CACdnJutOAPTmPm6dmHiw4+8rj=M7B1SiCkPaRZLmi9-CCuRyNg@mail.gmail.com>
On Tue, Apr 3, 2018 at 5:04 PM, Matthew Garrett <mjg59@google.com> 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
> majority of users from being vulnerable to an attacker just DMAing over the
> kernel?
.. if that ends up being a real problem, then you print a warning and
tell people to use the kernel command line to disable things.
And if it's a big and common problem, then the answer may be that
lockdown has to be entirely OFF by default, and you instead just tell
people to enable it manually with a kernel command line option.
Still better than telling them to disable/enable secure boot, which
they may or may not even be able to to.
Linus
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Matthew Garrett @ 2018-04-04 0:10 UTC (permalink / raw)
To: Linus Torvalds
Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox,
Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man,
jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <CA+55aFwJBGCr-anrdV9N63fUH4V_QJqgr0_fJyHhH=fuqGAoog@mail.gmail.com>
On Tue, Apr 3, 2018 at 5:06 PM Linus Torvalds
<torvalds@linux-foundation.org>
wrote:
> On Tue, Apr 3, 2018 at 4:59 PM, Matthew Garrett <mjg59@google.com> 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.
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 reason to enable it unless you have some mechanism for
verifying that you booted something you trust.
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Matthew Garrett @ 2018-04-04 0:12 UTC (permalink / raw)
To: Linus Torvalds
Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox,
Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man,
jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <CA+55aFzH6doC2F1xBitPRwTZtbiCO_mX+QVcJ8HQCdsdD3Vmpg@mail.gmail.com>
On Tue, Apr 3, 2018 at 5:08 PM Linus Torvalds
<torvalds@linux-foundation.org>
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 the time.
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Linus Torvalds @ 2018-04-04 0:15 UTC (permalink / raw)
To: Matthew Garrett
Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List,
Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook,
linux-efi
In-Reply-To: <CACdnJuvFqXGLsAv1Km3MmdssHBfuH5-C_vG3A4eq4Yuj0HhFBA@mail.gmail.com>
On Tue, Apr 3, 2018 at 5:10 PM, Matthew Garrett <mjg59@google.com> 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 reason to enable it unless you have some mechanism for
> verifying that you booted something you trust.
Wow. Way to snip the rest of the email where I told you what the
solution was. Let me repeat it here, since you so conveniently missed
it and deleted it:
>> Or, like a lot of other kernel options, maybe have a way to just
>> disable it on the kernel command line, and let the user know about it.
>>
>> That would still be better than disabling secure boot entirely in your
>> world view, so it's (a) more convenient and (b) better.
Matthew, it's simply not worth continuing talking with you.
I'll just not pull this crap, and vendors that you convince to do
stupid things have only themselves to blame.
You clearly have an agenda, and are not willing to look at arguments
against your idiotic choices.
Linus
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Matthew Garrett @ 2018-04-04 0:16 UTC (permalink / raw)
To: Linus Torvalds
Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox,
Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man,
jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <CA+55aFzYbpRAdma0PvqE+9ygySuKzNKByqOzzMufBoovXVnfPw@mail.gmail.com>
On Tue, Apr 3, 2018 at 5:15 PM Linus Torvalds
<torvalds@linux-foundation.org>
wrote:
> On Tue, Apr 3, 2018 at 5:10 PM, Matthew Garrett <mjg59@google.com> 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 reason to enable it unless you have some mechanism for
> > verifying that you booted something you trust.
> Wow. Way to snip the rest of the email where I told you what the
> solution was. Let me repeat it here, since you so conveniently missed
> it and deleted it:
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.
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Jann Horn @ 2018-04-04 0:17 UTC (permalink / raw)
To: Linus Torvalds
Cc: Matthew Garrett, Andrew Lutomirski, David Howells, Ard Biesheuvel,
James Morris, Alan Cox, Greg Kroah-Hartman,
Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli,
LSM List, Linux API, Kees Cook, linux-efi
In-Reply-To: <CA+55aFwJBGCr-anrdV9N63fUH4V_QJqgr0_fJyHhH=fuqGAoog@mail.gmail.com>
On Wed, Apr 4, 2018 at 2:06 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Apr 3, 2018 at 4:59 PM, Matthew Garrett <mjg59@google.com> 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 all the ones that I've mentioned several times.
>
> Or, like a lot of other kernel options, maybe have a way to just
> disable it on the kernel command line, and let the user know about it.
>
> That would still be better than disabling secure boot entirely in your
> world view, so it's (a) more convenient and (b) better.
>
> Again, in no case does it make sense to tie it into "how did we boot".
> Because that's just inconvenient for everybody.
Without taking a stance regarding whether I think that kernel lockdown
makes sense, I think Matthew's point is this:
If you don't have lockdown, secure boot doesn't provide a benefit,
since an attacker could just modify the init binary instead of messing
with your kernel.
If you have secure boot, you want lockdown to prevent chainloading
into a backdoored version of the real OS.
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Andy Lutomirski @ 2018-04-04 0:18 UTC (permalink / raw)
To: Matthew Garrett
Cc: Linus Torvalds, Andrew Lutomirski, David Howells, Ard Biesheuvel,
James Morris, Alan Cox, Greg Kroah-Hartman,
Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli,
LSM List, Linux API, Kees Cook, linux-efi
In-Reply-To: <CACdnJuv-VpdhjEe1cMysdHb6Oy67jQqg-_TVHbUrOfH9GmCVvg@mail.gmail.com>
On Tue, Apr 3, 2018 at 5:16 PM, Matthew Garrett <mjg59@google.com> wrote:
> On Tue, Apr 3, 2018 at 5:15 PM Linus Torvalds
> <torvalds@linux-foundation.org>
> wrote:
>> On Tue, Apr 3, 2018 at 5:10 PM, Matthew Garrett <mjg59@google.com> 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 reason to enable it unless you have some mechanism for
>> > verifying that you booted something you trust.
>
>> Wow. Way to snip the rest of the email where I told you what the
>> solution was. Let me repeat it here, since you so conveniently missed
>> it and deleted it:
>
> 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.
if your secure boot-enabled bootloader can't prevent a bad guy from
using malicious kernel command line parameters, then fix it.
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Matthew Garrett @ 2018-04-04 0:19 UTC (permalink / raw)
To: luto
Cc: Linus Torvalds, David Howells, Ard Biesheuvel, jmorris, Alan Cox,
Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man,
jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <CALCETrVF2vSvoz0sBCrfMKcbJ4hmi=1QJZbUxdvurkimVXr0nA@mail.gmail.com>
On Tue, Apr 3, 2018 at 5:18 PM Andy Lutomirski <luto@kernel.org> 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 parameters is?
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: David Howells @ 2018-04-04 0:22 UTC (permalink / raw)
To: Linus Torvalds
Cc: dhowells, Matthew Garrett, Andrew Lutomirski, Ard Biesheuvel,
James Morris, Alan Cox, Greg Kroah-Hartman,
Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli,
LSM List, Linux API, Kees Cook, linux-efi
In-Reply-To: <CA+55aFzH6doC2F1xBitPRwTZtbiCO_mX+QVcJ8HQCdsdD3Vmpg@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> ... use the kernel command line to disable things.
An attacker could then modify grub.cfg, say, and cause a reboot (or wait for
the next reboot) to disable lockdown:-/
And whilst we could also distribute a non-locked-down variant of the kernel as
an alternative, the attacker could install and boot that instead since we
can't lock package installation down very easily since it doesn't impinge
directly on the running kernel.
Unfortunately, it's hard to come up with a disablement mechanism in the kernel
that an attacker can't also make use of:-/
David
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Andy Lutomirski @ 2018-04-04 0:23 UTC (permalink / raw)
To: Jann Horn
Cc: Linus Torvalds, Matthew Garrett, Andrew Lutomirski, David Howells,
Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman,
Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli,
LSM List, Linux API, Kees Cook, linux-efi
In-Reply-To: <CAG48ez1MRsDGoea5MwGTXK6R0LJy9u0mX-1VrSSskwnV98kEjQ@mail.gmail.com>
On Tue, Apr 3, 2018 at 5:17 PM, Jann Horn <jannh@google.com> wrote:
> On Wed, Apr 4, 2018 at 2:06 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> On Tue, Apr 3, 2018 at 4:59 PM, Matthew Garrett <mjg59@google.com> 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 all the ones that I've mentioned several times.
>>
>> Or, like a lot of other kernel options, maybe have a way to just
>> disable it on the kernel command line, and let the user know about it.
>>
>> That would still be better than disabling secure boot entirely in your
>> world view, so it's (a) more convenient and (b) better.
>>
>> Again, in no case does it make sense to tie it into "how did we boot".
>> Because that's just inconvenient for everybody.
>
> Without taking a stance regarding whether I think that kernel lockdown
> makes sense, I think Matthew's point is this:
> If you don't have lockdown, secure boot doesn't provide a benefit,
> since an attacker could just modify the init binary instead of messing
> with your kernel.
> If you have secure boot, you want lockdown to prevent chainloading
> into a backdoored version of the real OS.
I don't think that's the argument here. Secure boot can be used to
protect initramfs, since initramfs comes from the secure boot-verified
bootloader. That verified initramfs can protect the init binary.
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. (There doesn't seem to be a
real benefit to preventing Linux from chainloading Linux, since the
chainloaded Linux is unlikely to let the attacker do much that the
original rooted Linux kernel wouldn't have allowed.) In particular,
Microsoft, which de facto controls most of the secure boot key
ecosystem, doesn't want Windows to be chainloaded without having its
signature verified.
I admit I'm not quite sure why Microsoft considers this important.
They already require a TPM for all new systems, and any important
secrets can be sealed by the TPM such that a maliciously chainloaded
Windows kernel couldn't access those secrets. But secure boot
predates the WHQL TPM requirement if I remember correctly, and I
suspect that we're seeing leftover requirements from
secure-boot-but-no-TPM era.
^ permalink raw reply
* Re: [PATCH] mm/page_alloc: don't reserve ZONE_HIGHMEM for ZONE_MOVABLE request
From: Joonsoo Kim @ 2018-04-04 0:24 UTC (permalink / raw)
To: Michal Hocko
Cc: Andrew Morton, Vlastimil Babka, Mel Gorman, Johannes Weiner,
Aneesh Kumar K . V, Minchan Kim, Linux Memory Management List,
LKML, Joonsoo Kim, linux-api
In-Reply-To: <20170914132452.d5klyizce72rhjaa@dhcp22.suse.cz>
Hello, Michal.
Sorry for a really long delay.
2017-09-14 22:24 GMT+09:00 Michal Hocko <mhocko@kernel.org>:
> [Sorry for a later reply]
>
> On Wed 06-09-17 13:35:25, Joonsoo Kim wrote:
>> From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>>
>> Freepage on ZONE_HIGHMEM doesn't work for kernel memory so it's not that
>> important to reserve.
>
> I am still not convinced this is a good idea. I do agree that reserving
> memory in both HIGHMEM and MOVABLE is just wasting memory but removing
> the reserve from the highmem as well will result that an oom victim will
> allocate from lower zones and that might have unexpected side effects.
Looks like you are confused.
This patch only affects the situation that ZONE_HIGHMEM and ZONE_MOVABLE is
used at the same time. In that case, before this patch, ZONE_HIGHMEM has
reserve for GFP_HIGHMEM | GFP_MOVABLE request, but, with this patch, no reserve
in ZONE_HIGHMEM for GFP_HIGHMEM | GFP_MOVABLE request. This perfectly
matchs with your hope. :)
> Can we simply leave HIGHMEM reserve and only remove it from the movable
> zone if both are present?
There is no higher zone than ZONE_MOVABLE so ZONE_MOVABLE has no reserve
with/without this patch. To save memory, we need to remove the reserve in
ZONE_HIGHMEM.
Thanks.
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Linus Torvalds @ 2018-04-04 0:25 UTC (permalink / raw)
To: Matthew Garrett
Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List,
Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook,
linux-efi
In-Reply-To: <CACdnJuv-VpdhjEe1cMysdHb6Oy67jQqg-_TVHbUrOfH9GmCVvg@mail.gmail.com>
On Tue, Apr 3, 2018 at 5:16 PM, Matthew Garrett <mjg59@google.com> 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 don't think the patchset is viable at all in that case.
No way will any sane distribution take it, potentially breaking a lot
of machines, and have no way to unbreak them except for "oh, btw, you
have to disable secure boot to get things to work again".
That would be insane.
So you'd better allow some command line options.
One reasonable option may be to just disable lockdown by default (to
make machines work reliably), and then have a "if you're anal about
security, add 'lockdown' to the kernel command line".
People who care about this already need to check the secure boot
status, so this would be just one more thing they'd check.
Linus
^ permalink raw reply
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