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] [day] [month] [year] [list]

Message-ID: <EEC4F4B9-69E0-460E-A598-9960ED52484C@zytor.com>
Date: Sat, 20 Dec 2025 00:47:33 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Uros Bizjak <ubizjak@...il.com>
CC: Nathan Chancellor <nathan@...nel.org>,
        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 December 19, 2025 11:50:57 PM PST, Uros Bizjak <ubizjak@...il.com> wrote:
>On Sat, Dec 20, 2025 at 1:48 AM H. Peter Anvin <hpa@...or.com> wrote:
>>
>> On 2025-12-19 16:24, Nathan Chancellor wrote:
>> > 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
>> >
>>
>> It looks to me that this is specifically related to static initializers, or is
>> there something else here that I'm not sure about?
>>
>> I'm asking because it might still allow at least the boot code improvements,
>> and/or have some other less painful workaround than carrying these hacks.
>>
>> As far as I can tell, on x86 gcc will not change the value of the pointer when
>> cast to a different address space and I believe Linux expects this behavior.
>
>This is because "... these address spaces are not considered to be
>subspaces of the generic (flat) address space. This means that
>explicit casts are required to convert pointers between these address
>spaces and the generic address space. In practice the application
>should cast to uintptr_t and apply the segment base offset that it
>installed previously." [1]
>
>[1] https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html
>
>Uros.
>

... which makes sense.