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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZJR1o0lzhIUdpTb+@li-008a6a4c-3549-11b2-a85c-c5cc2836eea2.ibm.com>
Date:   Thu, 22 Jun 2023 18:24:03 +0200
From:   Alexander Gordeev <agordeev@...ux.ibm.com>
To:     Eric DeVolder <eric.devolder@...cle.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 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!