[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <23576.1519230051@warthog.procyon.org.uk>
Date: Wed, 21 Feb 2018 16:20:51 +0000
From: David Howells <dhowells@...hat.com>
To: Jiri Bohac <jbohac@...e.cz>
Cc: dhowells@...hat.com, linux-security-module@...r.kernel.org,
gnomes@...rguk.ukuu.org.uk, linux-efi@...r.kernel.org,
linux-kernel@...r.kernel.org, jforbes@...hat.com,
Chun-Yi Lee <joeyli.kernel@...il.com>
Subject: Re: [PATCH 08a/30] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE
Jiri Bohac <jbohac@...e.cz> wrote:
> Key verification may and will fail for lots of reasons which is
> just going to make a user's life harder. E.g. you want to kexec
> an old kernel with an expired key. Or your date is just wrong and
> you get -EKEYEXPIRED.
Note that we can't check for expired keys as we can't trust the system clock
to be correct at this point.
> Also, only now I found that some of the error codes the crypto
> code returns yield really confusing messages (e.g.
> kexec_file_load of an unsigned kernel returns -ELIBBAD which
> makes kexec exit with "kexec_file_load failed: Accessing a
> corrupted shared library").
Yeah, that should be fixed.
> Maybe the error code could be unified to -EKEYREJECTED for all
> sorts of key verification failures?
Things like ENOMEM and EINTR definitely need to stay separate (not that I
allow interruption at the moment).
ENOKEY (couldn't find matching key), EINVAL (didn't recognise identifier),
ENOPKG (couldn't find a crypto algo) and EBADMSG (couldn't parse signature)
are arguable. I think there's a valid case for treating ENOKEY, EINVAL and
ENOPKG differently to EKEYREJECTED - more so for ENOKEY. In my opinion,
ENOKEY, EINVAL and ENOPKG are not fatal errors if we're not enforcing
signature checking, but EKEYREJECTED and EBADMSG are.
David
Powered by blists - more mailing lists