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

Re: [PATCH] x86/altp2m: p2m_altp2m_get_or_propagate() should honor ap2m->default_access


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
  • Date: Thu, 8 Feb 2024 09:20:07 -0500
  • Arc-authentication-results: i=1; mx.zohomail.com; dkim=pass header.i=tklengyel.com; spf=pass smtp.mailfrom=tamas@xxxxxxxxxxxxx; dmarc=pass header.from=<tamas@xxxxxxxxxxxxx>
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1707402045; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=wH+tUFLsw/E6eFvRCsiAGUx0r/1n1jC6F6nrBzmppjw=; b=J9hCL+1ft5Jj/81uYp0xdbbf7XI7lD/EYRixMIiPMXA+qXxWqTSULPb9SVG1FHWJWMesg9dvJP6Z0bHkiAqVQallz2IpKr/hwDjlPUTDLyfHx572m4OK+NVkM2rFMt/to2Igo8nTSBuaiP2t3GsK5g6ltR1xPr/TjStOqNcvXNQ=
  • Arc-seal: i=1; a=rsa-sha256; t=1707402045; cv=none; d=zohomail.com; s=zohoarc; b=erM+YJ+oErLz1jNKp9+2tLdezaW6rMeY2qT5KKWstrvztH4QTQLpT8+x+/eyuRQAeAvm9PDU6AXDJZ1neUiNFYyFlNLe7RrppGP3TaVx3stcGWu4AfhvEUolDtCaIGE58tYcbCn4ls3vik8tjTKJhlPsTC//0V5owQudYxriM8Y=
  • Cc: George Dunlap <george.dunlap@xxxxxxxxx>, Petr Beneš <w1benny@xxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx>, Petre Pircalabu <ppircalabu@xxxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Thu, 08 Feb 2024 14:20:56 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Feb 8, 2024 at 9:00 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 08.02.2024 14:45, Tamas K Lengyel wrote:
> > On Thu, Feb 8, 2024 at 2:46 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
> >>
> >> On 08.02.2024 05:32, George Dunlap wrote:
> >>> Er, ok, just one more comment: this could allow an altp2m to have more
> >>> permissions than the host; for example, the host p2m entry could be
> >>> p2m_access_r, but if the altp2m's default_access were p2m_access_rw,
> >>> it would override that.  Is that the behavior we want?  Or do we want
> >>> to do some sort of intersection of permissions?
> >>>
> >>> If the former, I'd propose the comment be adjusted thus:
> >
> > No intersection of permissions please, that needlessly complicates
> > things and makes it hard to reason about the state of a view where
> > default permissions are used. No need to force a specific type of
> > usecase here where the hostp2m's permissions are special just cause we
> > say so. No, the permissions in the hostp2m should not have more weight
> > then the specifically requested default permission.
> >
> >>>
> >>>  * If the entry is invalid, and the host entry was valid, propagate
> >>>  * the host's entry to the altp2m, retaining page order but using the
> >>>  * altp2m's default_access, and indicate that the caller should re-try
> >>>  * the faulting instruction.
> >>
> >> I find it highly questionable that such blind overriding should be taking
> >> place.
> >
> > It's not blind overriding, it's the requested default permission set
> > for a view where no entry was present before. It is the expected
> > behavior. It would be way harder to design applications with this
> > feature if it was special cased and it would take different
> > permissions based on what permission is set in another view.
>
> But the default can be only one specific value: How do you make sure that
> R/O, R/X, and R/W mappings all retain their respective restrictions in the
> alternative view? To not over-restrict permissions, the default would then
> need to be RWX, yet then all mappings will have full permission. What am I
> missing?

Why do you assume you need to retain the permissions that were set in
the hostp2m across all altp2ms? It is entirely reasonable to set
permissions for a couple entries manually in an altp2m and set the
default to _n, which may be totally different then what the hostp2m
has. When you get the event for entries you didn't manually specify
you can decide which view to switch to, which may be the hostp2m, but
may be some other view.

If you wanted to have a view with a default permission that inherits
permissions that are always at least as restrictive as the hostp2m,
you could do that, but the way to do that would be to introduce a
special mem_access permission to signify that that's the expected
behavior (similar to permissions like n2rwx). I don't think anyone is
asking for that.

Tamas



 


Rackspace

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