* 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
