Re: [Xen-devel] [PATCH v3 07/15] argo: implement the register op

[Roger Pau Monné <royger@xxxxxxxxxxx>]

On Fri, Jan 11, 2019 at 7:29 AM Christopher Clark
<christopher.w.clark@xxxxxxxxx> wrote:
>
> On Thu, Jan 10, 2019 at 3:25 AM Roger Pau Monné <royger@xxxxxxxxx> wrote:
> >
> >  On Mon, Jan 7, 2019 at 8:44 AM Christopher Clark
> > <christopher.w.clark@xxxxxxxxx> wrote:
> > > +static int
> > > +ring_map_page(struct argo_ring_info *ring_info, unsigned int i, void 
> > > **out_ptr)
> > > +{
> > > +    if ( i >= ring_info->nmfns )
> > > +    {
> > > +        gprintk(XENLOG_ERR,
> > > +               "argo: ring (vm%u:%x vm%d) %p attempted to map page  %u 
> > > of %u\n",
> > > +                ring_info->id.domain_id, ring_info->id.port,
> > > +                ring_info->id.partner_id, ring_info, i, 
> > > ring_info->nmfns);
> > > +        return -ENOMEM;
> > > +    }
> > > +
> > > +    if ( !ring_info->mfns || !ring_info->mfn_mapping)
> > > +    {
> > > +        ASSERT_UNREACHABLE();
> > > +        ring_info->len = 0;
> > > +        return -ENOMEM;
> > > +    }
> > > +
> > > +    if ( !ring_info->mfn_mapping[i] )
> > > +    {
> > > +        /*
> > > +         * TODO:
> > > +         * The first page of the ring contains the ring indices, so both 
> > > read
> > > +         * and write access to the page is required by the hypervisor, 
> > > but
> > > +         * read-access is not needed for this mapping for the remainder 
> > > of the
> > > +         * ring.
> > > +         * Since this mapping will remain resident in Xen's address 
> > > space for
> > > +         * the lifetime of the ring, and following the principle of least
> > > +         * privilege, it could be preferable to:
> > > +         *  # add a XSM check to determine what policy is wanted here
> > > +         *  # depending on the XSM query, optionally create this mapping 
> > > as
> > > +         *    _write-only_ on platforms that can support it.
> > > +         *    (eg. Intel EPT/AMD NPT).
> >
> > Why do Intel EPT or AMD NPT matter here?
>
> I think (though could be wrong and am open to correction here) that
> EPT and NPT enable the construction of write-only (ie not readable)
> memory mappings. Standard page tables can't do that: with those,
> if it's writable, it's also readable.

The hypervisor itself doesn't run on EPT or NPT second stage
translation, that's used exclusively for (HVM) guests. So even if
there's such support in EPT or NPT it's not relevant here. x86 page
tables don't have the capability to create write-only mappings.

Thanks, Roger.

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