Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87fsgryphl.fsf@mid.deneb.enyo.de>
Date: Fri, 16 Sep 2022 23:32:38 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: Chris Kennelly <ckennelly@...gle.com>
Cc: libc-coord@...ts.openwall.com,  Mathieu Desnoyers
 <mathieu.desnoyers@...icios.com>,  "carlos@...hat.com"
 <carlos@...hat.com>,  libc-alpha <libc-alpha@...rceware.org>,
  szabolcs.nagy@....com
Subject: Re: Re: RSEQ symbols: __rseq_size, __rseq_flags vs
 __rseq_feature_size

* Chris Kennelly:

>> If the kernel does not currently overwrite the padding, glibc can do
>> its own per-thread initialization there to support its malloc
>> implementation (because the padding is undefined today from an
>> application perspective).  That is, we would initialize these
>> invisible vCPU IDs the same way we assign arenas today.  That would
>> cover this specific malloc use case only, of course.

> If a user program updates to a new kernel before glibc does, would it be
> able to easily take advantage of it?

No, as far as I understand it, there is presently no signaling from
kernel to applications that bypasses the rseq area registration.  So
the only thing you could do is to unregister and re-register with a
compatible value.  And that is of course quite undefined and assumes
that you can do this early enough during the life-time of each thread.

But if we have the extension handshake, I'll expect us to backport it
quite widely, after some time to verify that it works with CRIU etc.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.