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 disab
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 verificati
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 fu
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 k
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 using secure boot without it, but I
On Tue 2018-04-03 21:08:54, Matthew Garrett wrote:
> On Tue, Apr 3, 2018 at 2:01 PM Linus Torvalds
>
> wrote:
>
> > On Tue, Apr 3, 2018 at 1:54 PM, Matthew Garrett wrote:
> > >
> > >> .. maybe you don't *want* secure boot, but it's been pushed in your
> > >> face by people with an agenda?
> > >
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 Lutomirski wrote:
> >>> >
> >>> >> "bpf: Restrict kern
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 pa
>
> 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
> so
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 bootloader"? Once I'm able to install an
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 lot of
real world cases.
> 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
> kerne
> 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
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 devolved horribly, I'm g
On Wed, 04 Apr 2018 00:12:04 +
Matthew Garrett wrote:
> 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 th
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" state into three le
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 names right now.)
> >
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 write to arbitrary ke
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.)
> Choi
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: Status quo in distro and mainline
> kernels
>> > Verifi
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.
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
> bootloader or kernel t
> 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 netw
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 a
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
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 enables it, or your
bo
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 you
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:
> >> > A kernel that allows users arbitrary access to r
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:
>>> > Theodore Y. Ts'o wrote:
>>> >
>>> > > Whoa. Why
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
disabled.
> This has been rebutted over
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:
>> > Theodore Y. Ts'o wrote:
>> >
>> > > Whoa. Why doesn't lockdown prevent kexec? Put another away, why
>> > > is
On Wed, Apr 4, 2018 at 9:17 AM, 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 names right now.)
>>
>> LOCKDOWN_NONE: normal be
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: Perception of security improvement
that'
+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 example, can be used to modify kernel me
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 are fearful that Linux could b
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,
> > module signature
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 defaults are really horrible defautls for real technical
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
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 this, but then when
David Howells writes:
> 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
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
LOCK
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.
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 secure boot state across ke
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
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 afrai
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 Secure UEFI contex
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 ci
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
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 signatu
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
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
> can
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 bootloader supposed to
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
.
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)
> Verified Boot on, l
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.
> N
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 Boot off, lockdown on: Perception of security improv
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 the kernel is locked
>>> >> down":
>>> >> This p
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 time it comes to ups
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)
You're doing some
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? Why not enable it
> by default then?
>
> And if "tur
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? Why not enable it
> by default then?
Because it do
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? Why not enable it
by default then?
And if "turn off secure boot" really is the accepted - and actuially
used - wo
On Tue, Apr 3, 2018 at 5:33 PM Linus Torvalds
wrote:
> In contrast, the generic distros can't enable it anyway if it breaks
> random hardware. And it wouldn't be about secure boot or not, but
> about the random hardware choice.
The generic distros have been shipping this policy for the past 5 y
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
Chromebooks etc.
But a chome O
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 don't think the patc
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* have this on, and to
>>> turn it off you have to disable 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 kernel as
an alternative, the att
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 parameters is?
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 OPTION.
>> >
>> > So your argument is that we should make the user experie
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 install a different kernel.
>
> Bingo.
>
> Exactly li
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?
Without
> > some sort of verified boot mechanism, lockdo
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 reason to enable it
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 the time.
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 install a different
kernel.
> Bingo.
> Exactly l
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
> majority of users from bei
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 all the ones that
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 good idea when
> >> you *didn't* boot using secure b
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 circumvent and the restri
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 attacker
replace
> > their kernel or one that doesn't
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 about.
Right.
Like
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
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
> to be?
Goddamnit.
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 boot issue. I can see using secure boot without it, but
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 completely idiotic.
> Another way of looking at this: if lockd
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 trustworthy
> No.
> That may be *one* intention, fo
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 can't "trust" something if the attacker
>>
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 you booted using secure boot, the
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
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 choice, or there was
no
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 actual user.
> 2)
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 other.
1) Secure Boot is intended
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
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 lines of "there
are political reason
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 feel
> > that the common case of 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 widely
> trusted derive
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. There is
>> absolutely no linkage between the two issu
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 modules simply because I think it
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 that ties any of
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 for determining that trust can be compro
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
1 - 100 of 134 matches
Mail list logo
