DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 877502191E
MIME-Version: 1.0
In-Reply-To: <20180105134025.kzmnydmzrnfdokz7@pd.tnic>
References: <17c5ebeb2e00879b0af1a9c32bf37ecdd9b9b31b.1515130397.git.luto@kernel.org>
 <20180105134025.kzmnydmzrnfdokz7@pd.tnic>
From: Andy Lutomirski <luto@kernel.org>
Date: Fri, 5 Jan 2018 10:01:23 -0800
Message-ID: <CALCETrVp3AaiXcZrxKCw0ABdn5_HjO8Ud0BcapGxABRyB=sFdA@mail.gmail.com>
Subject: Re: [RFC] selftests/x86: Add test_vsyscall
To: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@kernel.org>, X86 ML <x86@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Kees Cook <keescook@chromium.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org

On Fri, Jan 5, 2018 at 5:40 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Thu, Jan 04, 2018 at 09:38:37PM -0800, Andy Lutomirski wrote:
>> It's RFC because I want to re-read it myself first.  It's also missing
>> a test that will reliably make sure that vsyscall=none prevents use of
>> vsyscalls.
>
> With my patch ontop of 4.4 from yesterday:
>
> # ./test_vsyscall_32
> Warning: failed to find getcpu in vDSO

I should suppress that warning on 32-bit.  Apparently no one ever
wired up 32-bit getcpu.

> [RUN]   Checking read access to the vsyscall page
> [FAIL]  We don't have read access, but we should
>
> Do I really need the read access? :-)

Yes.  There are very clever tools like 'pin' that instrument a binary
by decoding all the instructions it executes and generating an
instrumented copy.  If that binary calls into the vDSO, the vDSO gets
decoded and instrumented (which works fine).  If the binary calls into
the vsyscall page, it still needs to work.  So the vsyscall page
contains machine code that actually works (even if it's NX) to support
these tools.  The authors and users of the tools yelled loudly in an
earlier version of the vsyscall emulation code that didn't support
this use case.

The root cause here is that 4.4 is KAISER, not KPTI.  The
kaiser_set_shadow_pgd() function is a steaming pile of shit, and this
is a known bug in it.  I have zero desire to hack up some stupid
special case in there.  For the modern KPTI kernels, I rewrote that
function entirely to be much simpler and much more correct.

It should be straightforward to kludge something up, though, but I'm
not volunteering.