linux-kernel - rseq vcpu

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

Message-ID: <1211272108.4257.1643246572499.JavaMail.zimbra@efficios.com>
Date:   Wed, 26 Jan 2022 20:22:52 -0500 (EST)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     Paul Turner <pjt@...gle.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Michael Jeanson <mjeanson@...icios.com>,
        paulmck <paulmck@...nel.org>, Boqun Feng <boqun.feng@...il.com>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: rseq vcpu_id ideas

Hi Paul,

I remember our LPC discussions about your virtual cpu ids ideas, and noticed some tcmalloc code
with "prototype" fields for vcpu_id and numa node id
(https://github.com/google/tcmalloc/blob/master/tcmalloc/internal/linux_syscall_support.h#L34).

I'm currently toying with ideas very close to vcpu_ids to solve issues with overzealous
memory allocation for LTTng-UST (user-space tracer) in use-cases where containers use few
cores.

My current thinking is that we could use your vcpu_id idea, but apply it on a per-pid-namespace
basis rather than per-process. We may have to be clever with NUMA as well to ensure good NUMA
locality.

Do you have any thought about this, and perhaps some prototype rseq extension code you could
share as a starting point ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com