From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f71.google.com (mail-oi0-f71.google.com [209.85.218.71]) by kanga.kvack.org (Postfix) with ESMTP id 776656B0033 for ; Thu, 2 Nov 2017 07:59:31 -0400 (EDT) Received: by mail-oi0-f71.google.com with SMTP id v9so5792225oif.15 for ; Thu, 02 Nov 2017 04:59:31 -0700 (PDT) Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id y5sor1092676oia.36.2017.11.02.04.59.30 for (Google Transport Security); Thu, 02 Nov 2017 04:59:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: [PATCH 02/23] x86, kaiser: do not set _PAGE_USER for init_mm page tables From: Andy Lutomirski In-Reply-To: Date: Thu, 2 Nov 2017 12:59:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171031223146.6B47C861@viggo.jf.intel.com> <20171031223150.AB41C68F@viggo.jf.intel.com> Sender: owner-linux-mm@kvack.org List-ID: To: Thomas Gleixner Cc: Andy Lutomirski , Linus Torvalds , Dave Hansen , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , moritz.lipp@iaik.tugraz.at, Daniel Gruss , michael.schwarz@iaik.tugraz.at, Kees Cook , Hugh Dickins , X86 ML > On Nov 2, 2017, at 12:33 PM, Thomas Gleixner wrote: >=20 >> On Thu, 2 Nov 2017, Andy Lutomirski wrote: >>> On Wed, Nov 1, 2017 at 3:20 PM, Thomas Gleixner wro= te: >>>> On Wed, 1 Nov 2017, Linus Torvalds wrote: >>>>> On Wed, Nov 1, 2017 at 2:52 PM, Dave Hansen wrote: >>>>>> On 11/01/2017 02:28 PM, Thomas Gleixner wrote: >>>>>>> On Wed, 1 Nov 2017, Andy Lutomirski wrote: >>>>>>> The vsyscall page is _PAGE_USER and lives in init_mm via the fixmap.= >>>>>>=20 >>>>>> Groan, forgot about that abomination, but still there is no point in h= aving >>>>>> it marked PAGE_USER in the init_mm at all, kaiser or not. >>>>>=20 >>>>> So shouldn't this patch effectively make the vsyscall page unusable? >>>>> Any idea why that didn't show up in any of the x86 selftests? >>>>=20 >>>> I actually think there may be two issues here: >>>>=20 >>>> - vsyscall isn't even used much - if any - any more >>>=20 >>> Only legacy user space uses it. >>>=20 >>>> - the vsyscall emulation works fine without _PAGE_USER, since the >>>> whole point is that we take a fault on it and then emulate. >>>>=20 >>>> We do expose the vsyscall page read-only to user space in the >>>> emulation case, but I'm not convinced that's even required. >>>=20 >>> I don't see a reason why it needs to be mapped at all for emulation. >>=20 >> At least a couple years ago, the maintainers of some userspace tracing >> tools complained very loudly at the early versions of the patches. >> There are programs like pin (semi-open-source IIRC) that parse >> instructions, make an instrumented copy, and run it. This means that >> the vsyscall page needs to contain text that is semantically >> equivalent to what calling it actually does. >>=20 >> So yes, read access needs to work. I should add a selftest for this. >>=20 >> This is needed in emulation mode as well as native mode, so removing >> native mode is totally orthogonal. >=20 > Fair enough. I enabled function tracing with emulate_vsyscall as the filte= r > on a couple of machines and so far I have no hit at all. Though I found a > VM with a real old user space (~2005) and that actually used it. >=20 > So for the problem at hand, I'd suggest we disable the vsyscall stuff if > CONFIG_KAISER=3Dy and be done with it. I think that time() on not-so-old glibc uses it. Even more recent versions o= f Go use it. :( >=20 > Thanks, >=20 > tglx >=20 >=20 >=20 >=20 >=20 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org