* Dave Martin:
Fair points, though this is rather what I meant by "sane essentials".
Because there are strict limits on what can be done in the vDSO, it may
be more bloat-resistant and more conservatively maintained.
This might provide a way to push some dumb compatibility kludge code
that receives little ongoing maintenance outside the privilege wall,
whereas it has to sit in the kernel proper today.
In theory we could opt to advertise new syscalls only via vDSO entry
points, and not maintain __NR_xxx values for them (which may or may
not upset ptrace users.) Anyway, I digress...
Is the vDSO available across all architectures? (I don't think we use
it on all architectures in glibc.)
If not, a vDSO-based approach would merely lead to even more variance
between architectures, which can't be a good thing.
Thanks,
Florian
On Wed, Nov 14, 2018 at 12:40:44PM +0100, Florian Weimer wrote:
* Dave Martin:
quoted
Fair points, though this is rather what I meant by "sane essentials".
Because there are strict limits on what can be done in the vDSO, it may
be more bloat-resistant and more conservatively maintained.
This might provide a way to push some dumb compatibility kludge code
that receives little ongoing maintenance outside the privilege wall,
whereas it has to sit in the kernel proper today.
In theory we could opt to advertise new syscalls only via vDSO entry
points, and not maintain __NR_xxx values for them (which may or may
not upset ptrace users.) Anyway, I digress...
Is the vDSO available across all architectures? (I don't think we use
it on all architectures in glibc.)
It's probably not available on all arches.
If not, a vDSO-based approach would merely lead to even more variance
between architectures, which can't be a good thing.
That's a fair concern.
Channeling syscalls through the vDSO could allow for a uniform syscall
interface at the ELF linkage level, but only those arches that have a
vDSO. There may be other issues too.
Also, I don't say that we should definitely do this, just that it's
a possibility.
Cheers
---Dave