Re: [Xen-devel] [PATCH v8 0/8] xen/arm: introduce GNTTABOP_cache_flush

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.10.14 at 12:36, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Mon, 20 Oct 2014, Jan Beulich wrote:
>> >>> On 20.10.14 at 11:47, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> > Hi all,
>> > this patch series introduces a new hypercall to perform cache
>> > maintenance operations on behalf of the guest. It is useful for dom0 to
>> > be able to cache flush pages involved in a dma operation with
>> > non-coherent devices.
>> > 
>> > It also removes XENFEAT_grant_map_identity as the feature is no longer
>> > necessary: it was used to achieve the same goal but the guest can now
>> > use the hypercall instead. Keeping the flag would also have a
>> > significant performance impact as a new p2m mapping gets created and
>> > then destroyed for every grant that is mapped and unmapped in dom0.
>> > 
>> > 
>> > Changes in v8:
>> > - remove unused #include;
>> > - set max_nr_grant_frames as __initdata;
>> > - set max_grant_frames and max_maptrack_frames as __read_mostly;
>> > - respent coding style for comments;
>> > - remove MAX_MAPTRACK_TO_GRANTS_RATIO;
>> > - avoid security issues, use two separate opaque variables to store the
>> > input argument and the output argument;
>> 
>> Security issues?
> 
> The user could have passed in an opaque value for a gnttabop that
> doesn't use it, causing Xen to keep looping over the continuation.
> I fixed it by using two different variable to save the opaque input and
> output.

Hmm, but that's not really a security issue, since the preemption
in between guarantees Xen's health. All it would end up being is a
guest vCPU looping indefinitely.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel