Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 11 Jul 2023 13:49:42 -0500 | Subject | Re: linux-next: Tree for Jul 10 (arch/s390/kernel/machine_kexec_file.c) | From | Eric DeVolder <> |
| |
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
| ![\](/images/icornerr.gif) |