linux-kernel - Re: [PATCH v4 00/25] RSEQ node id and virtual cpu id extensions

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:   Mon, 10 Oct 2022 15:04:29 +0200
From:   Florian Weimer <fweimer@...hat.com>
To:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
        "Paul E . McKenney" <paulmck@...nel.org>,
        Boqun Feng <boqun.feng@...il.com>,
        "H . Peter Anvin" <hpa@...or.com>, Paul Turner <pjt@...gle.com>,
        linux-api@...r.kernel.org, Christian Brauner <brauner@...nel.org>,
        David.Laight@...LAB.COM, carlos@...hat.com,
        Peter Oskolkov <posk@...k.io>,
        Alexander Mikhalitsyn <alexander@...alicyn.com>
Subject: Re: [PATCH v4 00/25] RSEQ node id and virtual cpu id extensions

* Mathieu Desnoyers:

> Extend the rseq ABI to expose a NUMA node ID and a vm_vcpu_id field.
>
> The NUMA node ID field allows implementing a faster getcpu(2) in libc.
>
> The virtual cpu id allows ideal scaling (down or up) of user-space
> per-cpu data structures. The virtual cpu ids allocated within a memory
> space are tracked by the scheduler, which takes into account the number
> of concurrently running threads, thus implicitly considering the number
> of threads, the cpu affinity, the cpusets applying to those threads, and
> the number of logical cores on the system.

Do you have some code that shows how the userspace application handshake
is supposed to work with the existing three __rseq_* symbols?  Maybe I'm
missing something.

>From an application perspective, it would be best to add 8 more shared
bytes in use, to push the new feature size over 32.  This would be
clearly visible in __rseq_size, helping applications a lot.

Alternatively, we could sacrifice a bit to indicate that the this round
of extensions is present.  But we'll need another bit to indicate that
the last remaining 4 bytes are in use, for consistency.  Or come up with
something to put their today.  The TID seems like an obvious choice.

If we want to the 8 more bytes route, TID and PID should be
uncontroversal?  The PID cache is clearly something that userspace
likes, not just as a defeat device for the old BYTE benchmark.

Thanks,
Florian