[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87mtayvz39.fsf@mid.deneb.enyo.de>
Date: Sat, 17 Sep 2022 16:45:46 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Chris Kennelly <ckennelly@...gle.com>, libc-coord@...ts.openwall.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
* Mathieu Desnoyers:
> On 2022-09-16 23:32, Florian Weimer wrote:
>> * 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.
>
> I don't think this is what Chris is asking here.
>
> I think the requirement here is to make sure that the extensibility
> scheme we come up with will allow to extend struct rseq simply by
> upgrading the kernel, without any need to upgrade glibc. (that's indeed
> a requirement of mine). So a new application and a new kernel can use a
> newly available extended field, even with an old glibc.
I took it for granted that we'd like to get libc out of the picture
for future changes, so I interpreted Chris' question in the context of
the initial switch (i.e., enabling rseq features that need
extensibility on currently released glibc, without upgrading glibc).
> If we want to keep the kernel ABI as simple as we can, then we just
> expose the rseq feature size (and required alignment), and don't expose
> any rseq feature flags. This in turn means that glibc would have to
> somehow expose the rseq feature size in its ABI. If glibc decides
> against exposing this rseq feature size symbol, then it would be up to
> the application to combine information about __rseq_size and
> getauxval(rseq feature size) to figure out which fields are actually
> populated. It would "work", but chances are that some users will get it
> wrong. It seems simpler for a user to simply do:
>
> if (__rseq_feature_size >= offsetofend(struct rseq, vm_vcpu_id))
>
> to validate whether a given field is indeed populated.
>
> The rseq feature size approach would scale to very large feature
> numbers. It would *not* allow deprecation of fields after they are
> published, but I see this as a gain in simplicity for users of the ABI,
> even though we lose a knob as kernel developers.
I think glibc can register rseq with a new flag once it sees
AT_RSEQ_FEATURE_SIZE in the auxiliary vector (even if it's 32). That
flag would naturally end up in __rseq_flags. For future extensions
__rseq_size should work directly.
But as I said, we better use all the padding at once during the first
step. Or we could add even more stuff to move past the current 32,
then we wouldn't need the flag dance. 8-)
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.
