> I'm actually not talking about UEFI storage, just the UEFI secure boot
> database. I think we might come up with a viable model for adding keys
> from a UEFI variable that isn't part of the secure boot database.
You also need to be able to remove or not trust the existing ones
including the Mic
On Fri, 2018-08-17 at 10:42 -0500, Justin Forbes wrote:
> On Fri, Aug 17, 2018 at 9:58 AM, James Bottomley
> wrote:
> > On Fri, 2018-08-17 at 09:24 +0100, David Howells wrote:
[...]
> > > We also don't necessarily want to encourage ordinary users to
> > > fiddle with the system key databases unles
On Fri, Aug 17, 2018 at 9:58 AM, James Bottomley
wrote:
> On Fri, 2018-08-17 at 09:24 +0100, David Howells wrote:
>> James Bottomley wrote:
>>
>> > > > As a step by step process, I agree. However, I think we can
>> > > > automate it to the point where you install a package and it
>> > > > says "
On Fri, 2018-08-17 at 09:24 +0100, David Howells wrote:
> James Bottomley wrote:
>
> > > > As a step by step process, I agree. However, I think we can
> > > > automate it to the point where you install a package and it
> > > > says "insert your yubikey" every time you upgrade the kernel
> > >
>
James Bottomley wrote:
> > > As a step by step process, I agree. However, I think we can
> > > automate it to the point where you install a package and it says
> > > "insert your yubikey" every time you upgrade the kernel
> >
> > That's a very bad idea. You train people to unlock their private
On Thu, 2018-08-16 at 21:31 +0100, David Howells wrote:
> James Bottomley wrote:
>
> > As a step by step process, I agree. However, I think we can
> > automate it to the point where you install a package and it says
> > "insert your yubikey" every time you upgrade the kernel
>
> That's a very b
James Bottomley wrote:
> As a step by step process, I agree. However, I think we can automate
> it to the point where you install a package and it says "insert your
> yubikey" every time you upgrade the kernel
That's a very bad idea. You train people to unlock their private key on
request. It
On Thu, 2018-08-16 at 16:56 +, David Laight wrote:
> From: James Bottomley
> > Sent: 16 August 2018 16:57
> > On Thu, 2018-08-16 at 16:49 +0100, David Howells wrote:
> > > James Bottomley wrote:
> > >
> > > > > The problem with that is that it means you can't load third
> > > > > party module
From: James Bottomley
> Sent: 16 August 2018 16:57
> On Thu, 2018-08-16 at 16:49 +0100, David Howells wrote:
> > James Bottomley wrote:
> >
> > > > The problem with that is that it means you can't load third party
> > > > modules - such as the NVidia driver. That's fine if you
> > > > absolutely
On Thu, 2018-08-16 at 16:49 +0100, David Howells wrote:
> James Bottomley wrote:
>
> > > The problem with that is that it means you can't load third party
> > > modules - such as the NVidia driver. That's fine if you
> > > absolutely reject the right of people to produce third party
> > > driver
James Bottomley wrote:
> > The problem with that is that it means you can't load third party
> > modules - such as the NVidia driver. That's fine if you absolutely
> > reject the right of people to produce third party drivers for the
> > Linux kernel and absolutely require that they open and ups
On Thu, 2018-08-16 at 08:16 -0700, James Bottomley wrote:
> So your lawyers tell you if you sign a third party module for your
> kernel then you could get blamed for the damage it causes? So this
> whole escapade is about Red Hat trying to evade legal responsibility
> for allowing customers to loa
On Thu, 2018-08-16 at 14:51 +0100, David Howells wrote:
> Linus Torvalds wrote:
>
> > > I see that module signing code trusts only builtin keys and
> > > not the keys in secondary_trusted_keys keyring.
> >
> > This, I think, makes sense.
> >
> > It basically says: we don't allow modules that we
On Thu, 2018-08-16 at 15:43 +0100, David Howells wrote:
> James Bottomley wrote:
>
> > I've told you several times you can't use the secure boot keys for
> > any form
> > of trust beyond boot,
>
> Yes - and you've been told several times that you're wrong.
>
> As far as I can tell, you seem to
James Bottomley wrote:
> I've told you several times you can't use the secure boot keys for any form
> of trust beyond boot,
Yes - and you've been told several times that you're wrong.
As far as I can tell, you seem to think that whilst keys from the UEFI storage
could be used to verify a hacke
On Thu, 2018-08-16 at 13:13 +0100, David Howells wrote:
> Vivek Goyal wrote:
>
> > Now this patch changed it to trusting builtin_trusted_keys by
> > default, and all the other keys go to secondary_trusted_keys
> > kerying. And that probably explains why it broke.
> >
> > So checking for keys in
Linus Torvalds wrote:
> > I see that module signing code trusts only builtin keys and
> > not the keys in secondary_trusted_keys keyring.
>
> This, I think, makes sense.
>
> It basically says: we don't allow modules that weren't built with the
> kernel. Adding a new key later and signing a modu
Vivek Goyal wrote:
> Now this patch changed it to trusting builtin_trusted_keys by default,
> and all the other keys go to secondary_trusted_keys kerying. And that
> probably explains why it broke.
>
> So checking for keys in both the keyrings makes sense to me.
>
> I am wondering why did we h
On 08/16/18 at 08:52am, Dave Young wrote:
> On 08/15/18 at 01:42pm, Vivek Goyal wrote:
> > On Wed, Aug 15, 2018 at 07:27:33PM +0200, Yannik Sembritzki wrote:
> > > Would this be okay?
> >
> > [ CC dave young, Baoquan, Justin Forbes]
> >
> > Hi Yannik,
> >
> > I am reading that bug and wondering
On 08/15/18 at 01:42pm, Vivek Goyal wrote:
> On Wed, Aug 15, 2018 at 07:27:33PM +0200, Yannik Sembritzki wrote:
> > Would this be okay?
>
> [ CC dave young, Baoquan, Justin Forbes]
>
> Hi Yannik,
>
> I am reading that bug and wondering that what broke it. It used to work,
> so some change broke
On 15.08.2018 23:57, Vivek Goyal wrote:
> Aha.., so that's your real problem. You are trying to load VirtualBox
> module and that will not load even if you take ownership of platform
> by adding your key and sign module with that key.
>
> So this patch still will not fix the problem you are facing.
On Wed, Aug 15, 2018 at 11:31:27PM +0200, Yannik Sembritzki wrote:
> On 15.08.2018 23:13, James Bottomley wrote:
> > Consider a UEFI system for which a user has taken ownership, but which
> > has some signed ROMs which are UEFI secure boot verified. Simply to
> > get their system to boot the user
On Wed, 2018-08-15 at 17:52 -0400, Vivek Goyal wrote:
> On Wed, Aug 15, 2018 at 02:13:17PM -0700, James Bottomley wrote:
> > On Wed, 2018-08-15 at 23:08 +0200, Yannik Sembritzki wrote:
> > > On 15.08.2018 22:47, Linus Torvalds wrote:
> > > > It basically says: we don't allow modules that weren't bu
On Wed, Aug 15, 2018 at 02:13:17PM -0700, James Bottomley wrote:
> On Wed, 2018-08-15 at 23:08 +0200, Yannik Sembritzki wrote:
> > On 15.08.2018 22:47, Linus Torvalds wrote:
> > > It basically says: we don't allow modules that weren't built with
> > > the kernel. Adding a new key later and signing
On 15.08.2018 23:40, James Bottomley wrote:
> What about the key linking patches:
>
> https://lkml.org/lkml/2018/5/2/989
>
> ? They allow you to insert your own binary key into bzimage and then
> resign the resulting blob for secure boot. It's a fairly painless
> process. The patches have been la
On Wed, 2018-08-15 at 23:31 +0200, Yannik Sembritzki wrote:
> On 15.08.2018 23:13, James Bottomley wrote:
> > Consider a UEFI system for which a user has taken ownership, but
> > which
> > has some signed ROMs which are UEFI secure boot verified. Simply
> > to
> > get their system to boot the user
On 15.08.2018 23:13, James Bottomley wrote:
> Consider a UEFI system for which a user has taken ownership, but which
> has some signed ROMs which are UEFI secure boot verified. Simply to
> get their system to boot the user will be forced to add the ODM key to
> the UEFI db ... and I'm sure in that
On Wed, Aug 15, 2018 at 2:08 PM Yannik Sembritzki wrote:
>
> IMO, this is not okay. The layer of trust should extend from the bottom
> (user-provisioned platform key) up. Only trusting the kernel builtin key
> later on (wrt. kernel modules) contradicts this principal.
This module loading case is
On Wed, 2018-08-15 at 23:08 +0200, Yannik Sembritzki wrote:
> On 15.08.2018 22:47, Linus Torvalds wrote:
> > It basically says: we don't allow modules that weren't built with
> > the kernel. Adding a new key later and signing a module with it
> > violates that premise.
>
> Considering the followin
On 15.08.2018 22:47, Linus Torvalds wrote:
> It basically says: we don't allow modules that weren't built with the
> kernel. Adding a new key later and signing a module with it violates
> that premise.
Considering the following scenario:
A user is running a distro kernel, which is built by the dis
On Wed, 2018-08-15 at 13:47 -0700, Linus Torvalds wrote:
> On Wed, Aug 15, 2018 at 12:49 PM Vivek Goyal
> wrote:
> >
> > I see that module signing code trusts only builtin keys and
> > not the keys in secondary_trusted_keys keyring.
>
> This, I think, makes sense.
>
> It basically says: we don'
On Wed, Aug 15, 2018 at 12:49 PM Vivek Goyal wrote:
>
> I see that module signing code trusts only builtin keys and
> not the keys in secondary_trusted_keys keyring.
This, I think, makes sense.
It basically says: we don't allow modules that weren't built with the
kernel. Adding a new key later a
On Wed, Aug 15, 2018 at 09:06:13PM +0200, Yannik Sembritzki wrote:
>
> > I am wondering why did we have to split this keyring to begin with.
> > So there are use cases where we want to trust builtin keys but
> > not the ones which came from other places (UEFI secure boot db, or
> > user loaded on
> I am wondering why did we have to split this keyring to begin with.
> So there are use cases where we want to trust builtin keys but
> not the ones which came from other places (UEFI secure boot db, or
> user loaded one)?
>
"User loaded ones" should not be trusted in general to prevent rootkit
On Wed, Aug 15, 2018 at 01:42:47PM -0400, Vivek Goyal wrote:
> On Wed, Aug 15, 2018 at 07:27:33PM +0200, Yannik Sembritzki wrote:
> > Would this be okay?
>
> [ CC dave young, Baoquan, Justin Forbes]
>
> Hi Yannik,
>
> I am reading that bug and wondering that what broke it. It used to work,
> so
> I am reading that bug and wondering that what broke it. It used to work,
> so some change broke it.
>
> Previously, I think all the keys used to go in system keyring and it
> used to work. Is it somehow because of split in builtin keyring and
> secondary system keyring. Could it be that fedora
On Wed, Aug 15, 2018 at 11:19 AM Yannik Sembritzki wrote:
>
> > No, I meant that it would have to go into the proper header files, and
> > also be used by verify_pkcs7_signature() and pkcs7_preparse() etc, so
> > that you could actually grep for this, and understand what it does.
> Thanks, Linus,
> No, I meant that it would have to go into the proper header files, and
> also be used by verify_pkcs7_signature() and pkcs7_preparse() etc, so
> that you could actually grep for this, and understand what it does.
Thanks, Linus, I'll take care of this right away.
This is my first patch and I'm no
On Wed, Aug 15, 2018 at 10:27 AM Yannik Sembritzki wrote:
>
> Would this be okay?
No, I meant that it would have to go into the proper header files, and
also be used by verify_pkcs7_signature() and pkcs7_preparse() etc, so
that you could actually grep for this, and understand what it does.
Right
On Wed, Aug 15, 2018 at 07:27:33PM +0200, Yannik Sembritzki wrote:
> Would this be okay?
[ CC dave young, Baoquan, Justin Forbes]
Hi Yannik,
I am reading that bug and wondering that what broke it. It used to work,
so some change broke it.
Justin said that we have been signing fedora kernels wi
I'm sorry, the sign-off was missing again (this is my first submission
to linux).
Signed-off-by: Yannik Sembritzki
Cc: sta...@vger.kernel.org
---
arch/x86/kernel/kexec-bzimage64.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/kexec-bzimage64.c
b/arch/x86
Would this be okay?
diff --git a/arch/x86/kernel/kexec-bzimage64.c
b/arch/x86/kernel/kexec-bzimage64.c
index 7326078e..2ba47e24 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -41,6 +41,9 @@
#define MIN_KERNEL_LOAD_ADDR 0x10
#define MIN_INITRD_LOAD
This needs more people involved, and at least a sign-off.
It looks ok, but I think we need a #define for the magical (void *)1UL
thing. I see the use in verify_pkcs7_signature(), but still.
Linus
On Wed, Aug 15, 2018 at 3:11 AM Yannik Sembritzki wrote:
>
> ---
> arch/x86/kernel
43 matches
Mail list logo
