linux-kernel - Re: Populating multiple ptes at fault time

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]

Date:	Wed, 17 Sep 2008 15:47:53 -0700
From:	Avi Kivity <avi@...hat.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
CC:	Nick Piggin <nickpiggin@...oo.com.au>,
	Hugh Dickens <hugh@...itas.com>,
	Linux Memory Management List <linux-mm@...ck.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Avi Kivity <avi@...ranet.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>
Subject: Re: Populating multiple ptes at fault time

Jeremy Fitzhardinge wrote:
>> One problem is the accessed bit.  If it's unset, the shadow code
>> cannot make the pte present (since it has to trap in order to set the
>> accessed bit); if it's set, we're lying to the vm.
>>     
>
> So even if the guest pte were present but non-accessed, the shadow pte
> would have to be non-present and you'd end up taking the fault anyway?
>
>   

Yes.

> Hm, that does undermine the benefits.  Does that mean that when the vm
> clears the access bit, you always have to make the shadow non-present? 
> I guess so.  And similarly with dirty and writable shadow.
>
>   

Yes.

> The counter-argument is that something has gone wrong if we start
> populating ptes that aren't going to be used in the near future anyway -
> if they're never used then any effort taken to populate them is wasted. 
> Therefore, setting accessed on them from the outset isn't terribly bad.
>
>   

We don't know whether the page will be used or not.  Keeping the 
accessed bit clear allows the vm to reclaim it early, and in preference 
to the pages it actually used.

We could work around it by having a hypercall to read and clear accessed 
bits.  If we know the guest will only do that via the hypercall, we can 
keep the accessed (and dirty) bits in the host, and not update them in 
the guest at all.  Given good batching, there's potential for a large 
win there.

(If the host throws away a shadow page, it could sync the bits back into 
the guest pte for safekeeping)

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/