----- 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
