[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180105130849.GA1279@kroah.com>
Date: Fri, 5 Jan 2018 14:08:49 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Kees Cook <keescook@...omium.org>
Cc: Andy Lutomirski <luto@...capital.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Pavel Tatashin <pasha.tatashin@...cle.com>,
Thomas Voegtle <tv@...96.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Guenter Roeck <linux@...ck-us.net>,
Shuah Khan <shuahkh@....samsung.com>, patches@...nelci.org,
Ben Hutchings <ben.hutchings@...ethink.co.uk>,
lkft-triage@...ts.linaro.org, stable <stable@...r.kernel.org>
Subject: Re: [PATCH 4.4 00/37] 4.4.110-stable review
On Fri, Jan 05, 2018 at 02:12:33AM -0800, Kees Cook wrote:
> On Thu, Jan 4, 2018 at 9:33 PM, Andy Lutomirski <luto@...capital.net> wrote:
> > On Thu, Jan 4, 2018 at 12:43 PM, Andy Lutomirski <luto@...capital.net> wrote:
> >>
> >>> On Jan 4, 2018, at 12:29 PM, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> >>>
> >>>> On Thu, Jan 4, 2018 at 12:16 PM, Thomas Voegtle <tv@...96.de> 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
Powered by blists - more mailing lists