.
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?
--
To unsub
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.
--
To unsubscribe fro
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
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 of trust.
>> >
>> > You don't have a cha
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
>> > overfeatured bootloader. Why would you want secure
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 body of a message to
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 assumes you *can* turn th
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 effectively an unsigned
> > bootloader, there's no point
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 to know that I'm run
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 ker
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?
> >
> > Then turn it off, or build a self-signed kernel that doesn't do t
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?
>
> Then turn it off, or build a self-signed kernel that doesn't do this?
Umm. So you asked a question, and then when you got an answer
On Tue, Apr 3, 2018 at 1:53 PM Linus Torvalds
wrote:
> On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett wrote:
> > On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski wrote:
> >> Can you explain that much more clearly? I'm asking why booting via
> >> UEFI Secure Boot should enable lockdown, and I do
On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett wrote:
> On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski wrote:
>> Can you explain that much more clearly? I'm asking why booting via
>> UEFI Secure Boot should enable lockdown, and I don't see what this has
>> to do with kexec. And "someone blackl
On Sat, Mar 31, 2018 at 02:19:44PM +0200, Hans de Goede wrote:
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index fddc5f706fd2..1a5ea950f58f 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -455,6 +455,7 @@ int __init efi_mem_desc_lookup(
Andy Lutomirski wrote:
> >>> A kernel that allows users arbitrary access to ring 0 is just an
> >>> overfeatured bootloader. Why would you want secure boot in that case?
> >>
> >> To get a chain of trust.
> >
> > You don't have a chain of trust that you can trust in that case.
> >
> Please elabor
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
> > overfeatured bootloader. Why would you want secure boot in that case?
> To get a chain of trust. I can provisio
On Tue, Apr 3, 2018 at 12:01 PM, Andy Lutomirski wrote:
> On Tue, Apr 3, 2018 at 11:45 AM, Kees Cook wrote:
>> On Tue, Apr 3, 2018 at 9:45 AM, Andy Lutomirski wrote:
>>> On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett wrote:
On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski wrote:
> Can
> On Apr 3, 2018, at 10:16 AM, 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 of trust.
>
> You don't have a chain of trust that y
On Tue, Apr 3, 2018 at 11:45 AM, Kees Cook wrote:
> On Tue, Apr 3, 2018 at 9:45 AM, Andy Lutomirski wrote:
>> On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett wrote:
>>> On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski wrote:
Can you explain that much more clearly? I'm asking why booting via
On Tue, Apr 03, 2018 at 08:07:11PM +0200, Lukas Wunner wrote:
> On Tue, Apr 03, 2018 at 10:33:25AM +0200, Hans de Goede wrote:
> > I asked Peter Jones for suggestions how to extract this during boot and
> > he suggested seeing if there was a copy of the firmware in the
> > EFI_BOOT_SERVICES_CODE me
In your next patches please Cc the folks I added for future review as well.
We don't have a mailing list for the firmware API so I just tend to Cc
who I think should help review when needed.
On Tue, Apr 03, 2018 at 10:33:25AM +0200, Hans de Goede wrote:
> Hi Luis,
>
> Thank you for the review.
>
On Tue, Apr 3, 2018 at 9:45 AM, Andy Lutomirski wrote:
> On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett wrote:
>> On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski wrote:
>>> Can you explain that much more clearly? I'm asking why booting via
>>> UEFI Secure Boot should enable lockdown, and I don'
On Tue, Apr 03, 2018 at 10:33:25AM +0200, Hans de Goede wrote:
> I asked Peter Jones for suggestions how to extract this during boot and
> he suggested seeing if there was a copy of the firmware in the
> EFI_BOOT_SERVICES_CODE memory segment, which it turns out there is.
>
> My patch to add suppor
Andy Lutomirski wrote:
> > A kernel that allows users arbitrary access to ring 0 is just an
> > overfeatured bootloader. Why would you want secure boot in that case?
>
> To get a chain of trust.
You don't have a chain of trust that you can trust in that case.
David
--
To unsubscribe from this
On Tue, 2018-04-03 at 18:07 +0200, Daniel Kiper wrote:
> On Tue, Apr 03, 2018 at 08:44:41AM -0700, James Bottomley wrote:
> >
> > On Tue, 2018-04-03 at 16:39 +0200, Daniel Kiper wrote:
> > >
> > > Initialize UEFI secure boot state during dom0 boot. Otherwise the
> > > kernel may not even know tha
On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett wrote:
> On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski wrote:
>> Can you explain that much more clearly? I'm asking why booting via
>> UEFI Secure Boot should enable lockdown, and I don't see what this has
>> to do with kexec. And "someone blackl
On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski wrote:
> Can you explain that much more clearly? I'm asking why booting via
> UEFI Secure Boot should enable lockdown, and I don't see what this has
> to do with kexec. And "someone blacklist[ing] your key in the
> bootloader" sounds like a politica
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 patch just sucks in general.
>> >
>> > Yes - but that's what Alexe
On Tue, Apr 03, 2018 at 08:44:41AM -0700, James Bottomley wrote:
> On Tue, 2018-04-03 at 16:39 +0200, Daniel Kiper wrote:
> > Initialize UEFI secure boot state during dom0 boot. Otherwise the
> > kernel
> > may not even know that it runs on secure boot enabled platform.
> >
> > Signed-off-by: Danie
On Tue, 2018-04-03 at 16:39 +0200, Daniel Kiper wrote:
> Initialize UEFI secure boot state during dom0 boot. Otherwise the
> kernel
> may not even know that it runs on secure boot enabled platform.
>
> Signed-off-by: Daniel Kiper
> ---
> arch/x86/xen/efi.c| 57
> +++
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 patch just sucks in general.
> >
> > Yes - but that's what Alexei Starovoitov specified. bpf kind of sucks since
> > it gives you
[re-added cc's, I think. Sorry, I think I failed to use the gmane
gateway correctly there.]
On Tue, Apr 3, 2018 at 12:06 AM, David Howells wrote:
> Andy Lutomirski wrote:
>
>> This is an attempt at a review. I'm replying here because I can't find the
>> actual relevant patch emails.
>
> This w
Initialize UEFI secure boot state during dom0 boot. Otherwise the kernel
may not even know that it runs on secure boot enabled platform.
Signed-off-by: Daniel Kiper
---
arch/x86/xen/efi.c| 57 +
drivers/firmware/efi/libstub/secureboot.c |
(+ Andy and Kees so they can respond to the thread)
On 31 March 2018 at 12:20, David Howells wrote:
> James Morris wrote:
>
>> Are there any known coverage gaps now?
>
> I've covered all the ones I know about.
>
Andy (and Kees) responded to this without keeping all the cc's. Given
that I share
Hi Luis,
Thank you for the review.
On 03-04-18 01:23, Luis R. Rodriguez wrote:
On Sat, Mar 31, 2018 at 02:19:44PM +0200, Hans de Goede wrote:
Just like with PCI options ROMs, which we save in the setup_efi_pci*
functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself
sometime
80 matches
Mail list logo
