linux-kernel - Re: [PATCH] x86/mm: Disable W^X detection and enforcement on 32-bit

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: <ca72bdfb-9868-162f-63d5-f778dd03db22@intel.com>
Date:   Fri, 23 Sep 2022 17:12:32 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     "Kirill A. Shutemov" <kirill@...temov.name>,
        Dave Hansen <dave.hansen@...ux.intel.com>
Cc:     linux-kernel@...r.kernel.org, Guenter Roeck <linux@...ck-us.net>,
        Ard Biesheuvel <ardb@...nel.org>,
        Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        x86@...nel.org, linux-efi@...r.kernel.org,
        "H. Peter Anvin" <hpa@...or.com>, Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH] x86/mm: Disable W^X detection and enforcement on 32-bit

On 9/23/22 17:09, Kirill A. Shutemov wrote:
> On Fri, Sep 23, 2022 at 03:17:30PM -0700, Dave Hansen wrote:
>> The 32-bit code is in a weird spot.  Some 32-bit builds (non-PAE) do not
>> even have NX support.  Even PAE builds that support NX have to contend
>> with things like EFI data and code mixed in the same pages where W+X
>> is unavoidable.
>>
>> The folks still running X86_32=y kernels are unlikely to care much about
>> NX.  That combined with the fundamental inability fix _all_ of the W+X
>> things means this code had little value on X86_32=y.  Disable the checks.
> Maybe downgrade the check to a warning for X86_32=y?

But for this EFI case, we really don't want the warning.  It's unfixable.

I'm also not sure we want to go to the trouble to properly silence the
warning in these unfixable cases.  There was an argument elsewhere in
the thread that we really shouldn't be warning on things that we don't
have full intentions to fix.  I buy that argument.