* Andy Lutomirski:
This could possibly be much more generic: have a mask of legacy
features to disable and a separate mask of lock bits.
Is that really necessary? Adding additional ARCH_* constants does not
seem to be particularly onerous and helps with detection of kernel
support.
quoted
I can turn this into a toggle, and we could probably default our builds
to vsyscalls=xonly. Given the userspace ABI impact, we'd still have to
upstream the toggle. Do you see a chance of a patch a long these lines
going in at all, given that it's an incomplete solution for
vsyscall=emulate?
There is basically no reason for anyone to use vsyscall=emulate any
more. I'm aware of exactly one use case, and it's quite bizarre and
involves instrumenting an outdated binary with an outdated
instrumentation tool. If either one is recent (last few years),
vsyscall=xonly is fine.
Yeah, we plan to stick to vsyscall=xonly. This means that the toggle is
easier to implement, of course.
quoted
Hmm. But only for vsyscall=xonly, right? With vsyscall=emulate,
reading at those addresses will still succeed.
IMO if vsyscall is disabled for a process, reads and executes should
both fail. This is trivial in xonly mode.
Right, I'll document this as a glitch for now.
I've got a v2 (with the toggle rather than pure lockout) and will sent
it out shortly.
Thanks,
Florian