Re: [PATCH v3 02/23] rseq: Introduce extensible rseq ABI

[Mathieu Desnoyers]

----- On Aug 10, 2022, at 2:33 AM, Florian Weimer fweimer@xxxxxxxxxx wrote:

> * Mathieu Desnoyers:
> 
>> Introduce the extensible rseq ABI, where the feature size supported by
>> the kernel and the required alignment are communicated to user-space
>> through ELF auxiliary vectors.
>>
>> This allows user-space to call rseq registration with a rseq_len of
>> either 32 bytes for the original struct rseq size (which includes
>> padding), or larger.
>>
>> If rseq_len is larger than 32 bytes, then it must be large enough to
>> contain the feature size communicated to user-space through ELF
>> auxiliary vectors.
> 
> I don't think this works with the glibc extension mechanism because
> __rseq_size does not change until the padding is exhausted.

In order to deal with this existing discrepancy between feature-set vs
size, the proposed extension scheme would require that glibc expose a new
__rseq_feature_size, which would give us:

/*
 * Size of the registered rseq area. 0 if the registration was
 * unsuccessful.
 */
unsigned int __rseq_size = -1U;

/* Flags used during rseq registration.  */
unsigned int __rseq_flags;

/*
 * rseq feature size supported by the kernel. 0 if the registration was
 * unsuccessful.
 */
unsigned int __rseq_feature_size = -1U;

> I think you'll need to add the suggested flags to the auxiliary vector,
> and then we can use that during registration and also communicate these
> flags via __rseq_flags.

For the struct rseq extension, with the "__rseq_feature_size" symbol
I don't think we need to suggest rseq registration flags through
auxiliary vectors.

However, the kernel could provide the set of "supported flags" which
can be passed as rseq flags argument through auxiliary vectors. Is
that what you have in mind ?

This can be useful to ensure we don't require userspace to rely on
rseq returning -1, errno=-EINVAL to detect supported feature flags.

> 
> Size and alignment can be stored in a single auxiliary vector entry.

getauxval returns a single "unsigned long". I'm not sure how to extract
size and alignment other than using bitwise operations. Is that what you
have in mind ? Are there other auxval entries that use this kind of
bitwise scheme ?

And by "size", do you mean "supported feature size" or "allocation size" ?
Because the allocation size will be typically aligned to the next power of
two, but not the "supported feature size". AFAIU though, the kernel only
needs to express the supported feature size and the allocation alignment
through auxv. The rest can be figured out from userspace.

Thanks,

Mathieu

> 
> Thanks,
> Florian

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