Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935619AbeAKTGN (ORCPT + 1 other); Thu, 11 Jan 2018 14:06:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44270 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933141AbeAKTGM (ORCPT ); Thu, 11 Jan 2018 14:06:12 -0500 Date: Thu, 11 Jan 2018 13:05:51 -0600 From: Josh Poimboeuf To: Dave Hansen Cc: Linus Torvalds , Alexei Starovoitov , Andy Lutomirski , Willy Tarreau , Peter Zijlstra , LKML , X86 ML , Borislav Petkov , Brian Gerst , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Greg Kroah-Hartman , Kees Cook , aarcange@redhat.com Subject: Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set Message-ID: <20180111190551.kefaiyemiljuolyd@treble> References: <20180111064259.GC14920@1wt.eu> <0f08d89e-61e1-20e3-5c59-0b2f7b32bf0c@linux.intel.com> <20180111154412.GA15296@1wt.eu> <20180111182147.masunghp5km6igjq@ast-mbp.dhcp.thefacebook.com> <20180111183207.dah7imbuvuhvrrk6@treble> <4e32af93-f632-ae17-eed4-c7023c1b9cc5@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4e32af93-f632-ae17-eed4-c7023c1b9cc5@linux.intel.com> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 11 Jan 2018 19:06:12 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Thu, Jan 11, 2018 at 10:57:51AM -0800, Dave Hansen wrote: > On 01/11/2018 10:51 AM, Linus Torvalds wrote: > > On Thu, Jan 11, 2018 at 10:38 AM, Dave Hansen > > wrote: > >> On 01/11/2018 10:32 AM, Josh Poimboeuf wrote: > >>>> hmm. Exposing cr3 to user space will make it trivial for user process > >>>> to know whether kpti is active. Not sure how exploitable such > >>>> information leak. > >>> It's already trivial to detect PTI from user space. > >> Do tell. > > One way to do it is to just run the attack, and see if you get something. > > Not judging how trivial (or not) the attack is, I was hoping for > something that was *not* the attack itself. :) > > I'd love to have a tool that tells you for sure "KPTI enabled or not", > but I'd also love to have it be something I can easily distribute > without it being handled like a WMD. Instead of the meltdown attack, why not just run the KASLR attack, with prefetches + cache timing? Something like this (I haven't tested it though): https://github.com/IAIK/prefetch/blob/master/addrspace/addrspace.c Andrea also created such a tool, but IIRC, it requires knowing a kernel address, so it wouldn't work with KASLR. It could probably be extended to scan kernel space until it finds something. We could maybe even add such a tool to the kernel tree. -- Josh