linux-kernel - Re: [PATCH 4/4] x86: use pte_none() to test for empty PTE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5787A0A2.4070406@intel.com>
Date:	Thu, 14 Jul 2016 07:24:34 -0700
From:	Dave Hansen <dave.hansen@...el.com>
To:	Vlastimil Babka <vbabka@...e.cz>, Dave Hansen <dave@...1.net>,
	linux-kernel@...r.kernel.org
Cc:	x86@...nel.org, linux-mm@...ck.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, bp@...en8.de, ak@...ux.intel.com,
	mhocko@...e.com, dave.hansen@...ux.intel.com,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	David Vrabel <david.vrabel@...rix.com>,
	Juergen Gross <jgross@...e.com>
Subject: Re: [PATCH 4/4] x86: use pte_none() to test for empty PTE

On 07/14/2016 06:47 AM, Vlastimil Babka wrote:
> So, this might be just because I know next to nothing about (para)virt,
> but...
> 
> in arch/x86/include/asm/paravirt.h, pte_val is implemented via some
> pvops, which suggests that obtaining a pte value is different than just
> reading it from memory. But I don't see pte_none() defined to be using
> this on paravirt, and it shares (before patch 2/4) the "return !pte.pte"
> implementation, AFAICS?
> 
> So that itself is suspicious to me. And now that this patches does
> things like this:
> 
> -              if (pte_val(*pte)) {
> +              if (!pte_none(*pte)) {
> 
> So previously on paravirt these tests would read pte via the pvops, and
> now they won't. Is that OK?

I've cc'd a few Xen guys.  I think they're the only ones that would care.

But, as far as I can tell, the Xen pte_val() will take a _PAGE_PRESENT
PTE and muck with it.  But its answer will never differ for an all 0 PTE
from !pte_none() because that PTE does not have _PAGE_PRESENT set.

It does seem fragile that Xen is doing it this way, but I guess it works.