linux-kernel - Re: [patch 6/6] Guest page hinting: s390 support.

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:	Thu, 13 Mar 2008 10:05:11 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	schwidefsky@...ibm.com
CC:	akpm@...l.org, linux-s390@...r.kernel.org, frankeh@...son.ibm.com,
	nickpiggin@...oo.com.au, linux-kernel@...r.kernel.org,
	virtualization@...ts.osdl.org,
	Anthony Liguori <anthony@...emonkey.ws>, hugh@...itas.com
Subject: Re: [patch 6/6] Guest page hinting: s390 support.

Martin Schwidefsky wrote:
> Vz is the page discarded state. The difference to Uz is slim, both
> states will cause a program check on access. Vz generates a discard
> fault, Uz generates an addressing exception which is nice for debugging.
>   

How do you handle these different cases in Linux?  Do you use Vr pages 
in the pagecache, and then shoot down the pagecache entry if the host 
steals the page?

The Uz access exception presumably just generates a normal oops.

(I should probably make time to read the rest of the series.)

>> But given how you've described V-state pages, I really would expect 
>> writes to a Vz to work, or alternatively, all writes to V-state pages to 
>> be disallowed.  Are there any real uses for a writable Vr page?
>>     
>
> You mean in the section that speaks about the guests states S/U/V/P ?
> Always keep in mind that you can access a V/P page only until it gets
> discarded. Then the useful content of the page frame is lost and any
> read of write to the not Vz page will be answered with a discard fault.
>   

Presumably reads from a Vz page also generate a discard fault?

> A Vr page is read-only. If a page gets mapped for writing it needs to
> get into the Pr state. This is the hint for the host to look at the
> dirty bit before it discards a page.
> So yes, there is no use for a writable Vr page.
>   

OK, thanks, that clears things up.  I was assuming that Vr was 
technically writable but that writes could be discarded at any time (ie, 
allowing guests to merrily shoot themselves in the foot ;).  Making it 
forced RO is much more sensible.

    J
--
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/