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

Re: [Xen-devel] [PATCH v3] vpci: honor read-only devices



On 03.09.2019 14:51, Roger Pau Monné  wrote:
> On Tue, Sep 03, 2019 at 02:16:52PM +0200, Jan Beulich wrote:
>> On 03.09.2019 12:14, Roger Pau Monne wrote:
>>> Don't allow the hardware domain write access the PCI config space of
>>> devices marked as read-only.
>>>
>>> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>>> ---
>>> Changes since v2:
>>>  - Fix test harness.
>>>  - Do the RO check before the ownership one.
>>>
>>> Changes since v1:
>>>  - Change the approach and allow full read access, while limiting
>>>    write access to devices marked RO.
>>> ---
>>>  tools/tests/vpci/emul.h | 3 +++
>>>  xen/drivers/vpci/vpci.c | 5 +++++
>>>  2 files changed, 8 insertions(+)
>>>
>>> diff --git a/tools/tests/vpci/emul.h b/tools/tests/vpci/emul.h
>>> index 5d47544bf7..2e1d3057c9 100644
>>> --- a/tools/tests/vpci/emul.h
>>> +++ b/tools/tests/vpci/emul.h
>>> @@ -92,6 +92,9 @@ typedef union {
>>>  #define xfree(p) free(p)
>>>  
>>>  #define pci_get_pdev_by_domain(...) &test_pdev
>>> +#define pci_get_ro_map(...) NULL
>>> +
>>> +#define test_bit(...) false
>>
>> The latter seems rather dangerous to me, as a further addition of
>> test_bit() would silently build fine, but possibly produce a non-
>> working binary. But you're the defacto maintainer of this
>> harness, so if you believe it's fine so be it. (If even
>> xenpaging is considered "fine" to include xc_bitops.h, I wonder
>> if this harness couldn't do so too. And then there are three
>> test_bit() definitions overall under tools/ - I wonder if those
>> couldn't be consolidated into a single, universally usable one.)
> 
> One option would be to turn test_bit into assert(0) which should work
> for the current usage, since test_bit shouldn't be called given the
> current code and will trigger if it actually gets used. Would you be
> fine with merging the chunk below into the current patch?

That's marginally better, but not enough for my taste. IIRC under
tools/ we can't rely on DCE, and hence declaring (but not defining)
test_bit() isn't an option either.

Anyway, as said, I won't object to whatever the tool stack
maintainers are willing to give an ack for.

> I would like to avoid including xc_bitops.h, since the xenpaging
> Makefile already contains a comment regarding the wrong usage of libxc
> internals.

Right, and I wouldn't have dared to suggest this for something that
isn't just a test binary.

Jan

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

 


Rackspace

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