* kexec_load(2) bypasses signature verification
@ 2015-06-15 3:50 ` Theodore Ts'o
0 siblings, 0 replies; 50+ messages in thread
From: Theodore Ts'o @ 2015-06-15 3:50 UTC (permalink / raw)
To: Eric Biederman, dhowells; +Cc: kexec, linux-kernel
>From experimentation and from looking at the sources, it appears that
the signature checking is only done in the kexec_file_load(2) system
all, and not in the kexec_load(2) system call. And I understand why
-- the signature is not sent from userspace to the kernel in the older
kexec_load(2) system call.
The problem is that if you use an old version of kexec, it will use
the old kexec_load(2) system call, and even though
CONFIG_KEXEC_VERIFY_SIG is enabled, kexec_load(2) will happily load an
unsigned kernel, and then "kexec -e" will happily boot into it.
Correct me if I am wrong, but this appears to be a hole in Secure Boot
you could drive a Mack Truck through.
(I noticed this because Debian is still using a kexec-tools from the
stone ages, version 2.0.7, and I was wondering **why** I was able to
kexec boot completely unsigned kernels.)
It would appear to me that if CONFIG_KEXEC_VERIFY_SIG is enabled, the
old kexec_load(2) system call should be disabled (and a warning be
placed in the Kconfig help that the user should have at least verision
2.X of kexec-tools if they enable this kernel option).
Am I missing something?
- Ted
^ permalink raw reply [flat|nested] 50+ messages in thread
* kexec_load(2) bypasses signature verification
@ 2015-06-15 3:50 ` Theodore Ts'o
0 siblings, 0 replies; 50+ messages in thread
From: Theodore Ts'o @ 2015-06-15 3:50 UTC (permalink / raw)
To: Eric Biederman, dhowells; +Cc: kexec, linux-kernel
From experimentation and from looking at the sources, it appears that
the signature checking is only done in the kexec_file_load(2) system
all, and not in the kexec_load(2) system call. And I understand why
-- the signature is not sent from userspace to the kernel in the older
kexec_load(2) system call.
The problem is that if you use an old version of kexec, it will use
the old kexec_load(2) system call, and even though
CONFIG_KEXEC_VERIFY_SIG is enabled, kexec_load(2) will happily load an
unsigned kernel, and then "kexec -e" will happily boot into it.
Correct me if I am wrong, but this appears to be a hole in Secure Boot
you could drive a Mack Truck through.
(I noticed this because Debian is still using a kexec-tools from the
stone ages, version 2.0.7, and I was wondering **why** I was able to
kexec boot completely unsigned kernels.)
It would appear to me that if CONFIG_KEXEC_VERIFY_SIG is enabled, the
old kexec_load(2) system call should be disabled (and a warning be
placed in the Kconfig help that the user should have at least verision
2.X of kexec-tools if they enable this kernel option).
Am I missing something?
- Ted
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-15 3:50 ` Theodore Ts'o
(?)
@ 2015-06-15 9:11 ` Dave Young
2015-06-15 9:28 ` Petr Tesarik
-1 siblings, 1 reply; 50+ messages in thread
From: Dave Young @ 2015-06-15 9:11 UTC (permalink / raw)
To: Theodore Ts'o, Eric Biederman, dhowells, kexec
On 06/14/15 at 11:50pm, Theodore Ts'o wrote:
> From experimentation and from looking at the sources, it appears that
> the signature checking is only done in the kexec_file_load(2) system
> all, and not in the kexec_load(2) system call. And I understand why
> -- the signature is not sent from userspace to the kernel in the older
> kexec_load(2) system call.
>
> The problem is that if you use an old version of kexec, it will use
> the old kexec_load(2) system call, and even though
> CONFIG_KEXEC_VERIFY_SIG is enabled, kexec_load(2) will happily load an
> unsigned kernel, and then "kexec -e" will happily boot into it.
>
> Correct me if I am wrong, but this appears to be a hole in Secure Boot
> you could drive a Mack Truck through.
>
> (I noticed this because Debian is still using a kexec-tools from the
> stone ages, version 2.0.7, and I was wondering **why** I was able to
> kexec boot completely unsigned kernels.)
>
> It would appear to me that if CONFIG_KEXEC_VERIFY_SIG is enabled, the
> old kexec_load(2) system call should be disabled (and a warning be
> placed in the Kconfig help that the user should have at least verision
> 2.X of kexec-tools if they enable this kernel option).
IMO it is fine to disable old syscall incase CONFIG_KEXEC_VERIFY=y
Add Vivek to the loop.
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-15 9:11 ` Dave Young
@ 2015-06-15 9:28 ` Petr Tesarik
0 siblings, 0 replies; 50+ messages in thread
From: Petr Tesarik @ 2015-06-15 9:28 UTC (permalink / raw)
To: Dave Young; +Cc: dhowells, kexec, Theodore Ts'o, Eric Biederman
On Mon, 15 Jun 2015 17:11:00 +0800
Dave Young <dyoung@redhat.com> wrote:
> On 06/14/15 at 11:50pm, Theodore Ts'o wrote:
> > From experimentation and from looking at the sources, it appears that
> > the signature checking is only done in the kexec_file_load(2) system
> > all, and not in the kexec_load(2) system call. And I understand why
> > -- the signature is not sent from userspace to the kernel in the older
> > kexec_load(2) system call.
> >
> > The problem is that if you use an old version of kexec, it will use
> > the old kexec_load(2) system call, and even though
> > CONFIG_KEXEC_VERIFY_SIG is enabled, kexec_load(2) will happily load an
> > unsigned kernel, and then "kexec -e" will happily boot into it.
> >
> > Correct me if I am wrong, but this appears to be a hole in Secure Boot
> > you could drive a Mack Truck through.
> >
> > (I noticed this because Debian is still using a kexec-tools from the
> > stone ages, version 2.0.7, and I was wondering **why** I was able to
> > kexec boot completely unsigned kernels.)
> >
> > It would appear to me that if CONFIG_KEXEC_VERIFY_SIG is enabled, the
> > old kexec_load(2) system call should be disabled (and a warning be
> > placed in the Kconfig help that the user should have at least verision
> > 2.X of kexec-tools if they enable this kernel option).
>
> IMO it is fine to disable old syscall incase CONFIG_KEXEC_VERIFY=y
Definitely. It is not possible to to sign all code passed through
kexec_load(2), at least not without giving kexec-tools the private part
of the key (which would effectively destroy the goal of Secure Boot).
Whenever signature verification is required, kexec_load(2) must be
disabled.
Petr Tesarik
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-15 3:50 ` Theodore Ts'o
@ 2015-06-15 12:14 ` Josh Boyer
-1 siblings, 0 replies; 50+ messages in thread
From: Josh Boyer @ 2015-06-15 12:14 UTC (permalink / raw)
To: Theodore Ts'o, Eric Biederman, David Howells, kexec,
Linux-Kernel@Vger. Kernel. Org
On Sun, Jun 14, 2015 at 11:50 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> From experimentation and from looking at the sources, it appears that
> the signature checking is only done in the kexec_file_load(2) system
> all, and not in the kexec_load(2) system call. And I understand why
> -- the signature is not sent from userspace to the kernel in the older
> kexec_load(2) system call.
>
> The problem is that if you use an old version of kexec, it will use
> the old kexec_load(2) system call, and even though
> CONFIG_KEXEC_VERIFY_SIG is enabled, kexec_load(2) will happily load an
> unsigned kernel, and then "kexec -e" will happily boot into it.
>
> Correct me if I am wrong, but this appears to be a hole in Secure Boot
> you could drive a Mack Truck through.
Yes, which is why most of the distro vendors carry an out-of-tree
patch that disables the old kexec in an SB setup. It would be nice if
we could merge said patches. However, they depend on Matthew's
secure_modules/trusted_kernel/<whatever name that works> patchset
which has gotten little movement since we came up with a tentative
agreement at LPC 2013.
> (I noticed this because Debian is still using a kexec-tools from the
> stone ages, version 2.0.7, and I was wondering **why** I was able to
> kexec boot completely unsigned kernels.)
>
> It would appear to me that if CONFIG_KEXEC_VERIFY_SIG is enabled, the
> old kexec_load(2) system call should be disabled (and a warning be
> placed in the Kconfig help that the user should have at least verision
> 2.X of kexec-tools if they enable this kernel option).
>
> Am I missing something?
Those sound like fine suggestions to me.
josh
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-15 12:14 ` Josh Boyer
0 siblings, 0 replies; 50+ messages in thread
From: Josh Boyer @ 2015-06-15 12:14 UTC (permalink / raw)
To: Theodore Ts'o, Eric Biederman, David Howells, kexec,
Linux-Kernel@Vger. Kernel. Org
On Sun, Jun 14, 2015 at 11:50 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> From experimentation and from looking at the sources, it appears that
> the signature checking is only done in the kexec_file_load(2) system
> all, and not in the kexec_load(2) system call. And I understand why
> -- the signature is not sent from userspace to the kernel in the older
> kexec_load(2) system call.
>
> The problem is that if you use an old version of kexec, it will use
> the old kexec_load(2) system call, and even though
> CONFIG_KEXEC_VERIFY_SIG is enabled, kexec_load(2) will happily load an
> unsigned kernel, and then "kexec -e" will happily boot into it.
>
> Correct me if I am wrong, but this appears to be a hole in Secure Boot
> you could drive a Mack Truck through.
Yes, which is why most of the distro vendors carry an out-of-tree
patch that disables the old kexec in an SB setup. It would be nice if
we could merge said patches. However, they depend on Matthew's
secure_modules/trusted_kernel/<whatever name that works> patchset
which has gotten little movement since we came up with a tentative
agreement at LPC 2013.
> (I noticed this because Debian is still using a kexec-tools from the
> stone ages, version 2.0.7, and I was wondering **why** I was able to
> kexec boot completely unsigned kernels.)
>
> It would appear to me that if CONFIG_KEXEC_VERIFY_SIG is enabled, the
> old kexec_load(2) system call should be disabled (and a warning be
> placed in the Kconfig help that the user should have at least verision
> 2.X of kexec-tools if they enable this kernel option).
>
> Am I missing something?
Those sound like fine suggestions to me.
josh
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-15 12:14 ` Josh Boyer
@ 2015-06-15 13:17 ` Theodore Ts'o
-1 siblings, 0 replies; 50+ messages in thread
From: Theodore Ts'o @ 2015-06-15 13:17 UTC (permalink / raw)
To: Josh Boyer
Cc: Eric Biederman, David Howells, kexec,
Linux-Kernel@Vger. Kernel. Org
On Mon, Jun 15, 2015 at 08:14:19AM -0400, Josh Boyer wrote:
> Yes, which is why most of the distro vendors carry an out-of-tree
> patch that disables the old kexec in an SB setup. It would be nice if
> we could merge said patches. However, they depend on Matthew's
> secure_modules/trusted_kernel/<whatever name that works> patchset
> which has gotten little movement since we came up with a tentative
> agreement at LPC 2013.
Signed modules is in, though, right? And the fact that we have
CONFIG_SIGNED_PE_FILE_VERIFICATION means we're doing unatural file
signatures w/o using ELF, which I thought was the basis of Linus's
accusation that Red Hat was performing intimate/physical acts with
Microsoft. :-)
I would have thought those were the nasty bits to get in; out of
curiosity, what's still missing?
Regards,
- Ted
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-15 13:17 ` Theodore Ts'o
0 siblings, 0 replies; 50+ messages in thread
From: Theodore Ts'o @ 2015-06-15 13:17 UTC (permalink / raw)
To: Josh Boyer
Cc: David Howells, kexec, Eric Biederman,
Linux-Kernel@Vger. Kernel. Org
On Mon, Jun 15, 2015 at 08:14:19AM -0400, Josh Boyer wrote:
> Yes, which is why most of the distro vendors carry an out-of-tree
> patch that disables the old kexec in an SB setup. It would be nice if
> we could merge said patches. However, they depend on Matthew's
> secure_modules/trusted_kernel/<whatever name that works> patchset
> which has gotten little movement since we came up with a tentative
> agreement at LPC 2013.
Signed modules is in, though, right? And the fact that we have
CONFIG_SIGNED_PE_FILE_VERIFICATION means we're doing unatural file
signatures w/o using ELF, which I thought was the basis of Linus's
accusation that Red Hat was performing intimate/physical acts with
Microsoft. :-)
I would have thought those were the nasty bits to get in; out of
curiosity, what's still missing?
Regards,
- Ted
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-15 13:17 ` Theodore Ts'o
@ 2015-06-15 13:37 ` Josh Boyer
-1 siblings, 0 replies; 50+ messages in thread
From: Josh Boyer @ 2015-06-15 13:37 UTC (permalink / raw)
To: Theodore Ts'o, Eric Biederman, David Howells, kexec,
Linux-Kernel@Vger. Kernel. Org
On Mon, Jun 15, 2015 at 9:17 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Mon, Jun 15, 2015 at 08:14:19AM -0400, Josh Boyer wrote:
>> Yes, which is why most of the distro vendors carry an out-of-tree
>> patch that disables the old kexec in an SB setup. It would be nice if
>> we could merge said patches. However, they depend on Matthew's
>> secure_modules/trusted_kernel/<whatever name that works> patchset
>> which has gotten little movement since we came up with a tentative
>> agreement at LPC 2013.
>
> Signed modules is in, though, right? And the fact that we have
Yes.
> CONFIG_SIGNED_PE_FILE_VERIFICATION means we're doing unatural file
> signatures w/o using ELF, which I thought was the basis of Linus's
> accusation that Red Hat was performing intimate/physical acts with
> Microsoft. :-)
>
> I would have thought those were the nasty bits to get in; out of
> curiosity, what's still missing?
The bits that actually read Secure Boot state out of the UEFI
variables, and apply protections to the machine to avoid compromise
under the SB threat model. Things like disabling the old kexec,
enforcing module signatures at runtime, restricting various access
(like /dev/mem, /dev/kmem), adding certs in UEFI db to the system
keyring, and enforcing the UEFI dbx blacklist. So most of the patches
in Matthew's set relate to enforcement using the bits of functionality
already merged. They aren't even strictly tied to UEFI or SB, but
some of the other patches distos carry are. We had tentative
agreement even from Linus on much of this (his words were along the
lines of "create a flag and use the flag"), but it's failed to
actually get carried in any tree for a few reasons.
josh
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-15 13:37 ` Josh Boyer
0 siblings, 0 replies; 50+ messages in thread
From: Josh Boyer @ 2015-06-15 13:37 UTC (permalink / raw)
To: Theodore Ts'o, Eric Biederman, David Howells, kexec,
Linux-Kernel@Vger. Kernel. Org
On Mon, Jun 15, 2015 at 9:17 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Mon, Jun 15, 2015 at 08:14:19AM -0400, Josh Boyer wrote:
>> Yes, which is why most of the distro vendors carry an out-of-tree
>> patch that disables the old kexec in an SB setup. It would be nice if
>> we could merge said patches. However, they depend on Matthew's
>> secure_modules/trusted_kernel/<whatever name that works> patchset
>> which has gotten little movement since we came up with a tentative
>> agreement at LPC 2013.
>
> Signed modules is in, though, right? And the fact that we have
Yes.
> CONFIG_SIGNED_PE_FILE_VERIFICATION means we're doing unatural file
> signatures w/o using ELF, which I thought was the basis of Linus's
> accusation that Red Hat was performing intimate/physical acts with
> Microsoft. :-)
>
> I would have thought those were the nasty bits to get in; out of
> curiosity, what's still missing?
The bits that actually read Secure Boot state out of the UEFI
variables, and apply protections to the machine to avoid compromise
under the SB threat model. Things like disabling the old kexec,
enforcing module signatures at runtime, restricting various access
(like /dev/mem, /dev/kmem), adding certs in UEFI db to the system
keyring, and enforcing the UEFI dbx blacklist. So most of the patches
in Matthew's set relate to enforcement using the bits of functionality
already merged. They aren't even strictly tied to UEFI or SB, but
some of the other patches distos carry are. We had tentative
agreement even from Linus on much of this (his words were along the
lines of "create a flag and use the flag"), but it's failed to
actually get carried in any tree for a few reasons.
josh
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-15 13:37 ` Josh Boyer
@ 2015-06-15 20:01 ` Theodore Ts'o
-1 siblings, 0 replies; 50+ messages in thread
From: Theodore Ts'o @ 2015-06-15 20:01 UTC (permalink / raw)
To: Josh Boyer
Cc: Eric Biederman, David Howells, kexec,
Linux-Kernel@Vger. Kernel. Org
On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
> The bits that actually read Secure Boot state out of the UEFI
> variables, and apply protections to the machine to avoid compromise
> under the SB threat model. Things like disabling the old kexec...
I don't have any real interest in using Secure Boot, but I *am*
interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to
have something similar to what we have with signed modules in terms of
CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
KEXEC_VERIFY_SIG. This would mean creating a separate flag
independent of the one Linus suggested for Secure Boot, but since we
have one for signed modules, we do have precedent for this sort of
thing.
- Ted
[1] Yes, it doesn't buy all that much, since if the system is rooted
the adversary can just replace the kernel in /boot and force a normal,
slower reboot, but the same could be said for signed modules --- the
adversary could just replace all of /boot/vmlinux-<kver> and
/lib/modules/<kver>. But both measures make it a tad more bit
difficult, especially for the adversary to do this replacement without
being noticed (for example linode will send me e-mail if the system
reboots normally, but not with a kexec-mediated reboot), and for cloud
systems where we don't have secure boot anyway, it's about the best we
can do.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-15 20:01 ` Theodore Ts'o
0 siblings, 0 replies; 50+ messages in thread
From: Theodore Ts'o @ 2015-06-15 20:01 UTC (permalink / raw)
To: Josh Boyer
Cc: David Howells, kexec, Eric Biederman,
Linux-Kernel@Vger. Kernel. Org
On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
> The bits that actually read Secure Boot state out of the UEFI
> variables, and apply protections to the machine to avoid compromise
> under the SB threat model. Things like disabling the old kexec...
I don't have any real interest in using Secure Boot, but I *am*
interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to
have something similar to what we have with signed modules in terms of
CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
KEXEC_VERIFY_SIG. This would mean creating a separate flag
independent of the one Linus suggested for Secure Boot, but since we
have one for signed modules, we do have precedent for this sort of
thing.
- Ted
[1] Yes, it doesn't buy all that much, since if the system is rooted
the adversary can just replace the kernel in /boot and force a normal,
slower reboot, but the same could be said for signed modules --- the
adversary could just replace all of /boot/vmlinux-<kver> and
/lib/modules/<kver>. But both measures make it a tad more bit
difficult, especially for the adversary to do this replacement without
being noticed (for example linode will send me e-mail if the system
reboots normally, but not with a kexec-mediated reboot), and for cloud
systems where we don't have secure boot anyway, it's about the best we
can do.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-15 20:01 ` Theodore Ts'o
@ 2015-06-16 19:38 ` Eric W. Biederman
-1 siblings, 0 replies; 50+ messages in thread
From: Eric W. Biederman @ 2015-06-16 19:38 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Josh Boyer, David Howells, kexec, Linux-Kernel@Vger. Kernel. Org,
Vivek Goyal, Dave Young, Petr Tesarik
Adding Vivek as he is the one who implemented kexec_file_load.
I was hoping he would respond to this thread, and it looks like he
simply has not ever been Cc'd.
Theodore Ts'o <tytso@mit.edu> writes:
> On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
>> The bits that actually read Secure Boot state out of the UEFI
>> variables, and apply protections to the machine to avoid compromise
>> under the SB threat model. Things like disabling the old kexec...
>
> I don't have any real interest in using Secure Boot, but I *am*
> interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to
> have something similar to what we have with signed modules in terms of
> CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
> KEXEC_VERIFY_SIG. This would mean creating a separate flag
> independent of the one Linus suggested for Secure Boot, but since we
> have one for signed modules, we do have precedent for this sort of
> thing.
My overall request with respect to kexec has been that we implement
things that make sense outside of the bizarre threat model of the Linux
folks who were talking about secure boot.
nI have not navigated the labyrinth of config options but having a way to
only boot signed things with kexec seems a completely sensible way to
operate in the context of signed images.
I don't know how much that will help given that actors with sufficient
resources have demonstrated the ability to steal private keys, but
assuming binary signing is an effective technique (or why else do it)
then having an option to limit kexec to only loading signed images seems
sensible.
Eric
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-16 19:38 ` Eric W. Biederman
0 siblings, 0 replies; 50+ messages in thread
From: Eric W. Biederman @ 2015-06-16 19:38 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Josh Boyer, Petr Tesarik, kexec, Linux-Kernel@Vger. Kernel. Org,
David Howells, Dave Young, Vivek Goyal
Adding Vivek as he is the one who implemented kexec_file_load.
I was hoping he would respond to this thread, and it looks like he
simply has not ever been Cc'd.
Theodore Ts'o <tytso@mit.edu> writes:
> On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
>> The bits that actually read Secure Boot state out of the UEFI
>> variables, and apply protections to the machine to avoid compromise
>> under the SB threat model. Things like disabling the old kexec...
>
> I don't have any real interest in using Secure Boot, but I *am*
> interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to
> have something similar to what we have with signed modules in terms of
> CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
> KEXEC_VERIFY_SIG. This would mean creating a separate flag
> independent of the one Linus suggested for Secure Boot, but since we
> have one for signed modules, we do have precedent for this sort of
> thing.
My overall request with respect to kexec has been that we implement
things that make sense outside of the bizarre threat model of the Linux
folks who were talking about secure boot.
nI have not navigated the labyrinth of config options but having a way to
only boot signed things with kexec seems a completely sensible way to
operate in the context of signed images.
I don't know how much that will help given that actors with sufficient
resources have demonstrated the ability to steal private keys, but
assuming binary signing is an effective technique (or why else do it)
then having an option to limit kexec to only loading signed images seems
sensible.
Eric
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-16 19:38 ` Eric W. Biederman
@ 2015-06-16 20:27 ` Vivek Goyal
-1 siblings, 0 replies; 50+ messages in thread
From: Vivek Goyal @ 2015-06-16 20:27 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Theodore Ts'o, Josh Boyer, David Howells, kexec,
Linux-Kernel@Vger. Kernel. Org, Dave Young, Petr Tesarik
On Tue, Jun 16, 2015 at 02:38:31PM -0500, Eric W. Biederman wrote:
>
> Adding Vivek as he is the one who implemented kexec_file_load.
> I was hoping he would respond to this thread, and it looks like he
> simply has not ever been Cc'd.
>
> Theodore Ts'o <tytso@mit.edu> writes:
>
> > On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
> >> The bits that actually read Secure Boot state out of the UEFI
> >> variables, and apply protections to the machine to avoid compromise
> >> under the SB threat model. Things like disabling the old kexec...
> >
> > I don't have any real interest in using Secure Boot, but I *am*
> > interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to
> > have something similar to what we have with signed modules in terms of
> > CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
> > KEXEC_VERIFY_SIG. This would mean creating a separate flag
> > independent of the one Linus suggested for Secure Boot, but since we
> > have one for signed modules, we do have precedent for this sort of
> > thing.
>
> My overall request with respect to kexec has been that we implement
> things that make sense outside of the bizarre threat model of the Linux
> folks who were talking about secure boot.
>
> nI have not navigated the labyrinth of config options but having a way to
> only boot signed things with kexec seems a completely sensible way to
> operate in the context of signed images.
>
> I don't know how much that will help given that actors with sufficient
> resources have demonstrated the ability to steal private keys, but
> assuming binary signing is an effective technique (or why else do it)
> then having an option to limit kexec to only loading signed images seems
> sensible.
I went through the mail chain on web and here are my thoughts.
- So yes, upstream does not have the logic which automatically disables
the old syscall (kexec_load()) on secureboot systems. Distributions
carry those patches.
- This KEXEC_VERIFY_SIG option only cotrols the behavior for
kexec_file_load() syscall and is not meant to directly affect any
behavior of old syscall (kexec_load()). I think I should have named
it KEXEC_FILE_VERIFY_SIG. Though help text makes it clear.
"Verify kernel signature during kexec_file_load() syscall".
- I think disabling old system call if KEXEC_VERIFY_SIG() is set
will break existing setup which use old system call by default, except
the case of secureboot system. And old syscall path is well tested
and new syscall might not be in a position to support all the corner
cases, atleast as of now.
Ted,
So looks like you are looking for a system/option where you just want to
always make use of kexec_file_load() and disable kexec_load(). This sounds
like you want a kernel where kexec_load() is compiled out and you want
only kexec_file_load() in.
Right now one can't do that becase kexec_file_load() depends on
CONFIG_KEXEC option.
I am wondering that how about making CONFIG_KEXEC_FILE_LOAD independent
of CONFIG_KEXEC. That way one can set CONFIG_KEXEC_VERIFY_SIG=y, and
only signed kernel can be kexeced on that system.
This should gel well with long term strategy of deprecating kexec_load()
at some point of time when kexec_file_load() is ready to completely
replace it.
Thanks
Vivek
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-16 20:27 ` Vivek Goyal
0 siblings, 0 replies; 50+ messages in thread
From: Vivek Goyal @ 2015-06-16 20:27 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Josh Boyer, Theodore Ts'o, Petr Tesarik, kexec,
Linux-Kernel@Vger. Kernel. Org, David Howells, Dave Young
On Tue, Jun 16, 2015 at 02:38:31PM -0500, Eric W. Biederman wrote:
>
> Adding Vivek as he is the one who implemented kexec_file_load.
> I was hoping he would respond to this thread, and it looks like he
> simply has not ever been Cc'd.
>
> Theodore Ts'o <tytso@mit.edu> writes:
>
> > On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
> >> The bits that actually read Secure Boot state out of the UEFI
> >> variables, and apply protections to the machine to avoid compromise
> >> under the SB threat model. Things like disabling the old kexec...
> >
> > I don't have any real interest in using Secure Boot, but I *am*
> > interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to
> > have something similar to what we have with signed modules in terms of
> > CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
> > KEXEC_VERIFY_SIG. This would mean creating a separate flag
> > independent of the one Linus suggested for Secure Boot, but since we
> > have one for signed modules, we do have precedent for this sort of
> > thing.
>
> My overall request with respect to kexec has been that we implement
> things that make sense outside of the bizarre threat model of the Linux
> folks who were talking about secure boot.
>
> nI have not navigated the labyrinth of config options but having a way to
> only boot signed things with kexec seems a completely sensible way to
> operate in the context of signed images.
>
> I don't know how much that will help given that actors with sufficient
> resources have demonstrated the ability to steal private keys, but
> assuming binary signing is an effective technique (or why else do it)
> then having an option to limit kexec to only loading signed images seems
> sensible.
I went through the mail chain on web and here are my thoughts.
- So yes, upstream does not have the logic which automatically disables
the old syscall (kexec_load()) on secureboot systems. Distributions
carry those patches.
- This KEXEC_VERIFY_SIG option only cotrols the behavior for
kexec_file_load() syscall and is not meant to directly affect any
behavior of old syscall (kexec_load()). I think I should have named
it KEXEC_FILE_VERIFY_SIG. Though help text makes it clear.
"Verify kernel signature during kexec_file_load() syscall".
- I think disabling old system call if KEXEC_VERIFY_SIG() is set
will break existing setup which use old system call by default, except
the case of secureboot system. And old syscall path is well tested
and new syscall might not be in a position to support all the corner
cases, atleast as of now.
Ted,
So looks like you are looking for a system/option where you just want to
always make use of kexec_file_load() and disable kexec_load(). This sounds
like you want a kernel where kexec_load() is compiled out and you want
only kexec_file_load() in.
Right now one can't do that becase kexec_file_load() depends on
CONFIG_KEXEC option.
I am wondering that how about making CONFIG_KEXEC_FILE_LOAD independent
of CONFIG_KEXEC. That way one can set CONFIG_KEXEC_VERIFY_SIG=y, and
only signed kernel can be kexeced on that system.
This should gel well with long term strategy of deprecating kexec_load()
at some point of time when kexec_file_load() is ready to completely
replace it.
Thanks
Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-16 20:27 ` Vivek Goyal
@ 2015-06-17 1:32 ` Eric W. Biederman
-1 siblings, 0 replies; 50+ messages in thread
From: Eric W. Biederman @ 2015-06-17 1:32 UTC (permalink / raw)
To: Vivek Goyal
Cc: Theodore Ts'o, Josh Boyer, David Howells, kexec,
Linux-Kernel@Vger. Kernel. Org, Dave Young, Petr Tesarik
Vivek Goyal <vgoyal@redhat.com> writes:
> On Tue, Jun 16, 2015 at 02:38:31PM -0500, Eric W. Biederman wrote:
>>
>> Adding Vivek as he is the one who implemented kexec_file_load.
>> I was hoping he would respond to this thread, and it looks like he
>> simply has not ever been Cc'd.
>>
>> Theodore Ts'o <tytso@mit.edu> writes:
>>
>> > On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
>> >> The bits that actually read Secure Boot state out of the UEFI
>> >> variables, and apply protections to the machine to avoid compromise
>> >> under the SB threat model. Things like disabling the old kexec...
>> >
>> > I don't have any real interest in using Secure Boot, but I *am*
>> > interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to
>> > have something similar to what we have with signed modules in terms of
>> > CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
>> > KEXEC_VERIFY_SIG. This would mean creating a separate flag
>> > independent of the one Linus suggested for Secure Boot, but since we
>> > have one for signed modules, we do have precedent for this sort of
>> > thing.
>>
>> My overall request with respect to kexec has been that we implement
>> things that make sense outside of the bizarre threat model of the Linux
>> folks who were talking about secure boot.
>>
>> nI have not navigated the labyrinth of config options but having a way to
>> only boot signed things with kexec seems a completely sensible way to
>> operate in the context of signed images.
>>
>> I don't know how much that will help given that actors with sufficient
>> resources have demonstrated the ability to steal private keys, but
>> assuming binary signing is an effective technique (or why else do it)
>> then having an option to limit kexec to only loading signed images seems
>> sensible.
>
> I went through the mail chain on web and here are my thoughts.
>
> - So yes, upstream does not have the logic which automatically disables
> the old syscall (kexec_load()) on secureboot systems. Distributions
> carry those patches.
>
> - This KEXEC_VERIFY_SIG option only cotrols the behavior for
> kexec_file_load() syscall and is not meant to directly affect any
> behavior of old syscall (kexec_load()). I think I should have named
> it KEXEC_FILE_VERIFY_SIG. Though help text makes it clear.
> "Verify kernel signature during kexec_file_load() syscall".
>
> - I think disabling old system call if KEXEC_VERIFY_SIG() is set
> will break existing setup which use old system call by default, except
> the case of secureboot system. And old syscall path is well tested
> and new syscall might not be in a position to support all the corner
> cases, atleast as of now.
>
> Ted,
>
> So looks like you are looking for a system/option where you just want to
> always make use of kexec_file_load() and disable kexec_load(). This sounds
> like you want a kernel where kexec_load() is compiled out and you want
> only kexec_file_load() in.
>
> Right now one can't do that becase kexec_file_load() depends on
> CONFIG_KEXEC option.
>
> I am wondering that how about making CONFIG_KEXEC_FILE_LOAD independent
> of CONFIG_KEXEC. That way one can set CONFIG_KEXEC_VERIFY_SIG=y, and
> only signed kernel can be kexeced on that system.
>
> This should gel well with long term strategy of deprecating kexec_load()
> at some point of time when kexec_file_load() is ready to completely
> replace it.
Interesting.
I suspect that what we want is to have CONFIG_KEXEC for the core
and additional CONFIG_KEXEC_LOAD option that covers that kexec_load call.
That should make it trivially easy to disable the kexec_load system call
in cases where people care.
Eric
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-17 1:32 ` Eric W. Biederman
0 siblings, 0 replies; 50+ messages in thread
From: Eric W. Biederman @ 2015-06-17 1:32 UTC (permalink / raw)
To: Vivek Goyal
Cc: Josh Boyer, Theodore Ts'o, Petr Tesarik, kexec,
Linux-Kernel@Vger. Kernel. Org, David Howells, Dave Young
Vivek Goyal <vgoyal@redhat.com> writes:
> On Tue, Jun 16, 2015 at 02:38:31PM -0500, Eric W. Biederman wrote:
>>
>> Adding Vivek as he is the one who implemented kexec_file_load.
>> I was hoping he would respond to this thread, and it looks like he
>> simply has not ever been Cc'd.
>>
>> Theodore Ts'o <tytso@mit.edu> writes:
>>
>> > On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
>> >> The bits that actually read Secure Boot state out of the UEFI
>> >> variables, and apply protections to the machine to avoid compromise
>> >> under the SB threat model. Things like disabling the old kexec...
>> >
>> > I don't have any real interest in using Secure Boot, but I *am*
>> > interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to
>> > have something similar to what we have with signed modules in terms of
>> > CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
>> > KEXEC_VERIFY_SIG. This would mean creating a separate flag
>> > independent of the one Linus suggested for Secure Boot, but since we
>> > have one for signed modules, we do have precedent for this sort of
>> > thing.
>>
>> My overall request with respect to kexec has been that we implement
>> things that make sense outside of the bizarre threat model of the Linux
>> folks who were talking about secure boot.
>>
>> nI have not navigated the labyrinth of config options but having a way to
>> only boot signed things with kexec seems a completely sensible way to
>> operate in the context of signed images.
>>
>> I don't know how much that will help given that actors with sufficient
>> resources have demonstrated the ability to steal private keys, but
>> assuming binary signing is an effective technique (or why else do it)
>> then having an option to limit kexec to only loading signed images seems
>> sensible.
>
> I went through the mail chain on web and here are my thoughts.
>
> - So yes, upstream does not have the logic which automatically disables
> the old syscall (kexec_load()) on secureboot systems. Distributions
> carry those patches.
>
> - This KEXEC_VERIFY_SIG option only cotrols the behavior for
> kexec_file_load() syscall and is not meant to directly affect any
> behavior of old syscall (kexec_load()). I think I should have named
> it KEXEC_FILE_VERIFY_SIG. Though help text makes it clear.
> "Verify kernel signature during kexec_file_load() syscall".
>
> - I think disabling old system call if KEXEC_VERIFY_SIG() is set
> will break existing setup which use old system call by default, except
> the case of secureboot system. And old syscall path is well tested
> and new syscall might not be in a position to support all the corner
> cases, atleast as of now.
>
> Ted,
>
> So looks like you are looking for a system/option where you just want to
> always make use of kexec_file_load() and disable kexec_load(). This sounds
> like you want a kernel where kexec_load() is compiled out and you want
> only kexec_file_load() in.
>
> Right now one can't do that becase kexec_file_load() depends on
> CONFIG_KEXEC option.
>
> I am wondering that how about making CONFIG_KEXEC_FILE_LOAD independent
> of CONFIG_KEXEC. That way one can set CONFIG_KEXEC_VERIFY_SIG=y, and
> only signed kernel can be kexeced on that system.
>
> This should gel well with long term strategy of deprecating kexec_load()
> at some point of time when kexec_file_load() is ready to completely
> replace it.
Interesting.
I suspect that what we want is to have CONFIG_KEXEC for the core
and additional CONFIG_KEXEC_LOAD option that covers that kexec_load call.
That should make it trivially easy to disable the kexec_load system call
in cases where people care.
Eric
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-17 1:32 ` Eric W. Biederman
@ 2015-06-17 1:47 ` Vivek Goyal
-1 siblings, 0 replies; 50+ messages in thread
From: Vivek Goyal @ 2015-06-17 1:47 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Theodore Ts'o, Josh Boyer, David Howells, kexec,
Linux-Kernel@Vger. Kernel. Org, Dave Young, Petr Tesarik
On Tue, Jun 16, 2015 at 08:32:37PM -0500, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@redhat.com> writes:
>
> > On Tue, Jun 16, 2015 at 02:38:31PM -0500, Eric W. Biederman wrote:
> >>
> >> Adding Vivek as he is the one who implemented kexec_file_load.
> >> I was hoping he would respond to this thread, and it looks like he
> >> simply has not ever been Cc'd.
> >>
> >> Theodore Ts'o <tytso@mit.edu> writes:
> >>
> >> > On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
> >> >> The bits that actually read Secure Boot state out of the UEFI
> >> >> variables, and apply protections to the machine to avoid compromise
> >> >> under the SB threat model. Things like disabling the old kexec...
> >> >
> >> > I don't have any real interest in using Secure Boot, but I *am*
> >> > interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to
> >> > have something similar to what we have with signed modules in terms of
> >> > CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
> >> > KEXEC_VERIFY_SIG. This would mean creating a separate flag
> >> > independent of the one Linus suggested for Secure Boot, but since we
> >> > have one for signed modules, we do have precedent for this sort of
> >> > thing.
> >>
> >> My overall request with respect to kexec has been that we implement
> >> things that make sense outside of the bizarre threat model of the Linux
> >> folks who were talking about secure boot.
> >>
> >> nI have not navigated the labyrinth of config options but having a way to
> >> only boot signed things with kexec seems a completely sensible way to
> >> operate in the context of signed images.
> >>
> >> I don't know how much that will help given that actors with sufficient
> >> resources have demonstrated the ability to steal private keys, but
> >> assuming binary signing is an effective technique (or why else do it)
> >> then having an option to limit kexec to only loading signed images seems
> >> sensible.
> >
> > I went through the mail chain on web and here are my thoughts.
> >
> > - So yes, upstream does not have the logic which automatically disables
> > the old syscall (kexec_load()) on secureboot systems. Distributions
> > carry those patches.
> >
> > - This KEXEC_VERIFY_SIG option only cotrols the behavior for
> > kexec_file_load() syscall and is not meant to directly affect any
> > behavior of old syscall (kexec_load()). I think I should have named
> > it KEXEC_FILE_VERIFY_SIG. Though help text makes it clear.
> > "Verify kernel signature during kexec_file_load() syscall".
> >
> > - I think disabling old system call if KEXEC_VERIFY_SIG() is set
> > will break existing setup which use old system call by default, except
> > the case of secureboot system. And old syscall path is well tested
> > and new syscall might not be in a position to support all the corner
> > cases, atleast as of now.
> >
> > Ted,
> >
> > So looks like you are looking for a system/option where you just want to
> > always make use of kexec_file_load() and disable kexec_load(). This sounds
> > like you want a kernel where kexec_load() is compiled out and you want
> > only kexec_file_load() in.
> >
> > Right now one can't do that becase kexec_file_load() depends on
> > CONFIG_KEXEC option.
> >
> > I am wondering that how about making CONFIG_KEXEC_FILE_LOAD independent
> > of CONFIG_KEXEC. That way one can set CONFIG_KEXEC_VERIFY_SIG=y, and
> > only signed kernel can be kexeced on that system.
> >
> > This should gel well with long term strategy of deprecating kexec_load()
> > at some point of time when kexec_file_load() is ready to completely
> > replace it.
>
> Interesting.
>
> I suspect that what we want is to have CONFIG_KEXEC for the core
> and additional CONFIG_KEXEC_LOAD option that covers that kexec_load call.
>
> That should make it trivially easy to disable the kexec_load system call
> in cases where people care.
Or, we could create another option CONFIG_KEXEC_CORE/CONFIG_KEXEC_COMMON
which will be automatically selected when either CONFIG_KEXEC or
CONIG_KEXEC_FILE are selected.
All common code can go under this option and rest can go under respective
config options.
That way, those who have CONFIG_KEXEC=y in old config files will not be
broken. They don't have to learn about new options at all.
Thanks
Vivek
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-17 1:47 ` Vivek Goyal
0 siblings, 0 replies; 50+ messages in thread
From: Vivek Goyal @ 2015-06-17 1:47 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Josh Boyer, Theodore Ts'o, Petr Tesarik, kexec,
Linux-Kernel@Vger. Kernel. Org, David Howells, Dave Young
On Tue, Jun 16, 2015 at 08:32:37PM -0500, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@redhat.com> writes:
>
> > On Tue, Jun 16, 2015 at 02:38:31PM -0500, Eric W. Biederman wrote:
> >>
> >> Adding Vivek as he is the one who implemented kexec_file_load.
> >> I was hoping he would respond to this thread, and it looks like he
> >> simply has not ever been Cc'd.
> >>
> >> Theodore Ts'o <tytso@mit.edu> writes:
> >>
> >> > On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
> >> >> The bits that actually read Secure Boot state out of the UEFI
> >> >> variables, and apply protections to the machine to avoid compromise
> >> >> under the SB threat model. Things like disabling the old kexec...
> >> >
> >> > I don't have any real interest in using Secure Boot, but I *am*
> >> > interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to
> >> > have something similar to what we have with signed modules in terms of
> >> > CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
> >> > KEXEC_VERIFY_SIG. This would mean creating a separate flag
> >> > independent of the one Linus suggested for Secure Boot, but since we
> >> > have one for signed modules, we do have precedent for this sort of
> >> > thing.
> >>
> >> My overall request with respect to kexec has been that we implement
> >> things that make sense outside of the bizarre threat model of the Linux
> >> folks who were talking about secure boot.
> >>
> >> nI have not navigated the labyrinth of config options but having a way to
> >> only boot signed things with kexec seems a completely sensible way to
> >> operate in the context of signed images.
> >>
> >> I don't know how much that will help given that actors with sufficient
> >> resources have demonstrated the ability to steal private keys, but
> >> assuming binary signing is an effective technique (or why else do it)
> >> then having an option to limit kexec to only loading signed images seems
> >> sensible.
> >
> > I went through the mail chain on web and here are my thoughts.
> >
> > - So yes, upstream does not have the logic which automatically disables
> > the old syscall (kexec_load()) on secureboot systems. Distributions
> > carry those patches.
> >
> > - This KEXEC_VERIFY_SIG option only cotrols the behavior for
> > kexec_file_load() syscall and is not meant to directly affect any
> > behavior of old syscall (kexec_load()). I think I should have named
> > it KEXEC_FILE_VERIFY_SIG. Though help text makes it clear.
> > "Verify kernel signature during kexec_file_load() syscall".
> >
> > - I think disabling old system call if KEXEC_VERIFY_SIG() is set
> > will break existing setup which use old system call by default, except
> > the case of secureboot system. And old syscall path is well tested
> > and new syscall might not be in a position to support all the corner
> > cases, atleast as of now.
> >
> > Ted,
> >
> > So looks like you are looking for a system/option where you just want to
> > always make use of kexec_file_load() and disable kexec_load(). This sounds
> > like you want a kernel where kexec_load() is compiled out and you want
> > only kexec_file_load() in.
> >
> > Right now one can't do that becase kexec_file_load() depends on
> > CONFIG_KEXEC option.
> >
> > I am wondering that how about making CONFIG_KEXEC_FILE_LOAD independent
> > of CONFIG_KEXEC. That way one can set CONFIG_KEXEC_VERIFY_SIG=y, and
> > only signed kernel can be kexeced on that system.
> >
> > This should gel well with long term strategy of deprecating kexec_load()
> > at some point of time when kexec_file_load() is ready to completely
> > replace it.
>
> Interesting.
>
> I suspect that what we want is to have CONFIG_KEXEC for the core
> and additional CONFIG_KEXEC_LOAD option that covers that kexec_load call.
>
> That should make it trivially easy to disable the kexec_load system call
> in cases where people care.
Or, we could create another option CONFIG_KEXEC_CORE/CONFIG_KEXEC_COMMON
which will be automatically selected when either CONFIG_KEXEC or
CONIG_KEXEC_FILE are selected.
All common code can go under this option and rest can go under respective
config options.
That way, those who have CONFIG_KEXEC=y in old config files will not be
broken. They don't have to learn about new options at all.
Thanks
Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-16 20:27 ` Vivek Goyal
@ 2015-06-17 3:26 ` Theodore Ts'o
-1 siblings, 0 replies; 50+ messages in thread
From: Theodore Ts'o @ 2015-06-17 3:26 UTC (permalink / raw)
To: Vivek Goyal
Cc: Eric W. Biederman, Josh Boyer, David Howells, kexec,
Linux-Kernel@Vger. Kernel. Org, Dave Young, Petr Tesarik
On Tue, Jun 16, 2015 at 04:27:57PM -0400, Vivek Goyal wrote:
>
> So looks like you are looking for a system/option where you just want to
> always make use of kexec_file_load() and disable kexec_load(). This sounds
> like you want a kernel where kexec_load() is compiled out and you want
> only kexec_file_load() in.
Either compiled out or disabled via some flag (similar to how signed
moduled verification can be required via a flag that can be set, but
not unset once it is set), yes.
> Right now one can't do that becase kexec_file_load() depends on
> CONFIG_KEXEC option.
>
> I am wondering that how about making CONFIG_KEXEC_FILE_LOAD independent
> of CONFIG_KEXEC. That way one can set CONFIG_KEXEC_VERIFY_SIG=y, and
> only signed kernel can be kexeced on that system.
That would certianly also be a workable strategy.
> This should gel well with long term strategy of deprecating kexec_load()
> at some point of time when kexec_file_load() is ready to completely
> replace it.
Well, note that Debian and Ubuntu are still using kexec-tools 2.0.7
(even in their latest development/unstable releases), which doesn't
have support for kexec_file_load(). So we need to get Debian to
upgrade its kexec-tools as part of this. I'll try to file a
nag-o-gram to the Debian BTS.
- Ted
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-17 3:26 ` Theodore Ts'o
0 siblings, 0 replies; 50+ messages in thread
From: Theodore Ts'o @ 2015-06-17 3:26 UTC (permalink / raw)
To: Vivek Goyal
Cc: Josh Boyer, Petr Tesarik, kexec, Linux-Kernel@Vger. Kernel. Org,
David Howells, Eric W. Biederman, Dave Young
On Tue, Jun 16, 2015 at 04:27:57PM -0400, Vivek Goyal wrote:
>
> So looks like you are looking for a system/option where you just want to
> always make use of kexec_file_load() and disable kexec_load(). This sounds
> like you want a kernel where kexec_load() is compiled out and you want
> only kexec_file_load() in.
Either compiled out or disabled via some flag (similar to how signed
moduled verification can be required via a flag that can be set, but
not unset once it is set), yes.
> Right now one can't do that becase kexec_file_load() depends on
> CONFIG_KEXEC option.
>
> I am wondering that how about making CONFIG_KEXEC_FILE_LOAD independent
> of CONFIG_KEXEC. That way one can set CONFIG_KEXEC_VERIFY_SIG=y, and
> only signed kernel can be kexeced on that system.
That would certianly also be a workable strategy.
> This should gel well with long term strategy of deprecating kexec_load()
> at some point of time when kexec_file_load() is ready to completely
> replace it.
Well, note that Debian and Ubuntu are still using kexec-tools 2.0.7
(even in their latest development/unstable releases), which doesn't
have support for kexec_file_load(). So we need to get Debian to
upgrade its kexec-tools as part of this. I'll try to file a
nag-o-gram to the Debian BTS.
- Ted
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-15 20:01 ` Theodore Ts'o
@ 2015-06-17 10:55 ` One Thousand Gnomes
-1 siblings, 0 replies; 50+ messages in thread
From: One Thousand Gnomes @ 2015-06-17 10:55 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Josh Boyer, Eric Biederman, David Howells, kexec,
Linux-Kernel@Vger. Kernel. Org
> [1] Yes, it doesn't buy all that much, since if the system is rooted
> the adversary can just replace the kernel in /boot and force a normal,
> slower reboot, but the same could be said for signed modules --- the
> adversary could just replace all of /boot/vmlinux-<kver> and
> /lib/modules/<kver>. But both measures make it a tad more bit
> difficult, especially for the adversary to do this replacement without
> being noticed (for example linode will send me e-mail if the system
> reboots normally, but not with a kexec-mediated reboot), and for cloud
> systems where we don't have secure boot anyway, it's about the best we
> can do.
It's about the same as the protection offered by the "secure" boot
patches I've seen because they don't block all kernel boot parameters
except a whitelist and because there are a pile of other fairly
fundamental problems that probably require you also sign the root file
system, which is itself a world of pain.
Alan
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-17 10:55 ` One Thousand Gnomes
0 siblings, 0 replies; 50+ messages in thread
From: One Thousand Gnomes @ 2015-06-17 10:55 UTC (permalink / raw)
To: Theodore Ts'o
Cc: David Howells, Josh Boyer, kexec, Eric Biederman,
Linux-Kernel@Vger. Kernel. Org
> [1] Yes, it doesn't buy all that much, since if the system is rooted
> the adversary can just replace the kernel in /boot and force a normal,
> slower reboot, but the same could be said for signed modules --- the
> adversary could just replace all of /boot/vmlinux-<kver> and
> /lib/modules/<kver>. But both measures make it a tad more bit
> difficult, especially for the adversary to do this replacement without
> being noticed (for example linode will send me e-mail if the system
> reboots normally, but not with a kexec-mediated reboot), and for cloud
> systems where we don't have secure boot anyway, it's about the best we
> can do.
It's about the same as the protection offered by the "secure" boot
patches I've seen because they don't block all kernel boot parameters
except a whitelist and because there are a pile of other fairly
fundamental problems that probably require you also sign the root file
system, which is itself a world of pain.
Alan
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-17 1:47 ` Vivek Goyal
@ 2015-06-18 1:16 ` Dave Young
-1 siblings, 0 replies; 50+ messages in thread
From: Dave Young @ 2015-06-18 1:16 UTC (permalink / raw)
To: Vivek Goyal
Cc: Eric W. Biederman, Josh Boyer, Theodore Ts'o, Petr Tesarik,
kexec, Linux-Kernel@Vger. Kernel. Org, David Howells
On 06/16/15 at 09:47pm, Vivek Goyal wrote:
> On Tue, Jun 16, 2015 at 08:32:37PM -0500, Eric W. Biederman wrote:
> > Vivek Goyal <vgoyal@redhat.com> writes:
> >
> > > On Tue, Jun 16, 2015 at 02:38:31PM -0500, Eric W. Biederman wrote:
> > >>
> > >> Adding Vivek as he is the one who implemented kexec_file_load.
> > >> I was hoping he would respond to this thread, and it looks like he
> > >> simply has not ever been Cc'd.
> > >>
> > >> Theodore Ts'o <tytso@mit.edu> writes:
> > >>
> > >> > On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
> > >> >> The bits that actually read Secure Boot state out of the UEFI
> > >> >> variables, and apply protections to the machine to avoid compromise
> > >> >> under the SB threat model. Things like disabling the old kexec...
> > >> >
> > >> > I don't have any real interest in using Secure Boot, but I *am*
> > >> > interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to
> > >> > have something similar to what we have with signed modules in terms of
> > >> > CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
> > >> > KEXEC_VERIFY_SIG. This would mean creating a separate flag
> > >> > independent of the one Linus suggested for Secure Boot, but since we
> > >> > have one for signed modules, we do have precedent for this sort of
> > >> > thing.
> > >>
> > >> My overall request with respect to kexec has been that we implement
> > >> things that make sense outside of the bizarre threat model of the Linux
> > >> folks who were talking about secure boot.
> > >>
> > >> nI have not navigated the labyrinth of config options but having a way to
> > >> only boot signed things with kexec seems a completely sensible way to
> > >> operate in the context of signed images.
> > >>
> > >> I don't know how much that will help given that actors with sufficient
> > >> resources have demonstrated the ability to steal private keys, but
> > >> assuming binary signing is an effective technique (or why else do it)
> > >> then having an option to limit kexec to only loading signed images seems
> > >> sensible.
> > >
> > > I went through the mail chain on web and here are my thoughts.
> > >
> > > - So yes, upstream does not have the logic which automatically disables
> > > the old syscall (kexec_load()) on secureboot systems. Distributions
> > > carry those patches.
> > >
> > > - This KEXEC_VERIFY_SIG option only cotrols the behavior for
> > > kexec_file_load() syscall and is not meant to directly affect any
> > > behavior of old syscall (kexec_load()). I think I should have named
> > > it KEXEC_FILE_VERIFY_SIG. Though help text makes it clear.
> > > "Verify kernel signature during kexec_file_load() syscall".
> > >
> > > - I think disabling old system call if KEXEC_VERIFY_SIG() is set
> > > will break existing setup which use old system call by default, except
> > > the case of secureboot system. And old syscall path is well tested
> > > and new syscall might not be in a position to support all the corner
> > > cases, atleast as of now.
> > >
> > > Ted,
> > >
> > > So looks like you are looking for a system/option where you just want to
> > > always make use of kexec_file_load() and disable kexec_load(). This sounds
> > > like you want a kernel where kexec_load() is compiled out and you want
> > > only kexec_file_load() in.
> > >
> > > Right now one can't do that becase kexec_file_load() depends on
> > > CONFIG_KEXEC option.
> > >
> > > I am wondering that how about making CONFIG_KEXEC_FILE_LOAD independent
> > > of CONFIG_KEXEC. That way one can set CONFIG_KEXEC_VERIFY_SIG=y, and
> > > only signed kernel can be kexeced on that system.
> > >
> > > This should gel well with long term strategy of deprecating kexec_load()
> > > at some point of time when kexec_file_load() is ready to completely
> > > replace it.
> >
> > Interesting.
> >
> > I suspect that what we want is to have CONFIG_KEXEC for the core
> > and additional CONFIG_KEXEC_LOAD option that covers that kexec_load call.
> >
> > That should make it trivially easy to disable the kexec_load system call
> > in cases where people care.
>
> Or, we could create another option CONFIG_KEXEC_CORE/CONFIG_KEXEC_COMMON
> which will be automatically selected when either CONFIG_KEXEC or
> CONIG_KEXEC_FILE are selected.
>
> All common code can go under this option and rest can go under respective
> config options.
>
> That way, those who have CONFIG_KEXEC=y in old config files will not be
> broken. They don't have to learn about new options at all.
Or simply add a new config option KEXEC_VERIFY_SIG_FORCE, so we can return
error in kexec_load and print some error message.
Thanks
Dave
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-18 1:16 ` Dave Young
0 siblings, 0 replies; 50+ messages in thread
From: Dave Young @ 2015-06-18 1:16 UTC (permalink / raw)
To: Vivek Goyal
Cc: Josh Boyer, Theodore Ts'o, kexec, Petr Tesarik,
Linux-Kernel@Vger. Kernel. Org, David Howells, Eric W. Biederman
On 06/16/15 at 09:47pm, Vivek Goyal wrote:
> On Tue, Jun 16, 2015 at 08:32:37PM -0500, Eric W. Biederman wrote:
> > Vivek Goyal <vgoyal@redhat.com> writes:
> >
> > > On Tue, Jun 16, 2015 at 02:38:31PM -0500, Eric W. Biederman wrote:
> > >>
> > >> Adding Vivek as he is the one who implemented kexec_file_load.
> > >> I was hoping he would respond to this thread, and it looks like he
> > >> simply has not ever been Cc'd.
> > >>
> > >> Theodore Ts'o <tytso@mit.edu> writes:
> > >>
> > >> > On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
> > >> >> The bits that actually read Secure Boot state out of the UEFI
> > >> >> variables, and apply protections to the machine to avoid compromise
> > >> >> under the SB threat model. Things like disabling the old kexec...
> > >> >
> > >> > I don't have any real interest in using Secure Boot, but I *am*
> > >> > interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to
> > >> > have something similar to what we have with signed modules in terms of
> > >> > CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
> > >> > KEXEC_VERIFY_SIG. This would mean creating a separate flag
> > >> > independent of the one Linus suggested for Secure Boot, but since we
> > >> > have one for signed modules, we do have precedent for this sort of
> > >> > thing.
> > >>
> > >> My overall request with respect to kexec has been that we implement
> > >> things that make sense outside of the bizarre threat model of the Linux
> > >> folks who were talking about secure boot.
> > >>
> > >> nI have not navigated the labyrinth of config options but having a way to
> > >> only boot signed things with kexec seems a completely sensible way to
> > >> operate in the context of signed images.
> > >>
> > >> I don't know how much that will help given that actors with sufficient
> > >> resources have demonstrated the ability to steal private keys, but
> > >> assuming binary signing is an effective technique (or why else do it)
> > >> then having an option to limit kexec to only loading signed images seems
> > >> sensible.
> > >
> > > I went through the mail chain on web and here are my thoughts.
> > >
> > > - So yes, upstream does not have the logic which automatically disables
> > > the old syscall (kexec_load()) on secureboot systems. Distributions
> > > carry those patches.
> > >
> > > - This KEXEC_VERIFY_SIG option only cotrols the behavior for
> > > kexec_file_load() syscall and is not meant to directly affect any
> > > behavior of old syscall (kexec_load()). I think I should have named
> > > it KEXEC_FILE_VERIFY_SIG. Though help text makes it clear.
> > > "Verify kernel signature during kexec_file_load() syscall".
> > >
> > > - I think disabling old system call if KEXEC_VERIFY_SIG() is set
> > > will break existing setup which use old system call by default, except
> > > the case of secureboot system. And old syscall path is well tested
> > > and new syscall might not be in a position to support all the corner
> > > cases, atleast as of now.
> > >
> > > Ted,
> > >
> > > So looks like you are looking for a system/option where you just want to
> > > always make use of kexec_file_load() and disable kexec_load(). This sounds
> > > like you want a kernel where kexec_load() is compiled out and you want
> > > only kexec_file_load() in.
> > >
> > > Right now one can't do that becase kexec_file_load() depends on
> > > CONFIG_KEXEC option.
> > >
> > > I am wondering that how about making CONFIG_KEXEC_FILE_LOAD independent
> > > of CONFIG_KEXEC. That way one can set CONFIG_KEXEC_VERIFY_SIG=y, and
> > > only signed kernel can be kexeced on that system.
> > >
> > > This should gel well with long term strategy of deprecating kexec_load()
> > > at some point of time when kexec_file_load() is ready to completely
> > > replace it.
> >
> > Interesting.
> >
> > I suspect that what we want is to have CONFIG_KEXEC for the core
> > and additional CONFIG_KEXEC_LOAD option that covers that kexec_load call.
> >
> > That should make it trivially easy to disable the kexec_load system call
> > in cases where people care.
>
> Or, we could create another option CONFIG_KEXEC_CORE/CONFIG_KEXEC_COMMON
> which will be automatically selected when either CONFIG_KEXEC or
> CONIG_KEXEC_FILE are selected.
>
> All common code can go under this option and rest can go under respective
> config options.
>
> That way, those who have CONFIG_KEXEC=y in old config files will not be
> broken. They don't have to learn about new options at all.
Or simply add a new config option KEXEC_VERIFY_SIG_FORCE, so we can return
error in kexec_load and print some error message.
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-15 20:01 ` Theodore Ts'o
@ 2015-06-18 1:25 ` Dave Young
-1 siblings, 0 replies; 50+ messages in thread
From: Dave Young @ 2015-06-18 1:25 UTC (permalink / raw)
To: Theodore Ts'o, Josh Boyer, Eric Biederman, David Howells,
kexec, Linux-Kernel@Vger. Kernel. Org
On 06/15/15 at 04:01pm, Theodore Ts'o wrote:
> On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
> > The bits that actually read Secure Boot state out of the UEFI
> > variables, and apply protections to the machine to avoid compromise
> > under the SB threat model. Things like disabling the old kexec...
>
> I don't have any real interest in using Secure Boot, but I *am*
> interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to
> have something similar to what we have with signed modules in terms of
> CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
> KEXEC_VERIFY_SIG. This would mean creating a separate flag
> independent of the one Linus suggested for Secure Boot, but since we
> have one for signed modules, we do have precedent for this sort of
> thing.
Agree and vote for this way as I replied in another email about
CONFIG_KEXEC_VERIFY_SIG_FORCE.
Thanks
Dave
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-18 1:25 ` Dave Young
0 siblings, 0 replies; 50+ messages in thread
From: Dave Young @ 2015-06-18 1:25 UTC (permalink / raw)
To: Theodore Ts'o, Josh Boyer, Eric Biederman, David Howells,
kexec, Linux-Kernel@Vger. Kernel. Org
On 06/15/15 at 04:01pm, Theodore Ts'o wrote:
> On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
> > The bits that actually read Secure Boot state out of the UEFI
> > variables, and apply protections to the machine to avoid compromise
> > under the SB threat model. Things like disabling the old kexec...
>
> I don't have any real interest in using Secure Boot, but I *am*
> interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to
> have something similar to what we have with signed modules in terms of
> CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
> KEXEC_VERIFY_SIG. This would mean creating a separate flag
> independent of the one Linus suggested for Secure Boot, but since we
> have one for signed modules, we do have precedent for this sort of
> thing.
Agree and vote for this way as I replied in another email about
CONFIG_KEXEC_VERIFY_SIG_FORCE.
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-18 1:16 ` Dave Young
@ 2015-06-18 2:02 ` Dave Young
-1 siblings, 0 replies; 50+ messages in thread
From: Dave Young @ 2015-06-18 2:02 UTC (permalink / raw)
To: Vivek Goyal
Cc: Eric W. Biederman, Josh Boyer, Theodore Ts'o, Petr Tesarik,
kexec, Linux-Kernel@Vger. Kernel. Org, David Howells
On 06/18/15 at 09:16am, Dave Young wrote:
> On 06/16/15 at 09:47pm, Vivek Goyal wrote:
> > On Tue, Jun 16, 2015 at 08:32:37PM -0500, Eric W. Biederman wrote:
> > > Vivek Goyal <vgoyal@redhat.com> writes:
> > >
> > > > On Tue, Jun 16, 2015 at 02:38:31PM -0500, Eric W. Biederman wrote:
> > > >>
> > > >> Adding Vivek as he is the one who implemented kexec_file_load.
> > > >> I was hoping he would respond to this thread, and it looks like he
> > > >> simply has not ever been Cc'd.
> > > >>
> > > >> Theodore Ts'o <tytso@mit.edu> writes:
> > > >>
> > > >> > On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
> > > >> >> The bits that actually read Secure Boot state out of the UEFI
> > > >> >> variables, and apply protections to the machine to avoid compromise
> > > >> >> under the SB threat model. Things like disabling the old kexec...
> > > >> >
> > > >> > I don't have any real interest in using Secure Boot, but I *am*
> > > >> > interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to
> > > >> > have something similar to what we have with signed modules in terms of
> > > >> > CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
> > > >> > KEXEC_VERIFY_SIG. This would mean creating a separate flag
> > > >> > independent of the one Linus suggested for Secure Boot, but since we
> > > >> > have one for signed modules, we do have precedent for this sort of
> > > >> > thing.
> > > >>
> > > >> My overall request with respect to kexec has been that we implement
> > > >> things that make sense outside of the bizarre threat model of the Linux
> > > >> folks who were talking about secure boot.
> > > >>
> > > >> nI have not navigated the labyrinth of config options but having a way to
> > > >> only boot signed things with kexec seems a completely sensible way to
> > > >> operate in the context of signed images.
> > > >>
> > > >> I don't know how much that will help given that actors with sufficient
> > > >> resources have demonstrated the ability to steal private keys, but
> > > >> assuming binary signing is an effective technique (or why else do it)
> > > >> then having an option to limit kexec to only loading signed images seems
> > > >> sensible.
> > > >
> > > > I went through the mail chain on web and here are my thoughts.
> > > >
> > > > - So yes, upstream does not have the logic which automatically disables
> > > > the old syscall (kexec_load()) on secureboot systems. Distributions
> > > > carry those patches.
> > > >
> > > > - This KEXEC_VERIFY_SIG option only cotrols the behavior for
> > > > kexec_file_load() syscall and is not meant to directly affect any
> > > > behavior of old syscall (kexec_load()). I think I should have named
> > > > it KEXEC_FILE_VERIFY_SIG. Though help text makes it clear.
> > > > "Verify kernel signature during kexec_file_load() syscall".
> > > >
> > > > - I think disabling old system call if KEXEC_VERIFY_SIG() is set
> > > > will break existing setup which use old system call by default, except
> > > > the case of secureboot system. And old syscall path is well tested
> > > > and new syscall might not be in a position to support all the corner
> > > > cases, atleast as of now.
> > > >
> > > > Ted,
> > > >
> > > > So looks like you are looking for a system/option where you just want to
> > > > always make use of kexec_file_load() and disable kexec_load(). This sounds
> > > > like you want a kernel where kexec_load() is compiled out and you want
> > > > only kexec_file_load() in.
> > > >
> > > > Right now one can't do that becase kexec_file_load() depends on
> > > > CONFIG_KEXEC option.
> > > >
> > > > I am wondering that how about making CONFIG_KEXEC_FILE_LOAD independent
> > > > of CONFIG_KEXEC. That way one can set CONFIG_KEXEC_VERIFY_SIG=y, and
> > > > only signed kernel can be kexeced on that system.
> > > >
> > > > This should gel well with long term strategy of deprecating kexec_load()
> > > > at some point of time when kexec_file_load() is ready to completely
> > > > replace it.
> > >
> > > Interesting.
> > >
> > > I suspect that what we want is to have CONFIG_KEXEC for the core
> > > and additional CONFIG_KEXEC_LOAD option that covers that kexec_load call.
> > >
> > > That should make it trivially easy to disable the kexec_load system call
> > > in cases where people care.
> >
> > Or, we could create another option CONFIG_KEXEC_CORE/CONFIG_KEXEC_COMMON
> > which will be automatically selected when either CONFIG_KEXEC or
> > CONIG_KEXEC_FILE are selected.
> >
> > All common code can go under this option and rest can go under respective
> > config options.
> >
> > That way, those who have CONFIG_KEXEC=y in old config files will not be
> > broken. They don't have to learn about new options at all.
>
> Or simply add a new config option KEXEC_VERIFY_SIG_FORCE, so we can return
> error in kexec_load and print some error message.
Just like below, does this work for you, Ted?
---
arch/x86/Kconfig | 7 +++++++
kernel/kexec.c | 9 ++++++++-
2 files changed, 15 insertions(+), 1 deletion(-)
--- linux.orig/arch/x86/Kconfig
+++ linux/arch/x86/Kconfig
@@ -1755,6 +1755,13 @@ config KEXEC_VERIFY_SIG
verification for the corresponding kernel image type being
loaded in order for this to work.
+config KEXEC_VERIFY_SIG_FORCE
+ bool "Enforce kexec signature verifying"
+ depends on KEXEC_VERIFY_SIG
+ ---help---
+ This option disable kexec_load() syscall, only kexec_file_load
+ can be used.
+
config KEXEC_BZIMAGE_VERIFY_SIG
bool "Enable bzImage signature verification support"
depends on KEXEC_VERIFY_SIG
--- linux.orig/kernel/kexec.c
+++ linux/kernel/kexec.c
@@ -45,6 +45,12 @@
#include <crypto/hash.h>
#include <crypto/sha.h>
+#ifdef CONFIG_KEXEC_VERIFY_SIG_FORCE
+static bool kexec_verify_sig_force = true;
+#else
+static bool kexec_verify_sig_force;
+#endif
+
/* Per cpu memory for storing cpu states in case of system crash. */
note_buf_t __percpu *crash_notes;
@@ -1243,7 +1249,8 @@ SYSCALL_DEFINE4(kexec_load, unsigned lon
int result;
/* We only trust the superuser with rebooting the system. */
- if (!capable(CAP_SYS_BOOT) || kexec_load_disabled)
+ if (!capable(CAP_SYS_BOOT) || kexec_load_disabled
+ || kexec_verify_sig_force)
return -EPERM;
/*
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-18 2:02 ` Dave Young
0 siblings, 0 replies; 50+ messages in thread
From: Dave Young @ 2015-06-18 2:02 UTC (permalink / raw)
To: Vivek Goyal
Cc: Josh Boyer, Theodore Ts'o, kexec, Petr Tesarik,
Linux-Kernel@Vger. Kernel. Org, David Howells, Eric W. Biederman
On 06/18/15 at 09:16am, Dave Young wrote:
> On 06/16/15 at 09:47pm, Vivek Goyal wrote:
> > On Tue, Jun 16, 2015 at 08:32:37PM -0500, Eric W. Biederman wrote:
> > > Vivek Goyal <vgoyal@redhat.com> writes:
> > >
> > > > On Tue, Jun 16, 2015 at 02:38:31PM -0500, Eric W. Biederman wrote:
> > > >>
> > > >> Adding Vivek as he is the one who implemented kexec_file_load.
> > > >> I was hoping he would respond to this thread, and it looks like he
> > > >> simply has not ever been Cc'd.
> > > >>
> > > >> Theodore Ts'o <tytso@mit.edu> writes:
> > > >>
> > > >> > On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
> > > >> >> The bits that actually read Secure Boot state out of the UEFI
> > > >> >> variables, and apply protections to the machine to avoid compromise
> > > >> >> under the SB threat model. Things like disabling the old kexec...
> > > >> >
> > > >> > I don't have any real interest in using Secure Boot, but I *am*
> > > >> > interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to
> > > >> > have something similar to what we have with signed modules in terms of
> > > >> > CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
> > > >> > KEXEC_VERIFY_SIG. This would mean creating a separate flag
> > > >> > independent of the one Linus suggested for Secure Boot, but since we
> > > >> > have one for signed modules, we do have precedent for this sort of
> > > >> > thing.
> > > >>
> > > >> My overall request with respect to kexec has been that we implement
> > > >> things that make sense outside of the bizarre threat model of the Linux
> > > >> folks who were talking about secure boot.
> > > >>
> > > >> nI have not navigated the labyrinth of config options but having a way to
> > > >> only boot signed things with kexec seems a completely sensible way to
> > > >> operate in the context of signed images.
> > > >>
> > > >> I don't know how much that will help given that actors with sufficient
> > > >> resources have demonstrated the ability to steal private keys, but
> > > >> assuming binary signing is an effective technique (or why else do it)
> > > >> then having an option to limit kexec to only loading signed images seems
> > > >> sensible.
> > > >
> > > > I went through the mail chain on web and here are my thoughts.
> > > >
> > > > - So yes, upstream does not have the logic which automatically disables
> > > > the old syscall (kexec_load()) on secureboot systems. Distributions
> > > > carry those patches.
> > > >
> > > > - This KEXEC_VERIFY_SIG option only cotrols the behavior for
> > > > kexec_file_load() syscall and is not meant to directly affect any
> > > > behavior of old syscall (kexec_load()). I think I should have named
> > > > it KEXEC_FILE_VERIFY_SIG. Though help text makes it clear.
> > > > "Verify kernel signature during kexec_file_load() syscall".
> > > >
> > > > - I think disabling old system call if KEXEC_VERIFY_SIG() is set
> > > > will break existing setup which use old system call by default, except
> > > > the case of secureboot system. And old syscall path is well tested
> > > > and new syscall might not be in a position to support all the corner
> > > > cases, atleast as of now.
> > > >
> > > > Ted,
> > > >
> > > > So looks like you are looking for a system/option where you just want to
> > > > always make use of kexec_file_load() and disable kexec_load(). This sounds
> > > > like you want a kernel where kexec_load() is compiled out and you want
> > > > only kexec_file_load() in.
> > > >
> > > > Right now one can't do that becase kexec_file_load() depends on
> > > > CONFIG_KEXEC option.
> > > >
> > > > I am wondering that how about making CONFIG_KEXEC_FILE_LOAD independent
> > > > of CONFIG_KEXEC. That way one can set CONFIG_KEXEC_VERIFY_SIG=y, and
> > > > only signed kernel can be kexeced on that system.
> > > >
> > > > This should gel well with long term strategy of deprecating kexec_load()
> > > > at some point of time when kexec_file_load() is ready to completely
> > > > replace it.
> > >
> > > Interesting.
> > >
> > > I suspect that what we want is to have CONFIG_KEXEC for the core
> > > and additional CONFIG_KEXEC_LOAD option that covers that kexec_load call.
> > >
> > > That should make it trivially easy to disable the kexec_load system call
> > > in cases where people care.
> >
> > Or, we could create another option CONFIG_KEXEC_CORE/CONFIG_KEXEC_COMMON
> > which will be automatically selected when either CONFIG_KEXEC or
> > CONIG_KEXEC_FILE are selected.
> >
> > All common code can go under this option and rest can go under respective
> > config options.
> >
> > That way, those who have CONFIG_KEXEC=y in old config files will not be
> > broken. They don't have to learn about new options at all.
>
> Or simply add a new config option KEXEC_VERIFY_SIG_FORCE, so we can return
> error in kexec_load and print some error message.
Just like below, does this work for you, Ted?
---
arch/x86/Kconfig | 7 +++++++
kernel/kexec.c | 9 ++++++++-
2 files changed, 15 insertions(+), 1 deletion(-)
--- linux.orig/arch/x86/Kconfig
+++ linux/arch/x86/Kconfig
@@ -1755,6 +1755,13 @@ config KEXEC_VERIFY_SIG
verification for the corresponding kernel image type being
loaded in order for this to work.
+config KEXEC_VERIFY_SIG_FORCE
+ bool "Enforce kexec signature verifying"
+ depends on KEXEC_VERIFY_SIG
+ ---help---
+ This option disable kexec_load() syscall, only kexec_file_load
+ can be used.
+
config KEXEC_BZIMAGE_VERIFY_SIG
bool "Enable bzImage signature verification support"
depends on KEXEC_VERIFY_SIG
--- linux.orig/kernel/kexec.c
+++ linux/kernel/kexec.c
@@ -45,6 +45,12 @@
#include <crypto/hash.h>
#include <crypto/sha.h>
+#ifdef CONFIG_KEXEC_VERIFY_SIG_FORCE
+static bool kexec_verify_sig_force = true;
+#else
+static bool kexec_verify_sig_force;
+#endif
+
/* Per cpu memory for storing cpu states in case of system crash. */
note_buf_t __percpu *crash_notes;
@@ -1243,7 +1249,8 @@ SYSCALL_DEFINE4(kexec_load, unsigned lon
int result;
/* We only trust the superuser with rebooting the system. */
- if (!capable(CAP_SYS_BOOT) || kexec_load_disabled)
+ if (!capable(CAP_SYS_BOOT) || kexec_load_disabled
+ || kexec_verify_sig_force)
return -EPERM;
/*
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-18 2:02 ` Dave Young
@ 2015-06-18 13:30 ` Vivek Goyal
-1 siblings, 0 replies; 50+ messages in thread
From: Vivek Goyal @ 2015-06-18 13:30 UTC (permalink / raw)
To: Dave Young
Cc: Eric W. Biederman, Josh Boyer, Theodore Ts'o, Petr Tesarik,
kexec, Linux-Kernel@Vger. Kernel. Org, David Howells
On Thu, Jun 18, 2015 at 10:02:09AM +0800, Dave Young wrote:
[..]
> > Or simply add a new config option KEXEC_VERIFY_SIG_FORCE, so we can return
> > error in kexec_load and print some error message.
>
> Just like below, does this work for you, Ted?
>
> ---
> arch/x86/Kconfig | 7 +++++++
> kernel/kexec.c | 9 ++++++++-
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> --- linux.orig/arch/x86/Kconfig
> +++ linux/arch/x86/Kconfig
> @@ -1755,6 +1755,13 @@ config KEXEC_VERIFY_SIG
> verification for the corresponding kernel image type being
> loaded in order for this to work.
>
> +config KEXEC_VERIFY_SIG_FORCE
> + bool "Enforce kexec signature verifying"
> + depends on KEXEC_VERIFY_SIG
> + ---help---
> + This option disable kexec_load() syscall, only kexec_file_load
> + can be used.
> +
Hi Dave,
I think we might not need a new config option. A new config option makes
it little confusing. KEXEC_VERIFY_SIG already implies KEXEC_VERIFY_SIG_FORCE
(for new syscall). Now extending it to also mean that it should disable old
syscall is confusing.
We already have a sysctl knob to disable kexec kernel loading. But that
knob disables it on both the syscalls.
May be we can just introduce another command line option say
"kexec_verify_sig_force" and this will work across both the syscalls and
will deny loading a unsigned kernel in following two cases.
- Using old syscall
- Using new syscall if kernel was compiled with KEXEC_VERIFY_SIG=n.
This should be simple and get us going in short term.
If we want to disable unsigned kernel loading at compile time, then we
really need to work on decoupling CONFIG_KEXEC and CONFIG_FILE_KEXEC.
Introducing another config option is not the way forward, IMHO.
Thanks
Vivek
> config KEXEC_BZIMAGE_VERIFY_SIG
> bool "Enable bzImage signature verification support"
> depends on KEXEC_VERIFY_SIG
> --- linux.orig/kernel/kexec.c
> +++ linux/kernel/kexec.c
> @@ -45,6 +45,12 @@
> #include <crypto/hash.h>
> #include <crypto/sha.h>
>
> +#ifdef CONFIG_KEXEC_VERIFY_SIG_FORCE
> +static bool kexec_verify_sig_force = true;
> +#else
> +static bool kexec_verify_sig_force;
> +#endif
> +
> /* Per cpu memory for storing cpu states in case of system crash. */
> note_buf_t __percpu *crash_notes;
>
> @@ -1243,7 +1249,8 @@ SYSCALL_DEFINE4(kexec_load, unsigned lon
> int result;
>
> /* We only trust the superuser with rebooting the system. */
> - if (!capable(CAP_SYS_BOOT) || kexec_load_disabled)
> + if (!capable(CAP_SYS_BOOT) || kexec_load_disabled
> + || kexec_verify_sig_force)
> return -EPERM;
>
> /*
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-18 13:30 ` Vivek Goyal
0 siblings, 0 replies; 50+ messages in thread
From: Vivek Goyal @ 2015-06-18 13:30 UTC (permalink / raw)
To: Dave Young
Cc: Josh Boyer, Theodore Ts'o, kexec, Petr Tesarik,
Linux-Kernel@Vger. Kernel. Org, David Howells, Eric W. Biederman
On Thu, Jun 18, 2015 at 10:02:09AM +0800, Dave Young wrote:
[..]
> > Or simply add a new config option KEXEC_VERIFY_SIG_FORCE, so we can return
> > error in kexec_load and print some error message.
>
> Just like below, does this work for you, Ted?
>
> ---
> arch/x86/Kconfig | 7 +++++++
> kernel/kexec.c | 9 ++++++++-
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> --- linux.orig/arch/x86/Kconfig
> +++ linux/arch/x86/Kconfig
> @@ -1755,6 +1755,13 @@ config KEXEC_VERIFY_SIG
> verification for the corresponding kernel image type being
> loaded in order for this to work.
>
> +config KEXEC_VERIFY_SIG_FORCE
> + bool "Enforce kexec signature verifying"
> + depends on KEXEC_VERIFY_SIG
> + ---help---
> + This option disable kexec_load() syscall, only kexec_file_load
> + can be used.
> +
Hi Dave,
I think we might not need a new config option. A new config option makes
it little confusing. KEXEC_VERIFY_SIG already implies KEXEC_VERIFY_SIG_FORCE
(for new syscall). Now extending it to also mean that it should disable old
syscall is confusing.
We already have a sysctl knob to disable kexec kernel loading. But that
knob disables it on both the syscalls.
May be we can just introduce another command line option say
"kexec_verify_sig_force" and this will work across both the syscalls and
will deny loading a unsigned kernel in following two cases.
- Using old syscall
- Using new syscall if kernel was compiled with KEXEC_VERIFY_SIG=n.
This should be simple and get us going in short term.
If we want to disable unsigned kernel loading at compile time, then we
really need to work on decoupling CONFIG_KEXEC and CONFIG_FILE_KEXEC.
Introducing another config option is not the way forward, IMHO.
Thanks
Vivek
> config KEXEC_BZIMAGE_VERIFY_SIG
> bool "Enable bzImage signature verification support"
> depends on KEXEC_VERIFY_SIG
> --- linux.orig/kernel/kexec.c
> +++ linux/kernel/kexec.c
> @@ -45,6 +45,12 @@
> #include <crypto/hash.h>
> #include <crypto/sha.h>
>
> +#ifdef CONFIG_KEXEC_VERIFY_SIG_FORCE
> +static bool kexec_verify_sig_force = true;
> +#else
> +static bool kexec_verify_sig_force;
> +#endif
> +
> /* Per cpu memory for storing cpu states in case of system crash. */
> note_buf_t __percpu *crash_notes;
>
> @@ -1243,7 +1249,8 @@ SYSCALL_DEFINE4(kexec_load, unsigned lon
> int result;
>
> /* We only trust the superuser with rebooting the system. */
> - if (!capable(CAP_SYS_BOOT) || kexec_load_disabled)
> + if (!capable(CAP_SYS_BOOT) || kexec_load_disabled
> + || kexec_verify_sig_force)
> return -EPERM;
>
> /*
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-18 13:30 ` Vivek Goyal
@ 2015-06-18 14:41 ` Eric W. Biederman
-1 siblings, 0 replies; 50+ messages in thread
From: Eric W. Biederman @ 2015-06-18 14:41 UTC (permalink / raw)
To: Vivek Goyal
Cc: Dave Young, Josh Boyer, Theodore Ts'o, Petr Tesarik, kexec,
Linux-Kernel@Vger. Kernel. Org, David Howells
Vivek Goyal <vgoyal@redhat.com> writes:
> On Thu, Jun 18, 2015 at 10:02:09AM +0800, Dave Young wrote:
>
> [..]
>> > Or simply add a new config option KEXEC_VERIFY_SIG_FORCE, so we can return
>> > error in kexec_load and print some error message.
>>
>> Just like below, does this work for you, Ted?
>>
>> ---
>> arch/x86/Kconfig | 7 +++++++
>> kernel/kexec.c | 9 ++++++++-
>> 2 files changed, 15 insertions(+), 1 deletion(-)
>>
>> --- linux.orig/arch/x86/Kconfig
>> +++ linux/arch/x86/Kconfig
>> @@ -1755,6 +1755,13 @@ config KEXEC_VERIFY_SIG
>> verification for the corresponding kernel image type being
>> loaded in order for this to work.
>>
>> +config KEXEC_VERIFY_SIG_FORCE
>> + bool "Enforce kexec signature verifying"
>> + depends on KEXEC_VERIFY_SIG
>> + ---help---
>> + This option disable kexec_load() syscall, only kexec_file_load
>> + can be used.
>> +
>
>
> Hi Dave,
>
> I think we might not need a new config option. A new config option makes
> it little confusing. KEXEC_VERIFY_SIG already implies KEXEC_VERIFY_SIG_FORCE
> (for new syscall). Now extending it to also mean that it should disable old
> syscall is confusing.
Agreed.
> We already have a sysctl knob to disable kexec kernel loading. But that
> knob disables it on both the syscalls.
>
> May be we can just introduce another command line option say
> "kexec_verify_sig_force" and this will work across both the syscalls and
> will deny loading a unsigned kernel in following two cases.
>
> - Using old syscall
> - Using new syscall if kernel was compiled with KEXEC_VERIFY_SIG=n.
>
> This should be simple and get us going in short term.
>
> If we want to disable unsigned kernel loading at compile time, then we
> really need to work on decoupling CONFIG_KEXEC and CONFIG_FILE_KEXEC.
> Introducing another config option is not the way forward, IMHO.
Agreed.
I think disabling kexec_load at compile time can be easily justified.
Anything at runtime is additional complexity, additional bugs,
additional documentation and additional maintenance and needs
to justify itself.
I currently do not see the case for a magic one time runtime disable of
the kexec_load system call. Maybe there is some valid distro case for
wanting one kernel to do everything and serve every possible need, but I
have not seen that case presented yet.
Eric
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-18 14:41 ` Eric W. Biederman
0 siblings, 0 replies; 50+ messages in thread
From: Eric W. Biederman @ 2015-06-18 14:41 UTC (permalink / raw)
To: Vivek Goyal
Cc: Josh Boyer, Theodore Ts'o, Petr Tesarik, kexec,
Linux-Kernel@Vger. Kernel. Org, David Howells, Dave Young
Vivek Goyal <vgoyal@redhat.com> writes:
> On Thu, Jun 18, 2015 at 10:02:09AM +0800, Dave Young wrote:
>
> [..]
>> > Or simply add a new config option KEXEC_VERIFY_SIG_FORCE, so we can return
>> > error in kexec_load and print some error message.
>>
>> Just like below, does this work for you, Ted?
>>
>> ---
>> arch/x86/Kconfig | 7 +++++++
>> kernel/kexec.c | 9 ++++++++-
>> 2 files changed, 15 insertions(+), 1 deletion(-)
>>
>> --- linux.orig/arch/x86/Kconfig
>> +++ linux/arch/x86/Kconfig
>> @@ -1755,6 +1755,13 @@ config KEXEC_VERIFY_SIG
>> verification for the corresponding kernel image type being
>> loaded in order for this to work.
>>
>> +config KEXEC_VERIFY_SIG_FORCE
>> + bool "Enforce kexec signature verifying"
>> + depends on KEXEC_VERIFY_SIG
>> + ---help---
>> + This option disable kexec_load() syscall, only kexec_file_load
>> + can be used.
>> +
>
>
> Hi Dave,
>
> I think we might not need a new config option. A new config option makes
> it little confusing. KEXEC_VERIFY_SIG already implies KEXEC_VERIFY_SIG_FORCE
> (for new syscall). Now extending it to also mean that it should disable old
> syscall is confusing.
Agreed.
> We already have a sysctl knob to disable kexec kernel loading. But that
> knob disables it on both the syscalls.
>
> May be we can just introduce another command line option say
> "kexec_verify_sig_force" and this will work across both the syscalls and
> will deny loading a unsigned kernel in following two cases.
>
> - Using old syscall
> - Using new syscall if kernel was compiled with KEXEC_VERIFY_SIG=n.
>
> This should be simple and get us going in short term.
>
> If we want to disable unsigned kernel loading at compile time, then we
> really need to work on decoupling CONFIG_KEXEC and CONFIG_FILE_KEXEC.
> Introducing another config option is not the way forward, IMHO.
Agreed.
I think disabling kexec_load at compile time can be easily justified.
Anything at runtime is additional complexity, additional bugs,
additional documentation and additional maintenance and needs
to justify itself.
I currently do not see the case for a magic one time runtime disable of
the kexec_load system call. Maybe there is some valid distro case for
wanting one kernel to do everything and serve every possible need, but I
have not seen that case presented yet.
Eric
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-18 13:30 ` Vivek Goyal
@ 2015-06-19 6:21 ` Dave Young
-1 siblings, 0 replies; 50+ messages in thread
From: Dave Young @ 2015-06-19 6:21 UTC (permalink / raw)
To: Vivek Goyal
Cc: Eric W. Biederman, Josh Boyer, Theodore Ts'o, Petr Tesarik,
kexec, Linux-Kernel@Vger. Kernel. Org, David Howells
On 06/18/15 at 09:30am, Vivek Goyal wrote:
> On Thu, Jun 18, 2015 at 10:02:09AM +0800, Dave Young wrote:
>
> [..]
> > > Or simply add a new config option KEXEC_VERIFY_SIG_FORCE, so we can return
> > > error in kexec_load and print some error message.
> >
> > Just like below, does this work for you, Ted?
> >
> > ---
> > arch/x86/Kconfig | 7 +++++++
> > kernel/kexec.c | 9 ++++++++-
> > 2 files changed, 15 insertions(+), 1 deletion(-)
> >
> > --- linux.orig/arch/x86/Kconfig
> > +++ linux/arch/x86/Kconfig
> > @@ -1755,6 +1755,13 @@ config KEXEC_VERIFY_SIG
> > verification for the corresponding kernel image type being
> > loaded in order for this to work.
> >
> > +config KEXEC_VERIFY_SIG_FORCE
> > + bool "Enforce kexec signature verifying"
> > + depends on KEXEC_VERIFY_SIG
> > + ---help---
> > + This option disable kexec_load() syscall, only kexec_file_load
> > + can be used.
> > +
>
>
> Hi Dave,
>
> I think we might not need a new config option. A new config option makes
> it little confusing. KEXEC_VERIFY_SIG already implies KEXEC_VERIFY_SIG_FORCE
> (for new syscall). Now extending it to also mean that it should disable old
> syscall is confusing.
Hmm, it is only reasonable when kexec_file_load can support bypassing sig
verifying even when CONFIG_KEXEC_VERIFY_SIG=y.
So agree it is confusing to add a _FORCE new option now.
>
> We already have a sysctl knob to disable kexec kernel loading. But that
> knob disables it on both the syscalls.
>
> May be we can just introduce another command line option say
> "kexec_verify_sig_force" and this will work across both the syscalls and
> will deny loading a unsigned kernel in following two cases.
>
> - Using old syscall
> - Using new syscall if kernel was compiled with KEXEC_VERIFY_SIG=n.
As you said KEXEC_VERIFY_SIG implies KEXEC_VERIFY_SIG_FORCE now so if one
disable it in .config, we have no reason to disable kernel loading without
signature verifying?
>
> This should be simple and get us going in short term.
>
> If we want to disable unsigned kernel loading at compile time, then we
> really need to work on decoupling CONFIG_KEXEC and CONFIG_FILE_KEXEC.
> Introducing another config option is not the way forward, IMHO.
Yes, let's do it in this way since everyone is fine with it.
Thanks
Dave
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-19 6:21 ` Dave Young
0 siblings, 0 replies; 50+ messages in thread
From: Dave Young @ 2015-06-19 6:21 UTC (permalink / raw)
To: Vivek Goyal
Cc: Josh Boyer, Theodore Ts'o, kexec, Petr Tesarik,
Linux-Kernel@Vger. Kernel. Org, David Howells, Eric W. Biederman
On 06/18/15 at 09:30am, Vivek Goyal wrote:
> On Thu, Jun 18, 2015 at 10:02:09AM +0800, Dave Young wrote:
>
> [..]
> > > Or simply add a new config option KEXEC_VERIFY_SIG_FORCE, so we can return
> > > error in kexec_load and print some error message.
> >
> > Just like below, does this work for you, Ted?
> >
> > ---
> > arch/x86/Kconfig | 7 +++++++
> > kernel/kexec.c | 9 ++++++++-
> > 2 files changed, 15 insertions(+), 1 deletion(-)
> >
> > --- linux.orig/arch/x86/Kconfig
> > +++ linux/arch/x86/Kconfig
> > @@ -1755,6 +1755,13 @@ config KEXEC_VERIFY_SIG
> > verification for the corresponding kernel image type being
> > loaded in order for this to work.
> >
> > +config KEXEC_VERIFY_SIG_FORCE
> > + bool "Enforce kexec signature verifying"
> > + depends on KEXEC_VERIFY_SIG
> > + ---help---
> > + This option disable kexec_load() syscall, only kexec_file_load
> > + can be used.
> > +
>
>
> Hi Dave,
>
> I think we might not need a new config option. A new config option makes
> it little confusing. KEXEC_VERIFY_SIG already implies KEXEC_VERIFY_SIG_FORCE
> (for new syscall). Now extending it to also mean that it should disable old
> syscall is confusing.
Hmm, it is only reasonable when kexec_file_load can support bypassing sig
verifying even when CONFIG_KEXEC_VERIFY_SIG=y.
So agree it is confusing to add a _FORCE new option now.
>
> We already have a sysctl knob to disable kexec kernel loading. But that
> knob disables it on both the syscalls.
>
> May be we can just introduce another command line option say
> "kexec_verify_sig_force" and this will work across both the syscalls and
> will deny loading a unsigned kernel in following two cases.
>
> - Using old syscall
> - Using new syscall if kernel was compiled with KEXEC_VERIFY_SIG=n.
As you said KEXEC_VERIFY_SIG implies KEXEC_VERIFY_SIG_FORCE now so if one
disable it in .config, we have no reason to disable kernel loading without
signature verifying?
>
> This should be simple and get us going in short term.
>
> If we want to disable unsigned kernel loading at compile time, then we
> really need to work on decoupling CONFIG_KEXEC and CONFIG_FILE_KEXEC.
> Introducing another config option is not the way forward, IMHO.
Yes, let's do it in this way since everyone is fine with it.
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-17 1:47 ` Vivek Goyal
@ 2015-06-19 7:04 ` Dave Young
-1 siblings, 0 replies; 50+ messages in thread
From: Dave Young @ 2015-06-19 7:04 UTC (permalink / raw)
To: Vivek Goyal
Cc: Eric W. Biederman, Theodore Ts'o, Josh Boyer, David Howells,
kexec, Linux-Kernel@Vger. Kernel. Org, Petr Tesarik
On 06/16/15 at 09:47pm, Vivek Goyal wrote:
> On Tue, Jun 16, 2015 at 08:32:37PM -0500, Eric W. Biederman wrote:
> > Vivek Goyal <vgoyal@redhat.com> writes:
> >
> > > On Tue, Jun 16, 2015 at 02:38:31PM -0500, Eric W. Biederman wrote:
> > >>
> > >> Adding Vivek as he is the one who implemented kexec_file_load.
> > >> I was hoping he would respond to this thread, and it looks like he
> > >> simply has not ever been Cc'd.
> > >>
> > >> Theodore Ts'o <tytso@mit.edu> writes:
> > >>
> > >> > On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
> > >> >> The bits that actually read Secure Boot state out of the UEFI
> > >> >> variables, and apply protections to the machine to avoid compromise
> > >> >> under the SB threat model. Things like disabling the old kexec...
> > >> >
> > >> > I don't have any real interest in using Secure Boot, but I *am*
> > >> > interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to
> > >> > have something similar to what we have with signed modules in terms of
> > >> > CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
> > >> > KEXEC_VERIFY_SIG. This would mean creating a separate flag
> > >> > independent of the one Linus suggested for Secure Boot, but since we
> > >> > have one for signed modules, we do have precedent for this sort of
> > >> > thing.
> > >>
> > >> My overall request with respect to kexec has been that we implement
> > >> things that make sense outside of the bizarre threat model of the Linux
> > >> folks who were talking about secure boot.
> > >>
> > >> nI have not navigated the labyrinth of config options but having a way to
> > >> only boot signed things with kexec seems a completely sensible way to
> > >> operate in the context of signed images.
> > >>
> > >> I don't know how much that will help given that actors with sufficient
> > >> resources have demonstrated the ability to steal private keys, but
> > >> assuming binary signing is an effective technique (or why else do it)
> > >> then having an option to limit kexec to only loading signed images seems
> > >> sensible.
> > >
> > > I went through the mail chain on web and here are my thoughts.
> > >
> > > - So yes, upstream does not have the logic which automatically disables
> > > the old syscall (kexec_load()) on secureboot systems. Distributions
> > > carry those patches.
> > >
> > > - This KEXEC_VERIFY_SIG option only cotrols the behavior for
> > > kexec_file_load() syscall and is not meant to directly affect any
> > > behavior of old syscall (kexec_load()). I think I should have named
> > > it KEXEC_FILE_VERIFY_SIG. Though help text makes it clear.
> > > "Verify kernel signature during kexec_file_load() syscall".
> > >
> > > - I think disabling old system call if KEXEC_VERIFY_SIG() is set
> > > will break existing setup which use old system call by default, except
> > > the case of secureboot system. And old syscall path is well tested
> > > and new syscall might not be in a position to support all the corner
> > > cases, atleast as of now.
> > >
> > > Ted,
> > >
> > > So looks like you are looking for a system/option where you just want to
> > > always make use of kexec_file_load() and disable kexec_load(). This sounds
> > > like you want a kernel where kexec_load() is compiled out and you want
> > > only kexec_file_load() in.
> > >
> > > Right now one can't do that becase kexec_file_load() depends on
> > > CONFIG_KEXEC option.
> > >
> > > I am wondering that how about making CONFIG_KEXEC_FILE_LOAD independent
> > > of CONFIG_KEXEC. That way one can set CONFIG_KEXEC_VERIFY_SIG=y, and
> > > only signed kernel can be kexeced on that system.
> > >
> > > This should gel well with long term strategy of deprecating kexec_load()
> > > at some point of time when kexec_file_load() is ready to completely
> > > replace it.
> >
> > Interesting.
> >
> > I suspect that what we want is to have CONFIG_KEXEC for the core
> > and additional CONFIG_KEXEC_LOAD option that covers that kexec_load call.
> >
> > That should make it trivially easy to disable the kexec_load system call
> > in cases where people care.
>
> Or, we could create another option CONFIG_KEXEC_CORE/CONFIG_KEXEC_COMMON
> which will be automatically selected when either CONFIG_KEXEC or
> CONIG_KEXEC_FILE are selected.
>
> All common code can go under this option and rest can go under respective
> config options.
>
> That way, those who have CONFIG_KEXEC=y in old config files will not be
> broken. They don't have to learn about new options at all.
Vivek, It is slight better for reusing old config file, but CONFIG_KEXEC_LOAD
sounds better. Do we have to maintain the compability for kconfig?
KEXEC_COMMON/KEXEC/KEXEC_FILE_LOAD is a little confusing. CONFIG_KEXEC
should be the common kexec stuff naturally, it is strange to use CONFIG_KEXEC
for only kexec_load syscall.
Thanks
Dave
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-19 7:04 ` Dave Young
0 siblings, 0 replies; 50+ messages in thread
From: Dave Young @ 2015-06-19 7:04 UTC (permalink / raw)
To: Vivek Goyal
Cc: Josh Boyer, Theodore Ts'o, Petr Tesarik, kexec,
Linux-Kernel@Vger. Kernel. Org, David Howells, Eric W. Biederman
On 06/16/15 at 09:47pm, Vivek Goyal wrote:
> On Tue, Jun 16, 2015 at 08:32:37PM -0500, Eric W. Biederman wrote:
> > Vivek Goyal <vgoyal@redhat.com> writes:
> >
> > > On Tue, Jun 16, 2015 at 02:38:31PM -0500, Eric W. Biederman wrote:
> > >>
> > >> Adding Vivek as he is the one who implemented kexec_file_load.
> > >> I was hoping he would respond to this thread, and it looks like he
> > >> simply has not ever been Cc'd.
> > >>
> > >> Theodore Ts'o <tytso@mit.edu> writes:
> > >>
> > >> > On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
> > >> >> The bits that actually read Secure Boot state out of the UEFI
> > >> >> variables, and apply protections to the machine to avoid compromise
> > >> >> under the SB threat model. Things like disabling the old kexec...
> > >> >
> > >> > I don't have any real interest in using Secure Boot, but I *am*
> > >> > interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to
> > >> > have something similar to what we have with signed modules in terms of
> > >> > CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
> > >> > KEXEC_VERIFY_SIG. This would mean creating a separate flag
> > >> > independent of the one Linus suggested for Secure Boot, but since we
> > >> > have one for signed modules, we do have precedent for this sort of
> > >> > thing.
> > >>
> > >> My overall request with respect to kexec has been that we implement
> > >> things that make sense outside of the bizarre threat model of the Linux
> > >> folks who were talking about secure boot.
> > >>
> > >> nI have not navigated the labyrinth of config options but having a way to
> > >> only boot signed things with kexec seems a completely sensible way to
> > >> operate in the context of signed images.
> > >>
> > >> I don't know how much that will help given that actors with sufficient
> > >> resources have demonstrated the ability to steal private keys, but
> > >> assuming binary signing is an effective technique (or why else do it)
> > >> then having an option to limit kexec to only loading signed images seems
> > >> sensible.
> > >
> > > I went through the mail chain on web and here are my thoughts.
> > >
> > > - So yes, upstream does not have the logic which automatically disables
> > > the old syscall (kexec_load()) on secureboot systems. Distributions
> > > carry those patches.
> > >
> > > - This KEXEC_VERIFY_SIG option only cotrols the behavior for
> > > kexec_file_load() syscall and is not meant to directly affect any
> > > behavior of old syscall (kexec_load()). I think I should have named
> > > it KEXEC_FILE_VERIFY_SIG. Though help text makes it clear.
> > > "Verify kernel signature during kexec_file_load() syscall".
> > >
> > > - I think disabling old system call if KEXEC_VERIFY_SIG() is set
> > > will break existing setup which use old system call by default, except
> > > the case of secureboot system. And old syscall path is well tested
> > > and new syscall might not be in a position to support all the corner
> > > cases, atleast as of now.
> > >
> > > Ted,
> > >
> > > So looks like you are looking for a system/option where you just want to
> > > always make use of kexec_file_load() and disable kexec_load(). This sounds
> > > like you want a kernel where kexec_load() is compiled out and you want
> > > only kexec_file_load() in.
> > >
> > > Right now one can't do that becase kexec_file_load() depends on
> > > CONFIG_KEXEC option.
> > >
> > > I am wondering that how about making CONFIG_KEXEC_FILE_LOAD independent
> > > of CONFIG_KEXEC. That way one can set CONFIG_KEXEC_VERIFY_SIG=y, and
> > > only signed kernel can be kexeced on that system.
> > >
> > > This should gel well with long term strategy of deprecating kexec_load()
> > > at some point of time when kexec_file_load() is ready to completely
> > > replace it.
> >
> > Interesting.
> >
> > I suspect that what we want is to have CONFIG_KEXEC for the core
> > and additional CONFIG_KEXEC_LOAD option that covers that kexec_load call.
> >
> > That should make it trivially easy to disable the kexec_load system call
> > in cases where people care.
>
> Or, we could create another option CONFIG_KEXEC_CORE/CONFIG_KEXEC_COMMON
> which will be automatically selected when either CONFIG_KEXEC or
> CONIG_KEXEC_FILE are selected.
>
> All common code can go under this option and rest can go under respective
> config options.
>
> That way, those who have CONFIG_KEXEC=y in old config files will not be
> broken. They don't have to learn about new options at all.
Vivek, It is slight better for reusing old config file, but CONFIG_KEXEC_LOAD
sounds better. Do we have to maintain the compability for kconfig?
KEXEC_COMMON/KEXEC/KEXEC_FILE_LOAD is a little confusing. CONFIG_KEXEC
should be the common kexec stuff naturally, it is strange to use CONFIG_KEXEC
for only kexec_load syscall.
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-19 6:21 ` Dave Young
@ 2015-06-19 8:18 ` Dave Young
-1 siblings, 0 replies; 50+ messages in thread
From: Dave Young @ 2015-06-19 8:18 UTC (permalink / raw)
To: Vivek Goyal
Cc: Eric W. Biederman, Josh Boyer, Theodore Ts'o, Petr Tesarik,
kexec, Linux-Kernel@Vger. Kernel. Org, David Howells
> > If we want to disable unsigned kernel loading at compile time, then we
> > really need to work on decoupling CONFIG_KEXEC and CONFIG_FILE_KEXEC.
> > Introducing another config option is not the way forward, IMHO.
>
> Yes, let's do it in this way since everyone is fine with it.
I will work on a patch if nobody else have interest or no time on it.
Thanks
Dave
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-19 8:18 ` Dave Young
0 siblings, 0 replies; 50+ messages in thread
From: Dave Young @ 2015-06-19 8:18 UTC (permalink / raw)
To: Vivek Goyal
Cc: Josh Boyer, Theodore Ts'o, kexec, Petr Tesarik,
Linux-Kernel@Vger. Kernel. Org, David Howells, Eric W. Biederman
> > If we want to disable unsigned kernel loading at compile time, then we
> > really need to work on decoupling CONFIG_KEXEC and CONFIG_FILE_KEXEC.
> > Introducing another config option is not the way forward, IMHO.
>
> Yes, let's do it in this way since everyone is fine with it.
I will work on a patch if nobody else have interest or no time on it.
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-19 7:04 ` Dave Young
@ 2015-06-19 13:09 ` Vivek Goyal
-1 siblings, 0 replies; 50+ messages in thread
From: Vivek Goyal @ 2015-06-19 13:09 UTC (permalink / raw)
To: Dave Young
Cc: Eric W. Biederman, Theodore Ts'o, Josh Boyer, David Howells,
kexec, Linux-Kernel@Vger. Kernel. Org, Petr Tesarik
On Fri, Jun 19, 2015 at 03:04:31PM +0800, Dave Young wrote:
> On 06/16/15 at 09:47pm, Vivek Goyal wrote:
> > On Tue, Jun 16, 2015 at 08:32:37PM -0500, Eric W. Biederman wrote:
> > > Vivek Goyal <vgoyal@redhat.com> writes:
> > >
> > > > On Tue, Jun 16, 2015 at 02:38:31PM -0500, Eric W. Biederman wrote:
> > > >>
> > > >> Adding Vivek as he is the one who implemented kexec_file_load.
> > > >> I was hoping he would respond to this thread, and it looks like he
> > > >> simply has not ever been Cc'd.
> > > >>
> > > >> Theodore Ts'o <tytso@mit.edu> writes:
> > > >>
> > > >> > On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
> > > >> >> The bits that actually read Secure Boot state out of the UEFI
> > > >> >> variables, and apply protections to the machine to avoid compromise
> > > >> >> under the SB threat model. Things like disabling the old kexec...
> > > >> >
> > > >> > I don't have any real interest in using Secure Boot, but I *am*
> > > >> > interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to
> > > >> > have something similar to what we have with signed modules in terms of
> > > >> > CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
> > > >> > KEXEC_VERIFY_SIG. This would mean creating a separate flag
> > > >> > independent of the one Linus suggested for Secure Boot, but since we
> > > >> > have one for signed modules, we do have precedent for this sort of
> > > >> > thing.
> > > >>
> > > >> My overall request with respect to kexec has been that we implement
> > > >> things that make sense outside of the bizarre threat model of the Linux
> > > >> folks who were talking about secure boot.
> > > >>
> > > >> nI have not navigated the labyrinth of config options but having a way to
> > > >> only boot signed things with kexec seems a completely sensible way to
> > > >> operate in the context of signed images.
> > > >>
> > > >> I don't know how much that will help given that actors with sufficient
> > > >> resources have demonstrated the ability to steal private keys, but
> > > >> assuming binary signing is an effective technique (or why else do it)
> > > >> then having an option to limit kexec to only loading signed images seems
> > > >> sensible.
> > > >
> > > > I went through the mail chain on web and here are my thoughts.
> > > >
> > > > - So yes, upstream does not have the logic which automatically disables
> > > > the old syscall (kexec_load()) on secureboot systems. Distributions
> > > > carry those patches.
> > > >
> > > > - This KEXEC_VERIFY_SIG option only cotrols the behavior for
> > > > kexec_file_load() syscall and is not meant to directly affect any
> > > > behavior of old syscall (kexec_load()). I think I should have named
> > > > it KEXEC_FILE_VERIFY_SIG. Though help text makes it clear.
> > > > "Verify kernel signature during kexec_file_load() syscall".
> > > >
> > > > - I think disabling old system call if KEXEC_VERIFY_SIG() is set
> > > > will break existing setup which use old system call by default, except
> > > > the case of secureboot system. And old syscall path is well tested
> > > > and new syscall might not be in a position to support all the corner
> > > > cases, atleast as of now.
> > > >
> > > > Ted,
> > > >
> > > > So looks like you are looking for a system/option where you just want to
> > > > always make use of kexec_file_load() and disable kexec_load(). This sounds
> > > > like you want a kernel where kexec_load() is compiled out and you want
> > > > only kexec_file_load() in.
> > > >
> > > > Right now one can't do that becase kexec_file_load() depends on
> > > > CONFIG_KEXEC option.
> > > >
> > > > I am wondering that how about making CONFIG_KEXEC_FILE_LOAD independent
> > > > of CONFIG_KEXEC. That way one can set CONFIG_KEXEC_VERIFY_SIG=y, and
> > > > only signed kernel can be kexeced on that system.
> > > >
> > > > This should gel well with long term strategy of deprecating kexec_load()
> > > > at some point of time when kexec_file_load() is ready to completely
> > > > replace it.
> > >
> > > Interesting.
> > >
> > > I suspect that what we want is to have CONFIG_KEXEC for the core
> > > and additional CONFIG_KEXEC_LOAD option that covers that kexec_load call.
> > >
> > > That should make it trivially easy to disable the kexec_load system call
> > > in cases where people care.
> >
> > Or, we could create another option CONFIG_KEXEC_CORE/CONFIG_KEXEC_COMMON
> > which will be automatically selected when either CONFIG_KEXEC or
> > CONIG_KEXEC_FILE are selected.
> >
> > All common code can go under this option and rest can go under respective
> > config options.
> >
> > That way, those who have CONFIG_KEXEC=y in old config files will not be
> > broken. They don't have to learn about new options at all.
>
> Vivek, It is slight better for reusing old config file, but CONFIG_KEXEC_LOAD
> sounds better. Do we have to maintain the compability for kconfig?
>
> KEXEC_COMMON/KEXEC/KEXEC_FILE_LOAD is a little confusing. CONFIG_KEXEC
> should be the common kexec stuff naturally, it is strange to use CONFIG_KEXEC
> for only kexec_load syscall.
Hi Dave,
I think as a user I would like my old config file to work with new kernel.
It is a good idea to keep old config options until and unless we have a
very good reason.
To me following should be reasonable.
CONFIG_KEXEC --> Enable old syscall
CONFIG_FILE_KEXEC --> Enable new syscall
In fact we might not have to introduce CONFIG_KEXEC_COMMON. We can
just use
#ifdef (CONFIG_KEXEC) | ifdef (CONFIG_FILE_KEXEC
/* Common code between two syscalls */
#endif
That way we don't introduce any new config options and stick to existing
ones.
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-19 13:09 ` Vivek Goyal
0 siblings, 0 replies; 50+ messages in thread
From: Vivek Goyal @ 2015-06-19 13:09 UTC (permalink / raw)
To: Dave Young
Cc: Josh Boyer, Theodore Ts'o, Petr Tesarik, kexec,
Linux-Kernel@Vger. Kernel. Org, David Howells, Eric W. Biederman
On Fri, Jun 19, 2015 at 03:04:31PM +0800, Dave Young wrote:
> On 06/16/15 at 09:47pm, Vivek Goyal wrote:
> > On Tue, Jun 16, 2015 at 08:32:37PM -0500, Eric W. Biederman wrote:
> > > Vivek Goyal <vgoyal@redhat.com> writes:
> > >
> > > > On Tue, Jun 16, 2015 at 02:38:31PM -0500, Eric W. Biederman wrote:
> > > >>
> > > >> Adding Vivek as he is the one who implemented kexec_file_load.
> > > >> I was hoping he would respond to this thread, and it looks like he
> > > >> simply has not ever been Cc'd.
> > > >>
> > > >> Theodore Ts'o <tytso@mit.edu> writes:
> > > >>
> > > >> > On Mon, Jun 15, 2015 at 09:37:05AM -0400, Josh Boyer wrote:
> > > >> >> The bits that actually read Secure Boot state out of the UEFI
> > > >> >> variables, and apply protections to the machine to avoid compromise
> > > >> >> under the SB threat model. Things like disabling the old kexec...
> > > >> >
> > > >> > I don't have any real interest in using Secure Boot, but I *am*
> > > >> > interested in using CONFIG_KEXEC_VERIFY_SIG[1]. So perhaps we need to
> > > >> > have something similar to what we have with signed modules in terms of
> > > >> > CONFIG_MODULE_SIG_FORCE and module/sig_enforce, but for
> > > >> > KEXEC_VERIFY_SIG. This would mean creating a separate flag
> > > >> > independent of the one Linus suggested for Secure Boot, but since we
> > > >> > have one for signed modules, we do have precedent for this sort of
> > > >> > thing.
> > > >>
> > > >> My overall request with respect to kexec has been that we implement
> > > >> things that make sense outside of the bizarre threat model of the Linux
> > > >> folks who were talking about secure boot.
> > > >>
> > > >> nI have not navigated the labyrinth of config options but having a way to
> > > >> only boot signed things with kexec seems a completely sensible way to
> > > >> operate in the context of signed images.
> > > >>
> > > >> I don't know how much that will help given that actors with sufficient
> > > >> resources have demonstrated the ability to steal private keys, but
> > > >> assuming binary signing is an effective technique (or why else do it)
> > > >> then having an option to limit kexec to only loading signed images seems
> > > >> sensible.
> > > >
> > > > I went through the mail chain on web and here are my thoughts.
> > > >
> > > > - So yes, upstream does not have the logic which automatically disables
> > > > the old syscall (kexec_load()) on secureboot systems. Distributions
> > > > carry those patches.
> > > >
> > > > - This KEXEC_VERIFY_SIG option only cotrols the behavior for
> > > > kexec_file_load() syscall and is not meant to directly affect any
> > > > behavior of old syscall (kexec_load()). I think I should have named
> > > > it KEXEC_FILE_VERIFY_SIG. Though help text makes it clear.
> > > > "Verify kernel signature during kexec_file_load() syscall".
> > > >
> > > > - I think disabling old system call if KEXEC_VERIFY_SIG() is set
> > > > will break existing setup which use old system call by default, except
> > > > the case of secureboot system. And old syscall path is well tested
> > > > and new syscall might not be in a position to support all the corner
> > > > cases, atleast as of now.
> > > >
> > > > Ted,
> > > >
> > > > So looks like you are looking for a system/option where you just want to
> > > > always make use of kexec_file_load() and disable kexec_load(). This sounds
> > > > like you want a kernel where kexec_load() is compiled out and you want
> > > > only kexec_file_load() in.
> > > >
> > > > Right now one can't do that becase kexec_file_load() depends on
> > > > CONFIG_KEXEC option.
> > > >
> > > > I am wondering that how about making CONFIG_KEXEC_FILE_LOAD independent
> > > > of CONFIG_KEXEC. That way one can set CONFIG_KEXEC_VERIFY_SIG=y, and
> > > > only signed kernel can be kexeced on that system.
> > > >
> > > > This should gel well with long term strategy of deprecating kexec_load()
> > > > at some point of time when kexec_file_load() is ready to completely
> > > > replace it.
> > >
> > > Interesting.
> > >
> > > I suspect that what we want is to have CONFIG_KEXEC for the core
> > > and additional CONFIG_KEXEC_LOAD option that covers that kexec_load call.
> > >
> > > That should make it trivially easy to disable the kexec_load system call
> > > in cases where people care.
> >
> > Or, we could create another option CONFIG_KEXEC_CORE/CONFIG_KEXEC_COMMON
> > which will be automatically selected when either CONFIG_KEXEC or
> > CONIG_KEXEC_FILE are selected.
> >
> > All common code can go under this option and rest can go under respective
> > config options.
> >
> > That way, those who have CONFIG_KEXEC=y in old config files will not be
> > broken. They don't have to learn about new options at all.
>
> Vivek, It is slight better for reusing old config file, but CONFIG_KEXEC_LOAD
> sounds better. Do we have to maintain the compability for kconfig?
>
> KEXEC_COMMON/KEXEC/KEXEC_FILE_LOAD is a little confusing. CONFIG_KEXEC
> should be the common kexec stuff naturally, it is strange to use CONFIG_KEXEC
> for only kexec_load syscall.
Hi Dave,
I think as a user I would like my old config file to work with new kernel.
It is a good idea to keep old config options until and unless we have a
very good reason.
To me following should be reasonable.
CONFIG_KEXEC --> Enable old syscall
CONFIG_FILE_KEXEC --> Enable new syscall
In fact we might not have to introduce CONFIG_KEXEC_COMMON. We can
just use
#ifdef (CONFIG_KEXEC) | ifdef (CONFIG_FILE_KEXEC
/* Common code between two syscalls */
#endif
That way we don't introduce any new config options and stick to existing
ones.
Thanks
Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-19 8:18 ` Dave Young
@ 2015-06-19 13:09 ` Vivek Goyal
-1 siblings, 0 replies; 50+ messages in thread
From: Vivek Goyal @ 2015-06-19 13:09 UTC (permalink / raw)
To: Dave Young
Cc: Eric W. Biederman, Josh Boyer, Theodore Ts'o, Petr Tesarik,
kexec, Linux-Kernel@Vger. Kernel. Org, David Howells
On Fri, Jun 19, 2015 at 04:18:16PM +0800, Dave Young wrote:
> > > If we want to disable unsigned kernel loading at compile time, then we
> > > really need to work on decoupling CONFIG_KEXEC and CONFIG_FILE_KEXEC.
> > > Introducing another config option is not the way forward, IMHO.
> >
> > Yes, let's do it in this way since everyone is fine with it.
>
> I will work on a patch if nobody else have interest or no time on it.
Thanks Dave. Will be good if you can get this done.
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-19 13:09 ` Vivek Goyal
0 siblings, 0 replies; 50+ messages in thread
From: Vivek Goyal @ 2015-06-19 13:09 UTC (permalink / raw)
To: Dave Young
Cc: Josh Boyer, Theodore Ts'o, kexec, Petr Tesarik,
Linux-Kernel@Vger. Kernel. Org, David Howells, Eric W. Biederman
On Fri, Jun 19, 2015 at 04:18:16PM +0800, Dave Young wrote:
> > > If we want to disable unsigned kernel loading at compile time, then we
> > > really need to work on decoupling CONFIG_KEXEC and CONFIG_FILE_KEXEC.
> > > Introducing another config option is not the way forward, IMHO.
> >
> > Yes, let's do it in this way since everyone is fine with it.
>
> I will work on a patch if nobody else have interest or no time on it.
Thanks Dave. Will be good if you can get this done.
Thanks
Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-19 13:09 ` Vivek Goyal
@ 2015-06-25 8:48 ` Dave Young
-1 siblings, 0 replies; 50+ messages in thread
From: Dave Young @ 2015-06-25 8:48 UTC (permalink / raw)
To: Vivek Goyal
Cc: Eric W. Biederman, Josh Boyer, Theodore Ts'o, Petr Tesarik,
kexec, Linux-Kernel@Vger. Kernel. Org, David Howells
On 06/19/15 at 09:09am, Vivek Goyal wrote:
> On Fri, Jun 19, 2015 at 04:18:16PM +0800, Dave Young wrote:
> > > > If we want to disable unsigned kernel loading at compile time, then we
> > > > really need to work on decoupling CONFIG_KEXEC and CONFIG_FILE_KEXEC.
> > > > Introducing another config option is not the way forward, IMHO.
> > >
> > > Yes, let's do it in this way since everyone is fine with it.
> >
> > I will work on a patch if nobody else have interest or no time on it.
>
> Thanks Dave. Will be good if you can get this done.
Vivek, I worked out some draft patches here:
https://github.com/daveyoung/linux/commits/kexec-syscall-cleanup
Basiclly I split kexec_file first, then add CONFIG_KEXEC_CORE kconfig option
then split kexec_load code from general code.
There's a lot of #ifdef CONFIG_KEXEC in kernel source, because CONFIG_KEXEC
can be disabled so I changed all kernel general and x86 #ifdef to use
CONFIG_KEXEC_CORE if necessary. For other arches dependent code with #ifdef
I did not change anything other than the new Kconfig option. It will works
because only x86 support KEXEC_FILE.
Please take a look if you have time, if this is not what you want please let
me know.
I will have no time this week, only did building test, will do more test next
week, if everything is ok I can send out the patches to list for review.
Thanks
Dave
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-25 8:48 ` Dave Young
0 siblings, 0 replies; 50+ messages in thread
From: Dave Young @ 2015-06-25 8:48 UTC (permalink / raw)
To: Vivek Goyal
Cc: Josh Boyer, Theodore Ts'o, kexec, Petr Tesarik,
Linux-Kernel@Vger. Kernel. Org, David Howells, Eric W. Biederman
On 06/19/15 at 09:09am, Vivek Goyal wrote:
> On Fri, Jun 19, 2015 at 04:18:16PM +0800, Dave Young wrote:
> > > > If we want to disable unsigned kernel loading at compile time, then we
> > > > really need to work on decoupling CONFIG_KEXEC and CONFIG_FILE_KEXEC.
> > > > Introducing another config option is not the way forward, IMHO.
> > >
> > > Yes, let's do it in this way since everyone is fine with it.
> >
> > I will work on a patch if nobody else have interest or no time on it.
>
> Thanks Dave. Will be good if you can get this done.
Vivek, I worked out some draft patches here:
https://github.com/daveyoung/linux/commits/kexec-syscall-cleanup
Basiclly I split kexec_file first, then add CONFIG_KEXEC_CORE kconfig option
then split kexec_load code from general code.
There's a lot of #ifdef CONFIG_KEXEC in kernel source, because CONFIG_KEXEC
can be disabled so I changed all kernel general and x86 #ifdef to use
CONFIG_KEXEC_CORE if necessary. For other arches dependent code with #ifdef
I did not change anything other than the new Kconfig option. It will works
because only x86 support KEXEC_FILE.
Please take a look if you have time, if this is not what you want please let
me know.
I will have no time this week, only did building test, will do more test next
week, if everything is ok I can send out the patches to list for review.
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-25 8:48 ` Dave Young
@ 2015-06-25 15:59 ` Vivek Goyal
-1 siblings, 0 replies; 50+ messages in thread
From: Vivek Goyal @ 2015-06-25 15:59 UTC (permalink / raw)
To: Dave Young
Cc: Eric W. Biederman, Josh Boyer, Theodore Ts'o, Petr Tesarik,
kexec, Linux-Kernel@Vger. Kernel. Org, David Howells
On Thu, Jun 25, 2015 at 04:48:18PM +0800, Dave Young wrote:
> On 06/19/15 at 09:09am, Vivek Goyal wrote:
> > On Fri, Jun 19, 2015 at 04:18:16PM +0800, Dave Young wrote:
> > > > > If we want to disable unsigned kernel loading at compile time, then we
> > > > > really need to work on decoupling CONFIG_KEXEC and CONFIG_FILE_KEXEC.
> > > > > Introducing another config option is not the way forward, IMHO.
> > > >
> > > > Yes, let's do it in this way since everyone is fine with it.
> > >
> > > I will work on a patch if nobody else have interest or no time on it.
> >
> > Thanks Dave. Will be good if you can get this done.
>
> Vivek, I worked out some draft patches here:
> https://github.com/daveyoung/linux/commits/kexec-syscall-cleanup
>
> Basiclly I split kexec_file first, then add CONFIG_KEXEC_CORE kconfig option
> then split kexec_load code from general code.
>
> There's a lot of #ifdef CONFIG_KEXEC in kernel source, because CONFIG_KEXEC
> can be disabled so I changed all kernel general and x86 #ifdef to use
> CONFIG_KEXEC_CORE if necessary. For other arches dependent code with #ifdef
> I did not change anything other than the new Kconfig option. It will works
> because only x86 support KEXEC_FILE.
>
> Please take a look if you have time, if this is not what you want please let
> me know.
>
> I will have no time this week, only did building test, will do more test next
> week, if everything is ok I can send out the patches to list for review.
Hi Dave,
I have put few comments in github. Please have a look. Once you have
another version of patches, I will have another look.
Thanks
Vivek
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-25 15:59 ` Vivek Goyal
0 siblings, 0 replies; 50+ messages in thread
From: Vivek Goyal @ 2015-06-25 15:59 UTC (permalink / raw)
To: Dave Young
Cc: Josh Boyer, Theodore Ts'o, kexec, Petr Tesarik,
Linux-Kernel@Vger. Kernel. Org, David Howells, Eric W. Biederman
On Thu, Jun 25, 2015 at 04:48:18PM +0800, Dave Young wrote:
> On 06/19/15 at 09:09am, Vivek Goyal wrote:
> > On Fri, Jun 19, 2015 at 04:18:16PM +0800, Dave Young wrote:
> > > > > If we want to disable unsigned kernel loading at compile time, then we
> > > > > really need to work on decoupling CONFIG_KEXEC and CONFIG_FILE_KEXEC.
> > > > > Introducing another config option is not the way forward, IMHO.
> > > >
> > > > Yes, let's do it in this way since everyone is fine with it.
> > >
> > > I will work on a patch if nobody else have interest or no time on it.
> >
> > Thanks Dave. Will be good if you can get this done.
>
> Vivek, I worked out some draft patches here:
> https://github.com/daveyoung/linux/commits/kexec-syscall-cleanup
>
> Basiclly I split kexec_file first, then add CONFIG_KEXEC_CORE kconfig option
> then split kexec_load code from general code.
>
> There's a lot of #ifdef CONFIG_KEXEC in kernel source, because CONFIG_KEXEC
> can be disabled so I changed all kernel general and x86 #ifdef to use
> CONFIG_KEXEC_CORE if necessary. For other arches dependent code with #ifdef
> I did not change anything other than the new Kconfig option. It will works
> because only x86 support KEXEC_FILE.
>
> Please take a look if you have time, if this is not what you want please let
> me know.
>
> I will have no time this week, only did building test, will do more test next
> week, if everything is ok I can send out the patches to list for review.
Hi Dave,
I have put few comments in github. Please have a look. Once you have
another version of patches, I will have another look.
Thanks
Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
2015-06-25 15:59 ` Vivek Goyal
@ 2015-06-26 1:59 ` Dave Young
-1 siblings, 0 replies; 50+ messages in thread
From: Dave Young @ 2015-06-26 1:59 UTC (permalink / raw)
To: Vivek Goyal
Cc: Eric W. Biederman, Josh Boyer, Theodore Ts'o, Petr Tesarik,
kexec, Linux-Kernel@Vger. Kernel. Org, David Howells
On 06/25/15 at 11:59am, Vivek Goyal wrote:
> On Thu, Jun 25, 2015 at 04:48:18PM +0800, Dave Young wrote:
> > On 06/19/15 at 09:09am, Vivek Goyal wrote:
> > > On Fri, Jun 19, 2015 at 04:18:16PM +0800, Dave Young wrote:
> > > > > > If we want to disable unsigned kernel loading at compile time, then we
> > > > > > really need to work on decoupling CONFIG_KEXEC and CONFIG_FILE_KEXEC.
> > > > > > Introducing another config option is not the way forward, IMHO.
> > > > >
> > > > > Yes, let's do it in this way since everyone is fine with it.
> > > >
> > > > I will work on a patch if nobody else have interest or no time on it.
> > >
> > > Thanks Dave. Will be good if you can get this done.
> >
> > Vivek, I worked out some draft patches here:
> > https://github.com/daveyoung/linux/commits/kexec-syscall-cleanup
> >
> > Basiclly I split kexec_file first, then add CONFIG_KEXEC_CORE kconfig option
> > then split kexec_load code from general code.
> >
> > There's a lot of #ifdef CONFIG_KEXEC in kernel source, because CONFIG_KEXEC
> > can be disabled so I changed all kernel general and x86 #ifdef to use
> > CONFIG_KEXEC_CORE if necessary. For other arches dependent code with #ifdef
> > I did not change anything other than the new Kconfig option. It will works
> > because only x86 support KEXEC_FILE.
> >
> > Please take a look if you have time, if this is not what you want please let
> > me know.
> >
> > I will have no time this week, only did building test, will do more test next
> > week, if everything is ok I can send out the patches to list for review.
>
> Hi Dave,
>
> I have put few comments in github. Please have a look. Once you have
> another version of patches, I will have another look.
Vivek, thanks a lot. Will have a look.
Dave
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: kexec_load(2) bypasses signature verification
@ 2015-06-26 1:59 ` Dave Young
0 siblings, 0 replies; 50+ messages in thread
From: Dave Young @ 2015-06-26 1:59 UTC (permalink / raw)
To: Vivek Goyal
Cc: Josh Boyer, Theodore Ts'o, kexec, Petr Tesarik,
Linux-Kernel@Vger. Kernel. Org, David Howells, Eric W. Biederman
On 06/25/15 at 11:59am, Vivek Goyal wrote:
> On Thu, Jun 25, 2015 at 04:48:18PM +0800, Dave Young wrote:
> > On 06/19/15 at 09:09am, Vivek Goyal wrote:
> > > On Fri, Jun 19, 2015 at 04:18:16PM +0800, Dave Young wrote:
> > > > > > If we want to disable unsigned kernel loading at compile time, then we
> > > > > > really need to work on decoupling CONFIG_KEXEC and CONFIG_FILE_KEXEC.
> > > > > > Introducing another config option is not the way forward, IMHO.
> > > > >
> > > > > Yes, let's do it in this way since everyone is fine with it.
> > > >
> > > > I will work on a patch if nobody else have interest or no time on it.
> > >
> > > Thanks Dave. Will be good if you can get this done.
> >
> > Vivek, I worked out some draft patches here:
> > https://github.com/daveyoung/linux/commits/kexec-syscall-cleanup
> >
> > Basiclly I split kexec_file first, then add CONFIG_KEXEC_CORE kconfig option
> > then split kexec_load code from general code.
> >
> > There's a lot of #ifdef CONFIG_KEXEC in kernel source, because CONFIG_KEXEC
> > can be disabled so I changed all kernel general and x86 #ifdef to use
> > CONFIG_KEXEC_CORE if necessary. For other arches dependent code with #ifdef
> > I did not change anything other than the new Kconfig option. It will works
> > because only x86 support KEXEC_FILE.
> >
> > Please take a look if you have time, if this is not what you want please let
> > me know.
> >
> > I will have no time this week, only did building test, will do more test next
> > week, if everything is ok I can send out the patches to list for review.
>
> Hi Dave,
>
> I have put few comments in github. Please have a look. Once you have
> another version of patches, I will have another look.
Vivek, thanks a lot. Will have a look.
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~2015-06-26 1:59 UTC | newest]
Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-15 3:50 kexec_load(2) bypasses signature verification Theodore Ts'o
2015-06-15 3:50 ` Theodore Ts'o
2015-06-15 9:11 ` Dave Young
2015-06-15 9:28 ` Petr Tesarik
2015-06-15 12:14 ` Josh Boyer
2015-06-15 12:14 ` Josh Boyer
2015-06-15 13:17 ` Theodore Ts'o
2015-06-15 13:17 ` Theodore Ts'o
2015-06-15 13:37 ` Josh Boyer
2015-06-15 13:37 ` Josh Boyer
2015-06-15 20:01 ` Theodore Ts'o
2015-06-15 20:01 ` Theodore Ts'o
2015-06-16 19:38 ` Eric W. Biederman
2015-06-16 19:38 ` Eric W. Biederman
2015-06-16 20:27 ` Vivek Goyal
2015-06-16 20:27 ` Vivek Goyal
2015-06-17 1:32 ` Eric W. Biederman
2015-06-17 1:32 ` Eric W. Biederman
2015-06-17 1:47 ` Vivek Goyal
2015-06-17 1:47 ` Vivek Goyal
2015-06-18 1:16 ` Dave Young
2015-06-18 1:16 ` Dave Young
2015-06-18 2:02 ` Dave Young
2015-06-18 2:02 ` Dave Young
2015-06-18 13:30 ` Vivek Goyal
2015-06-18 13:30 ` Vivek Goyal
2015-06-18 14:41 ` Eric W. Biederman
2015-06-18 14:41 ` Eric W. Biederman
2015-06-19 6:21 ` Dave Young
2015-06-19 6:21 ` Dave Young
2015-06-19 8:18 ` Dave Young
2015-06-19 8:18 ` Dave Young
2015-06-19 13:09 ` Vivek Goyal
2015-06-19 13:09 ` Vivek Goyal
2015-06-25 8:48 ` Dave Young
2015-06-25 8:48 ` Dave Young
2015-06-25 15:59 ` Vivek Goyal
2015-06-25 15:59 ` Vivek Goyal
2015-06-26 1:59 ` Dave Young
2015-06-26 1:59 ` Dave Young
2015-06-19 7:04 ` Dave Young
2015-06-19 7:04 ` Dave Young
2015-06-19 13:09 ` Vivek Goyal
2015-06-19 13:09 ` Vivek Goyal
2015-06-17 3:26 ` Theodore Ts'o
2015-06-17 3:26 ` Theodore Ts'o
2015-06-17 10:55 ` One Thousand Gnomes
2015-06-17 10:55 ` One Thousand Gnomes
2015-06-18 1:25 ` Dave Young
2015-06-18 1:25 ` Dave Young
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.