linux-kernel - Re: [PATCH 1/1] x86/mm/pae: Align up pteval_t, pmdval_t and pudval

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]

Date: Tue, 2 Apr 2024 19:23:14 +0200
From: Javier Pello <devel@...eo.eu>
To: Dave Hansen <dave.hansen@...el.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, Thomas Gleixner
 <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov
 <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin"
 <hpa@...or.com>
Subject: Re: [PATCH 1/1] x86/mm/pae: Align up pteval_t, pmdval_t and
 pudval_t to avoid split locks

On Mon, 1 Apr 2024 10:56:14 -0700 Dave Hansen wrote:

> First of all, how is it that you're running a PAE kernel on new,
> 64-bit hardware?  That's rather odd.

I got this motherboard and cpu fairly recently to replace old
hardware, and I just plugged my old hard disk and went along with
it, because I did not feel like bootstrapping a 64-bit system.

> The case that you're hitting is actually an on-stack pmd_t.  The
> fun part is that it's not shared and doesn't even _need_ atomics.
> I think it's just using pmd_populate() because it's convenient.

I see. So just annotating the variable on the stack with
__aligned(8) should do it? But the code is under mm/, so it should
be arch-agnostic, right? What would the correct fix be, then? I take
from your message that using atomics through pmd_populate() here is
not needed, but what accessors should be used instead? I am not
familiar at all with this part of the kernel.

> I'd honestly much rather just disable split lock support in 32-bit
> builds than mess with this stuff.  You really shouldn't be running
> 32-but kernels on this hardware.

Why? Is it unsupported? The hardware runs fine, it is just a choice
made by the kernel to crash a task if a split lock is detected in
kernel mode, but I do not see any technical reason not to fix the
split lock. Disabling split lock detection would not make the split
locks go away, they would just go unnoticed instead.

Regards,
Javier