Re: [xen-unstable test] 56456: regressions - FAIL

["Roger Pau Monné" <roger.pau@citrix.com>]

El 20/05/15 a les 11.43, Tim Deegan ha escrit:
> At 10:12 +0100 on 20 May (1432116766), Jan Beulich wrote:
>>>>> On 20.05.15 at 10:58, <roger.pau@citrix.com> wrote:
>>> After looking into this a little bit more, I'm afraid I don't see a
>>> straight forward way to check for the permissions of all paging levels.
>>> Here are the options I've found in order to deal with this:
>>>
>>>  - Use guest_get_eff_l1e and only check for the permissions of the L1
>>>    entry. Is it possible that the guest places an invalid entry in the
>>>    linear l1 table without Xen realizing?
>>
>> No - all page table changes are being validated by Xen.
> 
> Yes, using guest_get_eff_l1e() is safe for Xen.  The only concern is
> whether it's safe for the guest -- Xen might not honour an upper-level
> read-only mark (which copy_to_guest() would) or a supervisor-mode-only
> mark (which it wouldn't).
> 
>>>  - Add a new function hook somewhere (pv_domain maybe?) that can be
>>>    used to translate GVA to PFN for PV guests (mimicking what
>>>    paging_gva_to_gfn does). This would be implemented using
>>>    guest_walk_X_level, where X is the paging levels of the guest.
>>>
>>>  - Use some glue to be able to call guest_walk_{3/4}_level from
>>>    paging.c directly, and correctly choose which one to use based on
>>>    the guest bitness. IMHO this looks quite wacky, and I'm not even
>>>    sure if it's possible given the amount of preprocessor foo in
>>>    guest_pt.h.
>>>
>>> I have the first option already implemented, but I would appreciate some
>>> advice regarding the security implications of it.
>>
>> I think with all of the options here being unsatisfactory we should
>> reconsider your original option of restoring previous behavior
>> (without any mapping) for the PV case. Tim?
> 
> Yeah, I don't think it's worth adding a bunch mode pagetable-walk
> machinery just to keep this function clean.  So I suppose we have to
> have two paths. in this code.

FWIW there's also the option of taking the callers p2m lock if it's a
HVM guest:

http://lists.xen.org/archives/html/xen-devel/2014-10/msg01769.html

And avoid doing any modifications of the code paths.

Roger.