[Xen-devel] Re: Illegal PV kernel pfm/pfn translations on PROT_NONE ioremaps

["Stephen C. Tweedie" <sct@xxxxxxxxxx>]

Hi,

On Wed, 2008-03-19 at 16:00 +0000, Keir Fraser wrote:
> Return ~mfn in this case? Still fails the usual is-it-a-valid-pfn tests,

Right... 

>  The key
> is that most of the time invalid pfns are explicitly == end_pfn, or
> max_page, or similar, so we are distinguishing from those and also can still
> bug on that specific value in pfn_to_mfn().

Yep, it will still let pfn_to_mfn pick up that magic number --- it won't
catch corrupted ptes, though, which is a shame.

~mfn on its own probably won't work, though.  On non-PAE, we store mfns
in a pte that only has 20 bits for the information, so we have to deal
with that restricted range.

It might be easier to do this at the pte_machine_to_phys level instead,
where we can potentially take advantage of other bits of the pte to
encode the special casing.

> As for picking this up in the save/restore code -- sounds a bit tricky to
> me. We're better off not allowing migration of a I/O-privileged domain in
> the first place.

Right, clearly.  Ideally, though, we'd make this mechanism robust, and
either have the HV fail the migrate if it finds such ptes, or
alternatively have the kernel BUG on the ptes if the guest is marked
migratable.

The latter sounds cleaner, but would require a mechanism to mark guests
as unmigratable/saveable while they have IO space mapped; I'm not sure
we have a clean way for marking such things right now.

Thinking about it, if a guest could be clearly marked as having IO
permission, we could simply disable both save/migrate AND !PAGE_PRESENT
pfn-to-mfn translation in one go, and solve both problems at once.

Would either SIF_INITDOMAIN or SIF_PRIVILEGED work for this?
SIF_INITDOMAIN would be the safe fix for this particular dom0 case, I
think.  We could do it for SIF_PRIVILEGED too, but ONLY if we were sure
that such domains would never be migrated or saved (we'll corrupt
PROT_NONE mappings if we migrate such domains.)

Cheers,
 Stephen



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel