Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <ca72bdfb-9868-162f-63d5-f778dd03db22@intel.com>
Date:   Fri, 23 Sep 2022 17:12:32 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH] x86/mm: Disable W^X detection and enforcement on 32-bit
Content-Language: en-US
To:     "Kirill A. Shutemov" <kirill@shutemov.name>,
        Dave Hansen <dave.hansen@linux.intel.com>
Cc:     linux-kernel@vger.kernel.org, Guenter Roeck <linux@roeck-us.net>,
        Ard Biesheuvel <ardb@kernel.org>,
        Darren Hart <dvhart@infradead.org>,
        Andy Shevchenko <andy@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        x86@kernel.org, linux-efi@vger.kernel.org,
        "H. Peter Anvin" <hpa@zytor.com>, Kees Cook <keescook@chromium.org>
References: <20220923221730.1860518-1-dave.hansen@linux.intel.com>
 <20220924000954.hhaghgkrb6h33nvq@box.shutemov.name>
From:   Dave Hansen <dave.hansen@intel.com>
In-Reply-To: <20220924000954.hhaghgkrb6h33nvq@box.shutemov.name>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.