Messages in this thread | | | From | Florian Weimer <> | Subject | Re: [PATCH] x86: Implement arch_prctl(ARCH_VSYSCALL_LOCKOUT) to disable vsyscall | Date | Thu, 16 Dec 2021 19:31:19 +0100 |
| |
* 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.
>> 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.
>> 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
| |