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

Re: [PATCH v3 9/9] x86/P2M: relax permissions of PVH Dom0's MMIO entries


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 23 Sep 2021 17:22:08 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=S8F5spUXCIFyMGVa/FcabhfBFjtAKXUGA3Y0aDXtnNU=; b=EKfctUrY1SXXDK7jHadv0VkeIkdYPOI0uHTfvLlIjNh7HgFq8dJhkl4Xu533gurSdQlrHyEXJit/SIh/3s6002edqFrmnhk81wHAThRW49iQu6BvGyZyh7PDT2KLi2HJo8ZGpQXaz6nLB8JhCaF8bh56kzr5A9SPwaH2vjBWPpbeyIaVKm7BMWWE52w5bjv10dbFDNgP3OqtWqkmtk4sCOalcIYSxmhXwHfYDlZMe9UyvmqM/U0fRbYDNRgRZyV/TlEpxMmoot3/47S8f5Ge6m/V7fLu/VSkOYxgYK4XNmYQqHOZBJaG0nsIHPGLyKrzApZgJv2CbeVYE67rBwf1Og==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K61WgJnFEqxShCxcPAFIQom1g3D4L9mCeViYzeJfbxbCuOM1dmY/WnRhKW+VaVzcrWXOguCjI2Kgi5plNHzmRgM+BUu6ZqHvzePaKRbSipgmAaUyt/pdSjGve0UCxFvSZLx5MagnuODOl0i//NxlCQHOwzCrw5YeubzEQyfHpo60jhs0X7KLXP9d7AFWbbk+cFdYb7u3vTo8noRH8p/mk48f/ruILtcJLicEILSoSR95TcWmOXVuI+zvVCl9GR83OqS3HtTXJnHGg3lycoT1m3MnA2Jwsc/CrvqlW6STZP7UI3RHH5WUdoy6zHELVBEgDsr0ZqjfJHQNbg8PFSXh4g==
  • Authentication-results: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>
  • Delivery-date: Thu, 23 Sep 2021 15:22:19 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 23.09.2021 17:15, Roger Pau Monné wrote:
> On Thu, Sep 23, 2021 at 02:15:25PM +0200, Jan Beulich wrote:
>> On 23.09.2021 13:54, Roger Pau Monné wrote:
>>> On Thu, Sep 23, 2021 at 01:32:52PM +0200, Jan Beulich wrote:
>>>> On 23.09.2021 13:10, Roger Pau Monné wrote:
>>>>> On Tue, Sep 21, 2021 at 09:21:11AM +0200, Jan Beulich wrote:
>>>>>> --- a/xen/arch/x86/mm/p2m.c
>>>>>> +++ b/xen/arch/x86/mm/p2m.c
>>>>>> @@ -1319,6 +1319,18 @@ static int set_typed_p2m_entry(struct do
>>>>>>              return -EPERM;
>>>>>>          }
>>>>>>  
>>>>>> +        /*
>>>>>> +         * Gross bodge, to go away again rather sooner than later:
>>>>>> +         *
>>>>>> +         * For MMIO allow access permissions to accumulate, but only 
>>>>>> for Dom0.
>>>>>> +         * Since set_identity_p2m_entry() and set_mmio_p2m_entry() 
>>>>>> differ in
>>>>>> +         * the way they specify "access", this will allow the ultimate 
>>>>>> result
>>>>>> +         * to be independent of the sequence of operations.
>>>>>
>>>>> Wouldn't it be better to 'fix' those operations so that they can work
>>>>> together?
>>>>
>>>> Yes, but then we should do this properly by removing all abuse of
>>>> p2m_access_t.
>>>
>>> I'm not sure I follow what that abuse is.
>>
>> As was clarified, p2m_access_t should be solely used by e.g.
>> introspection agents, who are then the entity responsible for
>> resolving the resulting faults. Any other uses (to e.g. merely
>> restrict permissions for other reasons) are really abuses.
> 
> But some p2m types don't really have a fixed access tied to them, for
> example MMIO regions just inherit whatever is the default access for
> the domain, which makes all this look slightly weird. If the access
> should solely be used by introspection, then each type should have a
> fixed access tied to it?

I think so, yes. Hence e.g. p2m_ram_ro and p2m_grant_map_r{w,o}.

>> That
>> is, if e.g. a r/o direct-MMIO mapping is needed, this should not
>> be expressed as (p2m_mmio_direct, p2m_access_r) tuple, but would
>> require a distinct p2m_mmio_direct_ro type.
> 
> I guess we would then require a p2m_mmio_direct_ro,
> p2m_mmio_direct_rwx and a p2m_mmio_direct_n at least, and ideally we
> would need to differentiate the mandatory regions as present in ACPI
> tables using yet different types.

What would we need p2m_mmio_direct_n for? And what's the (present,
not future) reason for the x in p2m_mmio_direct_rwx?

Jan




 


Rackspace

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