linux-kernel - Re: Do we still care about compilers without __seg_fs and __seg

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: <20251220002424.GA3998744@ax162>
Date: Fri, 19 Dec 2025 17:24:24 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Uros Bizjak <ubizjak@...il.com>,
	Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
	Bill Wendling <morbo@...gle.com>,
	Justin Stitt <justinstitt@...gle.com>,
	"x86@...nel.org" <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Do we still care about compilers without __seg_fs and __seg_gs
 support??

On Fri, Dec 19, 2025 at 03:24:21PM -0800, H. Peter Anvin wrote:
> As of Linux 6.16, we require:
> 
> 	gcc 8.1 or higher
> 	clang 15.0.0 or higher
> 
> If my reading of the release notes is correct, then both versions *should*
> supported __seg_fs and __seg_gs, but we have:
> 
> config CC_HAS_NAMED_AS
>         def_bool $(success,echo 'int __seg_fs fs; int __seg_gs gs;' | $(CC) -x
> c - -S -o /dev/null)
>         depends on CC_IS_GCC
> 
> We don't even try on clang.
> 
> Being able to actually rely on the compiler for this would make a lot of
> things cleaner.  For one thing, I'm trying to untangle a bunch of ugliness in
> the code sharing between realmode and proper flat mode code...
> 
> Uros, you seem to have touched this code as recently as earlier this year; any
> thoughts?
> 
> What about the LLVM people, any insights?

Trying to use __seg_fs or __seg_gs in certain cases crashes the X86
backend.

  https://github.com/llvm/llvm-project/issues/93449

Is there anyone on AMD or Intel's LLVM teams that could look into
solving that? Nick pinged a couple of Intel's folks but it does not look

Cheers,
Nathan