> 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
> 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
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
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
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, 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
> > >
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
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
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
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
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.
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.
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
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
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
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
> > >
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
> > >
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/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 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
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
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, 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
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
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 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
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
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
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
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
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
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, 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
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
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
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
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
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
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
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
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 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
> 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
> 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
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
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
> 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
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,
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, 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
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.
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.
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
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
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
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
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
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
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:
>
> ---
>
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:
>
> ---
>
86 matches
Mail list logo
