lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 15 Aug 2018 20:44:02 +0200
From:   Yannik Sembritzki <yannik@...britzki.me>
To:     Vivek Goyal <vgoyal@...hat.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        David Howells <dhowells@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Peter Anvin <hpa@...or.com>,
        the arch/x86 maintainers <x86@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Dave Young <dyoung@...hat.com>, Baoquan He <bhe@...hat.com>,
        "Justin M. Forbes" <jforbes@...hat.com>
Subject: Re: [PATCH] Fix kexec forbidding kernels signed with custom platform
 keys to boot


> I am reading that bug and wondering that what broke it. It used to work,
> so some change broke it. 
>
> Previously, I think all the keys used to go in system keyring and it
> used to work. Is it somehow because of split in builtin keyring and
> secondary system keyring. Could it be that fedora key used to show
> up in system keyring previously and it worked but now it shows up
> in secondary system keyring and by default we don't use keys from
> that keyring for signature verification?
The fedora kernel is signed by the "Fedora Secure Boot CA", which is not
in the builtin keyring, but in the secondary keyring. So yes, that is
why kexec fails.
If this did indeed work earlier on, either "Fedora Secure Boot CA" was
in the system keyring previously, or the kernel was signed by the
"Fedora kernel signing key" (which is in the builtin keyring).

The fix I've introduced in my patch is necessary for everyone who uses
their own platform key in any case.

Yannik

>
>> diff --git a/arch/x86/kernel/kexec-bzimage64.c
>> b/arch/x86/kernel/kexec-bzimage64.c
>> index 7326078e..2ba47e24 100644
>> --- a/arch/x86/kernel/kexec-bzimage64.c
>> +++ b/arch/x86/kernel/kexec-bzimage64.c
>> @@ -41,6 +41,9 @@
>>  #define MIN_KERNEL_LOAD_ADDR   0x100000
>>  #define MIN_INITRD_LOAD_ADDR   0x1000000
>>  
>> +// Allow both builtin trusted keys and secondary trusted keys
>> +#define TRUST_FULL_KEYRING     (void *)1UL
>> +
>>  /*
>>   * This is a place holder for all boot loader specific data structure which
>>   * gets allocated in one call but gets freed much later during cleanup
>> @@ -532,7 +535,7 @@ static int bzImage64_cleanup(void *loader_data)
>>  static int bzImage64_verify_sig(const char *kernel, unsigned long
>> kernel_len)
>>  {
>>         return verify_pefile_signature(kernel, kernel_len,
>> -                                      NULL,
>> +                                      TRUST_FULL_KEYRING,
>>                                        VERIFYING_KEXEC_PE_SIGNATURE);
>>  }
>>  #endif
>> --
>>
>> On 15.08.2018 18:54, Linus Torvalds wrote:
>>> This needs more people involved, and at least a sign-off.
>>>
>>> It looks ok, but I think we need a #define for the magical (void *)1UL
>>> thing. I see the use in verify_pkcs7_signature(), but still.
>>>
>>>               Linus
>>>
>>>
>>>
>>> On Wed, Aug 15, 2018 at 3:11 AM Yannik Sembritzki <yannik@...britzki.me> wrote:
>>>> ---
>>>>  arch/x86/kernel/kexec-bzimage64.c | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
>>>> index 7326078e..eaaa125d 100644
>>>> --- a/arch/x86/kernel/kexec-bzimage64.c
>>>> +++ b/arch/x86/kernel/kexec-bzimage64.c
>>>> @@ -532,7 +532,7 @@ static int bzImage64_cleanup(void *loader_data)
>>>>  static int bzImage64_verify_sig(const char *kernel, unsigned long kernel_len)
>>>>  {
>>>>         return verify_pefile_signature(kernel, kernel_len,
>>>> -                                      NULL,
>>>> +                                      (void *)1UL,
>>>>                                        VERIFYING_KEXEC_PE_SIGNATURE);
>>>>  }
>>>>  #endif
>>>> --
>>>> 2.17.1
>>>>
>>>> The exact scenario under which this issue occurs is described here:
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1554113
>>>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ