[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v4] gnttab: don't expose host physical address without need

On 06.12.2019 20:48, Andrew Cooper wrote:
> On 05/12/2019 16:57, Jan Beulich wrote:
>> On 05.12.2019 16:47, Andrew Cooper wrote:
>>> On 05/12/2019 15:34, Jan Beulich wrote:
>>>> Translated domains shouldn't see host physical addresses. While the
>>>> address is also not supposed to be handed back even to non-translated
>>>> domains when GNTMAP_device_map is not set (as explicitly stated by a
>>>> comment in the public header), PV kernels (Linux at least) assume the
>>>> field to get populated nevertheless.
>>> This really means that the public header needs correcting.  The field
>>> may not have intended to escape out of Xen, but it is defacto part of
>>> the ABI now.
>> Well, that's one of two possible routes. The other is to have, like
>> you did suggest earlier on, a mode in which we behave more strictly,
>> and current Linux then wouldn't work on such a Xen until fixed.
> I'm sorely tempted to introduce a "fully strict mode" right now, behind
> a command line option, which chops off all the bits which shouldn't be
> usable in their current form.
> However, nothing, not even dom0, will boot successfully, so it probably
> isn't a great idea right now.  Also, we'd have an easier time starting
> from nothing and whitelisting ok things in, than attempt to locate
> everything that we should blacklist in the current configuration.

Okay, I'll add a remark to the public header comment then for now.

>>>> (Similarly mapkind() should check only GNTMAP_device_map.)
>>> Is this comment stale, or have I misunderstood some of the reasoning?
>> It's certainly not stale. mapkind() is used to determine whether
>> IOMMU mapping adjustments are needed. With this, it should in
>> principle only consider whether the current operation would
>> possibly alter IOMMU mapping needs. What needs doing should,
>> according to my interpretation of the originally intended design,
>> only depend on current and prior requests with GNTMAP_device_map
>> set.
> That's all reasonable, but there are no edits to mapkind(), so I'm
> confused as to why this is present in the commit message.

Well, it's the same underlying problem - improper separation of
host_map from device_map. I've added this just to emphasize that
this likely wasn't an oversight, but intentional (yet wrong, at
least afaict).


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.