Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 12/11/2017 06:00 PM, Tamas K Lengyel wrote:
>>> I think Jan was saying that he would ideally like to remove *all* guest
>>> access to altp2m functionality, even what's currently there.  The more
>>> extra features we make available to guests, the harder it will be in the
>>> future to argue to remove it all.
>>
>> With one slight correction: all _uncontrolled_ access is what I'd like
>> to see removed. Right now this could arguably indeed mean all
>> access, as it is all uncontrolled (afaict).
>>
> 
> But it is controlled. Unless you specifically allow the guest access
> to the interface (ie altp2m=1 in the xl config) the guest can't do
> anything with it. And if you do that, it is likely because you have an
> in-guest agent that works in tandem with an out-of-guest agent
> coordinating what to protect and how. You use the in-guest agent for
> performance-sensitive monitoring while you can use the out-of-guest
> agent to protect the in-guest agent. Of course, this is not a
> requirement but what I *think* the setup was that the interface was
> designed for as there is specific ability to decide which page
> permission violation goes to the guest (with #VE) and which goes to
> the toolstack. Plus even if the interface is enabled, it is only
> available to the guest kernel. If it's a malicious guest kernel the
> worst it should be able to do is crash itself (for example by
> allocating a ton of altp2m tables and running out of shadow memory).
> But I don't think you need the altp2m interface for a guest kernel to
> crash itself.

That's precisely how we envision possible use cases as well.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel