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

Re: [Xen-devel] [PATCH v4 13/24] arm/acpi: Map all other tables for Dom0



On Tue, 1 Mar 2016, Stefano Stabellini wrote:
> On Tue, 1 Mar 2016, Shannon Zhao wrote:
> > On 2016/2/29 22:15, Stefano Stabellini wrote:
> > > On Sun, 28 Feb 2016, Shannon Zhao wrote:
> > >> > From: Shannon Zhao <shannon.zhao@xxxxxxxxxx>
> > >> > 
> > >> > Map all other tables to Dom0 using 1:1 mappings.
> > >> > 
> > >> > Signed-off-by: Shannon Zhao <shannon.zhao@xxxxxxxxxx>
> > >> > ---
> > >> > v4: fix commit message
> > >> > ---
> > >> >  xen/arch/arm/domain_build.c | 26 ++++++++++++++++++++++++++
> > >> >  1 file changed, 26 insertions(+)
> > >> > 
> > >> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > >> > index 64e48ae..6ad420c 100644
> > >> > --- a/xen/arch/arm/domain_build.c
> > >> > +++ b/xen/arch/arm/domain_build.c
> > >> > @@ -1357,6 +1357,30 @@ static int prepare_dtb(struct domain *d, struct 
> > >> > kernel_info *kinfo)
> > >> >  }
> > >> >  
> > >> >  #ifdef CONFIG_ACPI
> > >> > +static void acpi_map_other_tables(struct domain *d)
> > >> > +{
> > >> > +    int i;
> > >> > +    unsigned long res;
> > >> > +    u64 addr, size;
> > >> > +
> > >> > +    /* Map all other tables to Dom0 using 1:1 mappings. */
> > >> > +    for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
> > >> > +    {
> > >> > +        addr = acpi_gbl_root_table_list.tables[i].address;
> > >> > +        size = acpi_gbl_root_table_list.tables[i].length;
> > >> > +        res = map_regions(d,
> > >> > +                          paddr_to_pfn(addr & PAGE_MASK),
> > >> > +                          DIV_ROUND_UP(size, PAGE_SIZE),
> > >> > +                          paddr_to_pfn(addr & PAGE_MASK));
> > >> > +        if ( res )
> > >> > +        {
> > >> > +             panic(XENLOG_ERR "Unable to map 0x%"PRIx64
> > >> > +                   " - 0x%"PRIx64" in domain \n",
> > >> > +                   addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
> > >> > +        }
> > >> > +    }
> > >> > +}
> > > The problem with this function is that it is mapping all other tables to
> > > the guest, including the unmodified FADT and MADT. This way dom0 is
> > > going to find two different versions of the FADT and MADT, isn't that
> > > right?
> > >  
> > We've replaced the entries of XSDT table with new value. That means XSDT
> > points to new table. Guest will not see the old ones.
> 
> All right. Of course it would be best to avoid mapping the original FADT
> and MADT at all, but given that they are not likely to be page aligned,
> it wouldn't be easy to do.
> 
> Reviewed-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>

However I have one more question: given that map_regions maps the memory
read-only to Dom0, isn't it possible that one or more of the DSDT
functions could not work as expected? I would imagine that the ACPI
bytecode is allowed to change its own memory, right?

Note that I am not suggesting to change map_regions to map memory
read-write, because that would be undesirable from a security
perspective.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

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