linux-kernel - Re: [PATCH v2 12/13] s390/kexec: refactor for kernel/Kconfig.kexec

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]

Message-ID: <b6ea0dc3-313f-6aae-f3cb-26bb61daf1fa@oracle.com>
Date:   Thu, 22 Jun 2023 12:51:41 -0500
From:   Eric DeVolder <eric.devolder@...cle.com>
To:     Alexander Gordeev <agordeev@...ux.ibm.com>
Cc:     Mimi Zohar <zohar@...ux.ibm.com>, linux@...linux.org.uk,
        catalin.marinas@....com, will@...nel.org, chenhuacai@...nel.org,
        geert@...ux-m68k.org, tsbogend@...ha.franken.de,
        James.Bottomley@...senpartnership.com, deller@....de,
        ysato@...rs.sourceforge.jp, dalias@...c.org,
        glaubitz@...sik.fu-berlin.de, tglx@...utronix.de, mingo@...hat.com,
        bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-ia64@...r.kernel.org, loongarch@...ts.linux.dev,
        linux-m68k@...ts.linux-m68k.org, linux-mips@...r.kernel.org,
        linux-parisc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        linux-riscv@...ts.infradead.org, linux-s390@...r.kernel.org,
        linux-sh@...r.kernel.org, kernel@...0n.name, mpe@...erman.id.au,
        npiggin@...il.com, christophe.leroy@...roup.eu,
        paul.walmsley@...ive.com, palmer@...belt.com,
        aou@...s.berkeley.edu, hca@...ux.ibm.com, gor@...ux.ibm.com,
        borntraeger@...ux.ibm.com, svens@...ux.ibm.com, hpa@...or.com,
        keescook@...omium.org, paulmck@...nel.org, peterz@...radead.org,
        frederic@...nel.org, akpm@...ux-foundation.org, ardb@...nel.org,
        samitolvanen@...gle.com, juerg.haefliger@...onical.com,
        arnd@...db.de, rmk+kernel@...linux.org.uk,
        linus.walleij@...aro.org, sebastian.reichel@...labora.com,
        rppt@...nel.org, kirill.shutemov@...ux.intel.com,
        anshuman.khandual@....com, ziy@...dia.com, masahiroy@...nel.org,
        ndesaulniers@...gle.com, mhiramat@...nel.org, ojeda@...nel.org,
        thunder.leizhen@...wei.com, xin3.li@...el.com, tj@...nel.org,
        gregkh@...uxfoundation.org, tsi@...oix.net, bhe@...hat.com,
        hbathini@...ux.ibm.com, sourabhjain@...ux.ibm.com,
        boris.ostrovsky@...cle.com, konrad.wilk@...cle.com
Subject: Re: [PATCH v2 12/13] s390/kexec: refactor for kernel/Kconfig.kexec



On 6/22/23 11:24, Alexander Gordeev wrote:
> On Wed, Jun 21, 2023 at 12:10:49PM -0500, Eric DeVolder wrote:
> Hi Eric,
> ...
>>>> NOTE: The original Kconfig has a KEXEC_SIG which depends on
>>>> MODULE_SIG_FORMAT. However, attempts to keep the MODULE_SIG_FORMAT
>>>> dependency (using the strategy outlined in this series, and other
>>>> techniques) results in 'error: recursive dependency detected'
>>>> on CRYPTO. This occurs due to any path through KEXEC_SIG
>>>> attempting to select CRYPTO is ultimately dependent upon CRYPTO:
>>>>
>>>>    CRYPTO
>>>>     <- ARCH_SUPPORTS_KEXEC_FILE
>>>>        <- KEXEC_FILE
>>>>           <- KEXEC_SIG
>>>>
>>>> Therefore, the solution is to drop the MODULE_SIG_FORMAT dependency
>>>> for KEXEC_SIG. In practice, however, MODULE_SIG_FORMAT is still
>>>> configured-in as the use of KEXEC_SIG is in step with the use of
>>>> SYSTEM_DATA_VERIFICATION, which does select MODULE_SIG_FORMAT.
>>>
>>> No, it is actually the other way around.
>>> Could you please provide the correct explanation?
>>>
>>> AFAICT the MODULE_SIG_FORMAT dependency was introduced with commit
>>> c8424e776b09 ("MODSIGN: Export module signature definitions") and
>>> in fact was not necessary, since s390 did/does not use mod_check_sig()
>>> anyway. So the SYSTEM_DATA_VERIFICATION could have left intact.
>>
>> Thomas, would the correct explanation be simply indicating that
>> MODULE_SIG_FORMAT isn't needed as it is not used by s390 (crediting your
>> summary above)?
> 
> I guess, you asked me? Anyway, I will try to answer as if I were Thomas :)
> 
> MODULE_SIG_FORMAT is needed to select SYSTEM_DATA_VERIFICATION.
> But SYSTEM_DATA_VERIFICATION is also selected by FS_VERITY*, so
> dropping MODULE_SIG_FORMAT does not hurt.
> 
> Thanks!

For the commit message for this s390/Kconfig change, are you ok
with the following?
eric

=====
The kexec and crash kernel options are provided in the common
kernel/Kconfig.kexec. Utilize the common options and provide
the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the
equivalent set of KEXEC and CRASH options.

NOTE: The original Kconfig has a KEXEC_SIG which depends on
MODULE_SIG_FORMAT. However, attempts to keep the MODULE_SIG_FORMAT
dependency (using the strategy outlined in this series, and other
techniques) results in 'error: recursive dependency detected'
on CRYPTO.

Per Alexander Gordeev <agordeev@...ux.ibm.com>: "the MODULE_SIG_FORMAT
dependency was introduced with c8424e776b09 ("MODSIGN: Export module
signature definitions") and in fact was not necessary, since s390
did/does not use mod_check_sig() anyway. MODULE_SIG_FORMAT is needed
to select SYSTEM_DATA_VERIFICATION. But SYSTEM_DATA_VERIFICATION is
also selected by FS_VERITY*, so dropping MODULE_SIG_FORMAT does not
hurt."

Therefore, the solution is to drop the MODULE_SIG_FORMAT dependency
from KEXEC_SIG.