[opensuse-kernel] kexec with secure boot enabled?
Hi, In bug https://bugzilla.opensuse.org/show_bug.cgi?id=1075051#c3 Steffen suspects different settings for kexec with secure boot enabled in Leap 15 vs TW. Is that that case? If so, intentional? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Tue, 09 Jan 2018 15:00:39 +0100, Ludwig Nussel wrote:
Hi,
In bug https://bugzilla.opensuse.org/show_bug.cgi?id=1075051#c3 Steffen suspects different settings for kexec with secure boot enabled in Leap 15 vs TW. Is that that case? If so, intentional?
SLE and Leap contain more secure boot patches than TW. It's because the lock-down patches are still not accepted by upstream. And, one of them is indeed to disable kexec_load syscall in secure boot. But note that the kexec_load_file syscall is still allowed in secure boot mode. So if kexec loads the kernel with -s option, it should work on SLE/Leap, too. Adding Joey who have better clue on this to Cc. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Tuesday 2018-01-09 15:10, Takashi Iwai wrote:
On Tue, 09 Jan 2018 15:00:39 +0100, Ludwig Nussel wrote:
Hi,
In bug https://bugzilla.opensuse.org/show_bug.cgi?id=1075051#c3 Steffen suspects different settings for kexec with secure boot enabled in Leap 15 vs TW. Is that that case? If so, intentional?
SLE and Leap contain more secure boot patches than TW. It's because the lock-down patches are still not accepted by upstream. And, one of them is indeed to disable kexec_load syscall in secure boot.
But note that the kexec_load_file syscall is still allowed in secure boot mode. So if kexec loads the kernel with -s option, it should work on SLE/Leap, too.
Seems not to work: # exec -s -l /download/file_0000 --initrd=/download/file_0001 kexec_file_load failed: Operation not permitted (with leap 15.0) Steffen -- Give orange me give eat orange me eat orange give me eat orange give me you. (chimp Nim, using sign language) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, 10 Jan 2018 10:12:39 +0100, Steffen Winterfeldt wrote:
On Tuesday 2018-01-09 15:10, Takashi Iwai wrote:
On Tue, 09 Jan 2018 15:00:39 +0100, Ludwig Nussel wrote:
Hi,
In bug https://bugzilla.opensuse.org/show_bug.cgi?id=1075051#c3 Steffen suspects different settings for kexec with secure boot enabled in Leap 15 vs TW. Is that that case? If so, intentional?
SLE and Leap contain more secure boot patches than TW. It's because the lock-down patches are still not accepted by upstream. And, one of them is indeed to disable kexec_load syscall in secure boot.
But note that the kexec_load_file syscall is still allowed in secure boot mode. So if kexec loads the kernel with -s option, it should work on SLE/Leap, too.
Seems not to work:
# exec -s -l /download/file_0000 --initrd=/download/file_0001 kexec_file_load failed: Operation not permitted
Ah, it must be specific to Leap 15.0, then. It's missing CONFIG_KEXEC_VERIFY_SIG=y (while SLE-15 has it). There is another lock-down patch to disable kexec_load_file() in secure boot mode unless CONFIG_KEXEC_VERIFY_SIG is set. But a slight concern is whether enabling this would cause another problem. I remember vaguely that we had to disable this option for openSUSE intentionally by some reason. In anyway, care to open a bugzilla entry and put Joey and me to Cc? thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, Jan 10, 2018 at 11:29:40AM +0100, Takashi Iwai wrote:
Ah, it must be specific to Leap 15.0, then. It's missing CONFIG_KEXEC_VERIFY_SIG=y (while SLE-15 has it). There is another lock-down patch to disable kexec_load_file() in secure boot mode unless CONFIG_KEXEC_VERIFY_SIG is set.
right; I find this a PITA, since it prevents you from loading an
unsigned kexec/kdump kernel even when secure boot is off and that
really sucks for testing and compiling own kernels, because it
forces you to sign them for no good reason.
With modules, we have separate MODULE_SIG and MODULE_SIG_FORCE.
The former implements the signing, which is only enforced with
either MODULE_SIG_FORCE, module.sig_enforce boot param or with
kernel_is_locked_down (secureboot).
We don't compile with MODULE_SIG_FORCE.
I think that KEXEC_VERIFY_SIG should be similarly split to
KEXEC_SIG and KEXEC_SIG_FORCE and we should not compile with
KEXEC_SIG_FORCE. The signing would again be
enforced by kernel_is_locked_down.
Does that make sense?
--
Jiri Bohac
On Wed, 10 Jan 2018 12:46:30 +0100, Jiri Bohac wrote:
On Wed, Jan 10, 2018 at 11:29:40AM +0100, Takashi Iwai wrote:
Ah, it must be specific to Leap 15.0, then. It's missing CONFIG_KEXEC_VERIFY_SIG=y (while SLE-15 has it). There is another lock-down patch to disable kexec_load_file() in secure boot mode unless CONFIG_KEXEC_VERIFY_SIG is set.
right; I find this a PITA, since it prevents you from loading an unsigned kexec/kdump kernel even when secure boot is off and that really sucks for testing and compiling own kernels, because it forces you to sign them for no good reason.
With modules, we have separate MODULE_SIG and MODULE_SIG_FORCE. The former implements the signing, which is only enforced with either MODULE_SIG_FORCE, module.sig_enforce boot param or with kernel_is_locked_down (secureboot).
We don't compile with MODULE_SIG_FORCE.
I think that KEXEC_VERIFY_SIG should be similarly split to KEXEC_SIG and KEXEC_SIG_FORCE and we should not compile with KEXEC_SIG_FORCE. The signing would again be enforced by kernel_is_locked_down.
Does that make sense?
One difference in the case of kexec is that there are actually two routes, and one could use the old kexec method for unsigned kernels. And, as discussed in bsc#947816, a part of the problem is that user-space doesn't treat it properly without fallback mechanism. Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, Jan 10, 2018 at 12:59:52PM +0100, Takashi Iwai wrote:
I think that KEXEC_VERIFY_SIG should be similarly split to KEXEC_SIG and KEXEC_SIG_FORCE and we should not compile with KEXEC_SIG_FORCE. The signing would again be enforced by kernel_is_locked_down.
Does that make sense?
One difference in the case of kexec is that there are actually two routes, and one could use the old kexec method for unsigned kernels. And, as discussed in bsc#947816, a part of the problem is that user-space doesn't treat it properly without fallback mechanism.
yes, but falling back to a completely different API just because
the new API only accepts a signed kernel seems wrong.
With secureboot, we now put
if (kernel_is_locked_down()) return -EPERM;
into the kexec_load syscall to completely disable it when
secureboot is on. That's fine, because this syscall can not check
signatures at all. With secureboot off this syscall works.
Yet in the kexec_file_load syscall we force the verification even
without secure boot and that seems wrong.
I would prefer:
- without secure boot: both kexec_load and kexec_file_load work
and ignore the signature
- with secure boot: only kexec_file_load works and requires a
valid signature
--
Jiri Bohac
On Wed, 10 Jan 2018 13:16:17 +0100, Jiri Bohac wrote:
On Wed, Jan 10, 2018 at 12:59:52PM +0100, Takashi Iwai wrote:
I think that KEXEC_VERIFY_SIG should be similarly split to KEXEC_SIG and KEXEC_SIG_FORCE and we should not compile with KEXEC_SIG_FORCE. The signing would again be enforced by kernel_is_locked_down.
Does that make sense?
One difference in the case of kexec is that there are actually two routes, and one could use the old kexec method for unsigned kernels. And, as discussed in bsc#947816, a part of the problem is that user-space doesn't treat it properly without fallback mechanism.
yes, but falling back to a completely different API just because the new API only accepts a signed kernel seems wrong.
With secureboot, we now put if (kernel_is_locked_down()) return -EPERM; into the kexec_load syscall to completely disable it when secureboot is on. That's fine, because this syscall can not check signatures at all. With secureboot off this syscall works.
Yet in the kexec_file_load syscall we force the verification even without secure boot and that seems wrong.
I would prefer: - without secure boot: both kexec_load and kexec_file_load work and ignore the signature
- with secure boot: only kexec_file_load works and requires a valid signature
Yeah, I'm not objecting to that change (and both changes -- in kernel and user-space fallback -- don't conflict). OTOH, adding more Kconfig doesn't sound sexy, either. But if it's no other better way... Anyways, the current lock-down patches are still downstream patches, so basically we can change more on that. I leave the stuff to Joey. The bug 947816 is still open, so we can track the issue with kexec of unsigned kernels there. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (4)
-
Jiri Bohac -
Ludwig Nussel -
Steffen Winterfeldt -
Takashi Iwai