linux-kernel - Re: [RFC PATCH 0/4] x86/percpu: Use segment qualifiers

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: <CAFULd4ZfAjobU45POv0uSB73urVFa0kFX_35RNyHy3rf_kbFjg@mail.gmail.com>
Date: Tue, 29 Apr 2025 19:05:33 +0200
From: Uros Bizjak <ubizjak@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>, 
	Andy Lutomirski <luto@...nel.org>, Ingo Molnar <mingo@...nel.org>, Nadav Amit <nadav.amit@...il.com>, 
	Brian Gerst <brgerst@...il.com>, Denys Vlasenko <dvlasenk@...hat.com>, 
	"H . Peter Anvin" <hpa@...or.com>, Peter Zijlstra <peterz@...radead.org>, 
	Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>, Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [RFC PATCH 0/4] x86/percpu: Use segment qualifiers

On Tue, Apr 29, 2025 at 6:50 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Tue, 29 Apr 2025 at 09:31, Uros Bizjak <ubizjak@...il.com> wrote:
> >
> > FYI, after GCC PR 111657 [1] was fixed, gcc-16 will generate the following code:
>
> Well, that's certainly a lot better than the horrible byte-at-a-time loop.
>
> Did you verify doing a structure copy the other way?
>
> Because the segment override on 'rep movs' only works one way - it
> only affects the source, not the destination.
>
> So while
>
>       #include <string.h>
>       struct a { long arr[30]; };
>
>       __seg_fs struct a m;
>       void foo(struct a *dst) { *dst = m; }
>
> works with 'rep movs', changing it do do
>
>       __seg_fs struct a m;
>       void foo(struct a *src) { m = *src; }
>
> can only work with a loop of explicit stores.

True, the generated code due to mentioned HW limitation is then:

foo:
       xorl    %eax, %eax
.L2:
       movl    %eax, %edx
       addl    $8, %eax
       movq    (%rdi,%rdx), %rcx
       movq    %rcx, %fs:m(%rdx)
       cmpl    $240, %eax
       jb      .L2
       ret

which has some room for improvement, please see PR12000 [2].

[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120000

> And I see in the gcc bugzilla that some gcc developer was confused,
> and thought this was about calling "memcpy()" (which should complain
> about address spaces rather than generate code).
>
> But structure assignment is a different thing.

Yes, GCC won't even consider calling memcpy() for structure
assignments when any of the structures is in the non-default address
space.

Uros.