Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751803AbeAENIr (ORCPT + 1 other); Fri, 5 Jan 2018 08:08:47 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:54752 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751628AbeAENIp (ORCPT ); Fri, 5 Jan 2018 08:08:45 -0500 Date: Fri, 5 Jan 2018 14:08:49 +0100 From: Greg Kroah-Hartman To: Kees Cook Cc: Andy Lutomirski , Linus Torvalds , Pavel Tatashin , Thomas Voegtle , Linux Kernel Mailing List , Andrew Morton , Guenter Roeck , Shuah Khan , patches@kernelci.org, Ben Hutchings , lkft-triage@lists.linaro.org, stable Subject: Re: [PATCH 4.4 00/37] 4.4.110-stable review Message-ID: <20180105130849.GA1279@kroah.com> References: <20180103195056.837404126@linuxfoundation.org> <20180104195055.GA29809@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Fri, Jan 05, 2018 at 02:12:33AM -0800, Kees Cook wrote: > On Thu, Jan 4, 2018 at 9:33 PM, Andy Lutomirski wrote: > > On Thu, Jan 4, 2018 at 12:43 PM, Andy Lutomirski wrote: > >> > >>> On Jan 4, 2018, at 12:29 PM, Linus Torvalds wrote: > >>> > >>>> On Thu, Jan 4, 2018 at 12:16 PM, Thomas Voegtle wrote: > >>>> > >>>> Attached a screenshot. > >>>> Is that useful? Are there some debug options I can add? > >>> > >>> Not much of an oops, because the SIGSEGV happens in user space. The > >>> only reason you get any kernel stack printout at all is because 'init' > >>> dying will make the kernel print that out. > >>> > >>> The segfault address for init looks like the fixmap area to me (first > >>> byte in the last page of the fixmap?). "Error 5" means that it's a > >>> user-space read that got a protection fault. So it's not a LDT of GDT > >>> update or anything like that, it's a normal access from user space (or > >>> a qemu emulation bug, but that sounds unlikely). > >>> > >>> Is that the vsyscall page? > >>> > >>> Adding Luto to the participants. I think he noticed one of the > >>> vsyscall patches missing earlier in the 4.9 series. Maybe the 4.4 > >>> series had something similar.. > >>> > >> > >> That's almost certainly it. > >> > >> I'll try to find some time today or tomorrow to add a proper selftest. > >> > > > > Give this a shot: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/pti&id=17c5ebeb2e00879b0af1a9c32bf37ecdd9b9b31b > > > > Boot with each of vsyscall=none, vsyscall=native, and vsyscall=emulate > > and run both the 32-bit and 64-bit variants of that test. All six > > combinations should pass. But I bet they don't on 4.4. > > With my 4.4.110-rc1 under QEMU -cpu=host (Xeon E5-2690 v3) > > vsyscall=emulate: > > # ./test_vsyscall_64 > ... > [RUN] Checking read access to the vsyscall page > [FAIL] We don't have read access, but we should > > vsyscall=native: > > # ./test_vsyscall_64 > ... > [RUN] Checking read access to the vsyscall page > [FAIL] We don't have read access, but we should > > Everything else passes. I get this same error with the latest 4.9-rc tree as well, but it works just fine on 4.15-rc6. I'll look at the proposed patches now for this... thanks so much for the test tool. greg k-h