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] [day] [month] [year] [list]
Date:   Wed, 12 Jul 2023 10:18:19 -0500
From:   Eric DeVolder <eric.devolder@...cle.com>
To:     Randy Dunlap <rdunlap@...radead.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: linux-next: Tree for Jul 10
 (arch/s390/kernel/machine_kexec_file.c)



On 7/11/23 13:49, Eric DeVolder wrote:
> 
> 
> On 7/10/23 17:15, Randy Dunlap wrote:
>>
>>
>> On 7/10/23 14:27, Eric DeVolder wrote:
>>>
>>>
>>> On 7/10/23 15:23, Eric DeVolder wrote:
>>>>
>>>>
>>>> On 7/10/23 15:11, Randy Dunlap wrote:
>>>>>
>>>>>
>>>>> On 7/9/23 18:38, Stephen Rothwell wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Changes since 20230707:
>>>>>>
>>>>>
>>>>> on s390:
>>>>>
>>>>> ../arch/s390/kernel/machine_kexec_file.c: In function 's390_verify_sig':
>>>>> ../arch/s390/kernel/machine_kexec_file.c:69:15: error: implicit declaration of function 
>>>>> 'verify_pkcs7_signature' [-Werror=implicit-function-declaration]
>>>>>      69 |         ret = verify_pkcs7_signature(kernel, kernel_len,
>>>>>         |               ^~~~~~~~~~~~~~~~~~~~~~
>>>>> cc1: some warnings being treated as errors
>>>>>
>>>>>
>>>>> Full randconfig file is attached.
>>>>>
>>>>
>>>> Randy,
>>>> Thanks for this. This appears to be randconfig testing against linux-next.
>>>> As of right now, linux-next does not contain the v5 that I posted friday.
>>>> The v5 posted friday was picked up by Andrew and over the weekend no fails
>>>> discovered, and the series currently sits in mm-everything branch. So hopefully
>>>> it will appear soon in linux-next!
>>>>
>>>> Let me know if I misunderstand the situation.
>>>> Thanks!
>>>> eric
>>>
>>> Well the root cause is a missing SYSTEM_DATA_VERIFICATION. This was discussed
>>> through MODULE_SIG_FORMAT thread. I don't think v5 changed anything with
>>> respect to this issue, so it will likely reveal itself again.
>>>
>>> Since it was agreed to drop MODULE_SIG_FORMAT, and my attempt to select
>>> SYSTEM_DATA_VERIFICATION results in same circular dependency as with
>>> MODULE_SIG_FORMAT, I'm unsure how to proceed.
>>>
>>> The arch/s390/Kconfig S390 option has a 'select KEXEC' (but not KEXEC_FILE),
>>> maybe we consider adding a 'select SYSTEM_DATA_VERIFICATION' as well?
>>
>> Sure, since some other configs select it also.
>> And as long as it doesn't cause a circular dependency problem.
>>
>> thanks.
> 
> Randy, all,
> I did the following for s390 and it "works", but I don't think we can use it.
> 
> Changed:
> 
> config ARCH_SUPPORTS_KEXEC_FILE
>      def_bool CRYPTO && CRYPTO_SHA256 && CRYPTO_SHA256_S390
> 
> to:
> 
> config ARCH_SELECTS_KEXEC_FILE
>          def_bool y
>          depends on KEXEC_FILE
>          select CRYPTO
>          select CRYPTO_SHA256
>          select CRYPTO_SHA256_S390
>          select SYSTEM_DATA_VERIFICATION
> 
> and this essentially passes my regression but for the following:
> 
> FAIL olddefconfig arch/s390/configs/defconfig
> LHSB {'CONFIG_CRYPTO_SHA256_S390': 'm'}
> RHSB {'CONFIG_CRYPTO_SHA256_S390': 'y'}
> 
> which simply means that the CRYPTO_SHA256_S390 is always built-in, whereas previously
> it could be a module. This happens because 'select' is always =y; overwrites if
> previously =m, as was the case with this particular config file.
> 
> I still don't know how to close this gap. Today I see linux-next has v5 in it.
> eric
> 
> 
Alright, I found the solution; somewhat obvious now that I see it.

The current s390/Kconfig for KEXEC_SIG looks like:

config KEXEC_SIG
     bool "Verify kernel signature during kexec_file_load() syscall"
     depends on KEXEC_FILE && MODULE_SIG_FORMAT
     help

and this caused issues with my original conversion. I now have the conversion as:

config ARCH_SUPPORTS_KEXEC_SIG
     def_bool MODULE_SIG_FORMAT

(where previously it was simply def_bool y). This works and passes all my regressions
as well as the reported fail here.

And it makes perfect sense, now.

I'll be posting v6 shortly.
Thanks,
eric

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ