On Tue, Apr 4, 2017 at 9:58 AM, Andrew Cooper <andrew.coop...@citrix.com>
wrote:
> On 04/04/17 16:39, Tamas K Lengyel wrote:
>
>
>
> On Tue, Apr 4, 2017 at 9:11 AM, Andrew Cooper <andrew.coop...@citrix.com>
> wrote:
>
>> On 04/04/17 13:14, Razvan Cojocaru wrote:
>> > Currently xc_translate_foreign_address only checks for PSE bit only on
>> > level 2 entries (that's 2 MB pages on x64 and 32-bit with PAE, and 4 MB
>> > pages on 32-bit). But linux kernel sometimes uses 1 GB pages. This patch
>> > fixes that, and checks the PSE bit on level 3 entries if the guest has 4
>> > translation levels (that means 64-bit guests only).
>> >
>> > Signed-off-by: Cristian-Bogdan Sirb <cs...@bitdefender.com>
>>
>> This function is in a rather tragic state. Lucky it isn't used by code
>> covered by Xen's security statement.
>>
>> This patch reintroduces XSA-176, and the existing code doesn't work for
>> 4M superpages, or guests using PSE36. (I might be acutely aware of
>> pagetable issues, following c/s
>> 4c5d78a10dc89). Furthermore, the map/unmap overhead must be a large
>> overhead.
>>
>
> Indeed it is, that's why in LibVMI there is actually a cache implemented
> for mapped pages so we throw them away only after they have been idle for a
> while.
>
>
>>
>> How often is this used by introspection? To properly walk the
>> pagetables, you need access to the CPUID information (as well as the
>> control register state), and that isn't yet available to the toolstack
>> in Xen.
>>
>
> Control register state is certainly available.
>
>
>>
>> I'm wondering whether it might be better to have a way of asking Xen to
>> perform a virtual to linear translation in the context of a specific
>> vcpu. My gut feeling is that it might be quicker than running this
>> logic, and is definitely more simple than trying to fix this code not to
>> have vulnerabilities in it.
>
>
> I don't think it would be necessary. IMHO doing this in Xen wouldn't
> really net us much performance-wise. Furthermore, there are certain PTE
> bits that are OS specific and Xen wouldn't necessary have the required
> information to do the translation properly (ie. present bit unset but
> transition bits used for Windows guests).
>
>
> Ok. Xen needs to care only about the behaviour of real pointers in guest
> context, and whether they raise #PF.
>
> It sounds like the best thing to do is to provide userspace with all
> information it needs to actually perform the walk safely, and let the
> library apply guest-specific knowledge if it wants.
>
> Off the top of my head, the control information needed is:
>
> Hap/Shadow, hardwares views towards page1gb and pse36, whether EFER.NX is
> leaked from Xen, EFER.NX, CR0.{PG,WP}, CR4.{PAE,PSE,PCID,SMEP,SMAP,PKE},
> and the PDPTRs for the 32bit PAE case, because the translation in use isn't
> necessary the value you would read by following CR3 in memory.
>
The userspace already has access to these informations and we use them in
LibVMI already (see
https://github.com/libvmi/libvmi/blob/master/libvmi/memory.c#L37). It's
only this libxc function that has not really been touched in a long time
because I don't think anyone uses it..
Tamas
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
