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

Re: [PATCH 2/2] xen/arm: p2m: Populate pages for GICv2 mapping in arch_domain_create()


  • To: Julien Grall <julien@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • Date: Mon, 17 Oct 2022 21:50:44 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=R7edvmSZZq3qVoN3yhQXeokM7ol1GAXlsxTkm2pEaxM=; b=SO7WZOgXxXauLcyqxRzdfAUqHfi3vUGklEhgHh42kP53kCeeQmTxf9bzYoh6KN9JsmsSBV0S3haADJeFbHsr0ZJig2mRxDkMgAoxCnymNSHTv/SAgARCfZRv8l+k2m9AhCre250t9/CkyF8A6+zBir46q7Fitu5O47szVqJe6+O+qpRl03yFrhH1a7BxbYBqilNAw3OclDeSymiALD3QMceT+Ff9/b9zeebwg0wjbEJynJsfyJqLSzwWNZe6y+aX/EW4lpeifrd5KCLodVWiyY1AcwhhFyDHSI07+Q1XUeXldL5iy3EIUXsiuP7hTiH9kCw1A8aH0KyKccW/hcl7QQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MCKJIi0GnrfLhTmVgP6N6UKXzmBNHtgONUv6ht9uESPnA/AugSVnuTVpa9dJVN6IUyLBsqBfq+Q8T1cT+BhtR1cFO1K6BSKd7G7Zdw6YdugeC1DF31VwDDUCOaTCZ/9EIwk14tnsZbMfqY4J0HcWx0tRmR8D35ZzOg9gsmjYJ/HFtv8K0nJFGBUMCdmcktt+Ih3V5JHbIl453ezzt/detA5ZW2WnmMwBo0aB9o7FunWTbzrKc0Gvwt2WRl5rZqaSsdn5jMNd2tMcORmxBTJv5e5BMPjzjBrl0li0oL47tnLhunllew06mQp3L0yt8Lz4hrD0dcHpinNrjpysWAjqmw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Henry Wang <Henry.Wang@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>
  • Delivery-date: Mon, 17 Oct 2022 21:51:16 +0000
  • Ironport-data: A9a23:179yz6x09kFfFckN8eB6t+fExyrEfRIJ4+MujC+fZmUNrF6WrkVUz TdNUWuCbqzZYDHwe9lyOYW//E1Tu5LcztYxHQA9/CAxQypGp/SeCIXCJC8cHc8wwu7rFxs7s ppEOrEsCOhuExcwcz/0auCJQUFUjP3OHPykYAL9EngZbRd+Tys8gg5Ulec8g4p56fC0GArIs t7pyyHlEAbNNwVcbyRFtspvlDs15K6o4WtB4QRkDRx2lAS2e0c9Xcp3yZ6ZdxMUcqEMdsamS uDKyq2O/2+x13/B3fv8z94X2mVTKlLjFVDmZkh+AsBOsTAbzsAG6Y4pNeJ0VKtio27hc+ada jl6ncfYpQ8BZsUgkQmGOvVSO3kW0aZuoNcrLZUj2CA6IoKvn3bEmp1T4E8K0YIw3bdIOGd36 PwhNi1cdkDdrfK2yeKrY7w57igjBJGD0II3nFhFlGicJtF/BJfJTuPN+MNS2yo2ioZWB/HCa sEFaD1pKhPdfxlIPVRRA5U79AuqriCnL3sE9xTI++xuvTi7IA9ZidABNPL8fNCQSNoTtUGfv m/cpEzyAw0ANczZwj2Amp6prr+VzHmkBNtDfFG+3txA3EW0y3UaMhA5XEWSsdqniVajXfsKf iT4/QJr98De7neDTMT5XhC+iG6JuFgbQdU4O/037kSBx7TZ5y6dB3MYVXhRZdo+rsg0SDc2k FiTkLvBJTFpqqzTdnub+Z+dtzb0Mi8QRUcZfjMNRwYB59jloakwgwjJQ9IlF7S65vXLHjX3z yGPvTIJrbwZhs4W1I225VnCxTmro/DhRAMv+h/eWG7j6wpjfZOkfKSh812d5vFFRLt1VXGEt XkA3sOZteYHCMjUkDTXGbtdWra0+/yCLTvQx0Z1GIUs/Cis/Hjlep1M5DZ5JwFiNcNslSLVX XI/cDh5vPd7VEZGp4cuC25tI6zGFZTdKOk=
  • Ironport-hdrordr: A9a23:VYtSy6HteNi6BY9mpLqFS5HXdLJyesId70hD6qkvc3Fom52j/f xGws5x6fatskdrZJkh8erwW5Vp2RvnhNNICPoqTM2ftW7dySeVxeBZnMHfKljbdxEWmdQtsp uIH5IeNDS0NykDsS+Y2nj2Lz9D+qjgzEnAv463oBlQpENRGthdBmxCe2Sm+zhNNW177O0CZf +hD6R8xwaISDAyVICWF3MFV+/Mq5ngj5T9eyMLABYh9U2nkS6owKSSKWnY4j4uFxd0hZsy+2 nMlAL0oo+5teug9xPa32jPq7xLhdrazMdZDsDksLlUFtyssHfqWG1SYczGgNkHmpDq1L/sqq iKn/4UBbUw15oWRBDynfKi4Xi47N9k0Q6e9bbRuwqenSW+fkN1NyMJv/MmTvOSgXBQw+1Uwe ZF2XmUuIFQCg6FlCPh58LQXxUvjUasp2E++NRjxkC3fLFuH4O5l7Zvin99AdMFBmb3+YonGO 5hAIXV4+tXa0qTazTcsnN0yNKhU3wvFlPeK3Jy8fC9wnxThjR03kEYzMsQkjMJ8488UYBN46 DBPr5znL9DQ8cKZeZ2BfsHQ8GwFmvRKCi8eF66MBDiDuUKKnjNo5n47PE84/yrYoUByN8olJ HIQDpjxBoPkoLVeLizNbFwg2PwqT+GLEXQI+llluhEk6y5Qqb3OiueT11rm9e8opwkc7/mZ8 o=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHY4lyBiWnfx+vnUkmAUdSmWjh5Xq4TC2qAgAAU4AA=
  • Thread-topic: [PATCH 2/2] xen/arm: p2m: Populate pages for GICv2 mapping in arch_domain_create()

On 17/10/2022 21:36, Julien Grall wrote:
> Hi Andrew,
>
> On 17/10/2022 20:12, Andrew Cooper wrote:
>> From: Henry Wang <Henry.Wang@xxxxxxx>
>>
>> The XSA-409 fixes discovered that the GICv2 path tries to create P2M
>> mappings
>> in the domain_create() path.  This fails, as the P2M pool is empty
>> before a
>> XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION hypercall.
>>
>> As a stopgap, automatically give domains 16 pages of P2M memory. 
>> This is
>> large enough to allow the GICv2 case to work, but small enough to not
>> introduce a continuation worry.
>>
>> A consequence is that, for later error paths domain_create(), we end
>> up in
>> p2m_final_teardown() with a nonzero P2M pool.  Such a domain has no
>> vCPUs, and
>> has never been scheduled, so free the memory directly.
>>
>> Fixes: cbea5a1149ca ("xen/arm: Allocate and free P2M pages from the
>> P2M pool")
>> Suggested-by: Julien Grall <jgrall@xxxxxxxxxx>
>
> This is not really in the spirit of my original suggestion anymore

Ok, I have dropped it.

> ... In fact, you drop all the explanations regarding how the code is
> fragile (e.g. we are relying on early mapping to not take any extra
> reference). Maybe you don't care, but I do as Henry and I spent ages
> to figure out all the corner cases.

I presume you're referring to the todo?  If so, that's an statement, not
an explanation of what is suddenly different about it.

What has XSA-409 changed in this regard?  Because it looks like the
answer is nothing and the GICv2 path was similarly fragile beforehand. 
In which case, why it is appropriate content for a security patch?

>
>> Signed-off-by: Henry Wang <Henry.Wang@xxxxxxx>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> ---
>> CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
>> CC: Julien Grall <julien@xxxxxxx>
>> CC: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
>> CC: Bertrand Marquis <bertrand.marquis@xxxxxxx>
>> CC: Henry Wang <Henry.Wang@xxxxxxx>
>> ---
>>   xen/arch/arm/p2m.c | 43 +++++++++++++++++++++++++++++++++++++++++--
>>   1 file changed, 41 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
>> index 6826f6315080..76a0e31c6c8c 100644
>> --- a/xen/arch/arm/p2m.c
>> +++ b/xen/arch/arm/p2m.c
>> @@ -1736,8 +1736,36 @@ void p2m_final_teardown(struct domain *d)
>>       if ( !p2m->domain )
>>           return;
>>   -    ASSERT(page_list_empty(&p2m->pages));
>> -    ASSERT(page_list_empty(&d->arch.paging.p2m_freelist));
>> +    /*
>> +     * On the domain_create() error path only, we can end up here
>> with a
>> +     * non-zero P2M pool.
>> +     *
>> +     * At present, this is a maximum of 16 pages, spread between
>> p2m->pages
>> +     * and the free list.  The domain has never been scheduled (it
>> has no
>> +     * vcpus), so there is TLB maintenance to perform; just free
>> everything.
>> +     */
>> +    if ( !page_list_empty(&p2m->pages) ||
>> +         !page_list_empty(&d->arch.paging.p2m_freelist) )
>> +    {
>> +        struct page_info *pg;
>> +
>> +        /*
>> +         * There's no sensible "in the domain_create() error path"
>> predicate,
>> +         * so simply sanity check that we don't have unexpected work
>> to do.
>> +         */
>> +        ASSERT(d->arch.paging.p2m_total_pages <= 16);
>> +
>> +        spin_lock(&d->arch.paging.lock);
>> +
>> +        while ( (pg = page_list_remove_head(&p2m->pages)) )
>> +            free_domheap_page(pg);
>> +        while ( (pg =
>> page_list_remove_head(&d->arch.paging.p2m_freelist)) )
>> +            free_domheap_page(pg);
>> +
>> +        d->arch.paging.p2m_total_pages = 0;
>> +
>> +        spin_unlock(&d->arch.paging.lock);
>> +    }
>
> ... you are hardcoding both p2m_teardown() and p2m_set_allocation().
> IMO this is not an improvement at all. It is just making the code more
> complex than necessary and lack all the explanation on the assumptions.
>
> So while I am fine with your patch #1 (already reviewed it), there is
> a better patch from Henry on the ML. So we should take his (rebased)
> instead of yours.

If by better, you mean something that still has errors, then sure.

There's a really good reason why you cannot safely repurpose
p2m_teardown().  It's written expecting a fully constructed domain -
which is fine because that's how it is used.  It doesn't cope safely
with an partially constructed domain.


Yes, this code is a bit nasty, but it's less buggy than all attempts
presented thus far, specifically because it avoids inappropriate
repurposing of infrastructure.

At this point, we're a week after the publishing of XSA-409 and CI is
still red across the board.  There were multiple failings which have
lead to this situation, that the security team need to deal with, but
right now, we need a correct fix and we need it yesterday.

~Andrew

 


Rackspace

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