From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: Pondering per-process vsyscall disablement Date: Wed, 28 May 2014 14:45:18 -0700 Message-ID: <538658EE.8030809@zytor.com> References: <537EB60E.40204@1h.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Andy Lutomirski , Marian Marinov Cc: "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , X86 ML , Linux API List-Id: linux-api@vger.kernel.org On 05/23/2014 09:40 AM, Andy Lutomirski wrote: > > I don't think this should be something configured by the > administrator, unless the administrator is the builder of a kiosky > thing like Chromium OS. In that case, the administrator can use > vsyscall=none. > > I think this should be handled by either libc or the toolchain, hence > the suggestions of a syscall or an ELF header. > We could mimic the NX stack stuff, but it would have a lot of false negatives, simply because very few things would actually poke at the vsyscall page. The NX stuff uses a dummy program header in the ELF image. On the other hand, you could make the argument that anything compiled with a new toolchain simply should not use the vsyscall page, and just unconditionally set the opt-out bit (header) in question. It might be better to have some kind of flags field (which a number of architectures use) than keep using dummy program headers, though. -hpa