On 5/30/23 10:25, Mathieu Desnoyers wrote:
On 5/30/23 04:20, Florian Weimer wrote:
[...]
The challenge is that once we put stuff at fixed offsets, we can't
transparently fix it later. It would need more auxv entries with
further offsets, or accessing this data through some indirection,
perhaps via vDSO helpers.
Perhaps this is more flexibility/complexity than we really need. One
possible approach would be to split struct rseq into sub-structures, e.g.:
rseq_len = overall size of all sub-structures.
auxv AT_RSEQ_ALIGN = 256
auxv AT_RSEQ_FEATURE_SIZE = size of first portion of struct rseq,
at most 256 bytes, meant to contain fields
stored/loaded from the thread doing the
registration.
auxv AT_RSEQ_SHARED_FEATURE_SIZE =
size of 2nd portion of struct rseq,
starts at offset 256, at most 256 bytes,
meant to contain fields stored/loaded by
any thread.
Then we have this layout:
struct rseq {
struct rseq_local {
/* Fields accessed from local thread. */
} __attribute__((aligned((256));
struct rseq_shared {
/* Shared fields. */
} __attribute__((aligned(256));
} __attribute__((aligned(256));
And if someday AT_RSEQ_FEATURE_SIZE needs to grow over 256 bytes
(32 * u64), we can still extend with a new auxv entry after the "shared"
features.
Actually, after giving it some more thoughts, I think we can do better:
- Add a sys_rseq() rseq_flag RSEQ_FLAG_SHARED, which changes the
behavior of sys_rseq() to expect an additional "struct rseq_shared *"
argument.
- Introduce auxv AT_RSEQ_SHARED_FEATURE_SIZE.
This way, it's up to the libc to decide how to allocate its private vs
shared rseq structures.
The auxv "AT_RSEQ_ALIGN" would dictate the minimal alignment required
for both private and shared rseq structures.
I don't think we need to express the size of the rseq_shared memory area
allocated by libc because we know that it needs to be large enough to
handle the shared feature size.
Thoughts ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
