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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a3970db3-1ded-da2e-84a0-754810c15183@roeck-us.net>
Date:   Fri, 23 Sep 2022 21:38:04 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Dave Hansen <dave.hansen@...el.com>,
        "Kirill A. Shutemov" <kirill@...temov.name>,
        Dave Hansen <dave.hansen@...ux.intel.com>
Cc:     linux-kernel@...r.kernel.org, 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:12, Dave Hansen wrote:
> 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.

Yes, there are already way too many such useless warnings around.
Please don't add more of them.

Guenter