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

Re: [PATCH 2/8] x86/shadow: properly handle get_page() failing


  • To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 27 Jul 2022 14:53:10 +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:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1NSeQmfm0TmXIBRpni0a/g/m8ad3ZqQCjtk2S8LffOY=; b=Mp5Pzv61GUz4E9JSZ080RhAhdUFy3wR7pJ5y3nh/nqH1wdN9vK4bkvI7sxNPw0w+FCLmzC+V6aUSo4xZW+7ObUxf3ytdt4MiFqHEGEv7TpTcsXyoVtKTfo+AMvREaSkD9u855T1ha4TTCFfso82CEIIhKIhGfiwf40n48n558bfY+d8lk6FPiH3WK0BQsjfvTkrgj0koWu8TueMYepUE+oGcRVoBmtzZPFK2Ern8kdSOQlsFsgju74A8t7zehSGSIfvkckjFbkizTGtX2sunk/eb5a0Ugq8fTxKL7oobz1RvOhhSDxH8NG0XWt4xaRanFRaM1O3ippgM35Fd1U1sxw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ShAaVYo2pp186om5l95BHj82tHk72ykLGdH7/yd8fwChe0kDFD8TrjDW57tymtI7H+XvLVR/zcvQYcd64OuWAEzVNnzL2hTFN0ou/Ze1LIiJVbteI/wKQQrqfEbhURKDtbN8RHdOyiah0LCoET4UyBHr2KpuITllrWMNn3SBel4IuIMVMhIvPHrgvNMlzWx+vDUXSGbIhcG4cy1aX820i05KbtLc5JnY+OEdCH6azQYaF/Z6BEPNP3objPZmUbSXswlO9jLxjUVwvk7rC23iLP7Bv1XmDo74xILsB84eaKZILWn5Fnrl4p0wcaKOTqeVshvIi7OYcStyB6RSJGHCew==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>, "Tim (Xen.org)" <tim@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 27 Jul 2022 12:53:20 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 27.07.2022 14:46, Andrew Cooper wrote:
> On 26/07/2022 17:04, Jan Beulich wrote:
>> We should not blindly (in a release build) insert the new entry in the
>> hash if a reference to the guest page cannot be obtained, or else an
>> excess reference would be put when removing the hash entry again. Crash
>> the domain in that case instead. The sole caller doesn't further care
>> about the state of the guest page: All it does is return the
>> corresponding shadow page (which was obtained successfully before) to
>> its caller.
>>
>> To compensate we further need to adjust hash removal: Since the shadow
>> page already has had its backlink set, domain cleanup code would try to
>> destroy the shadow, and hence still cause a put_page() without
>> corresponding get_page(). Leverage that the failed get_page() leads to
>> no hash insertion, making shadow_hash_delete() no longer assume it will
>> find the requested entry. Instead return back whether the entry was
>> found. This way delete_shadow_status() can avoid calling put_page() in
>> the problem scenario.
>>
>> For the other caller of shadow_hash_delete() simply reinstate the
>> otherwise dropped assertion at the call site.
>>
>> While touching the conditionals in {set,delete}_shadow_status() anyway,
>> also switch around their two pre-existing parts, to have the cheap one
>> first (frequently allowing to avoid evaluation of the expensive - due to
>> evaluate_nospec() - one altogether).
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, although with
> some observations and a suggestion.

Thanks.

>> --- a/xen/arch/x86/mm/shadow/multi.c
>> +++ b/xen/arch/x86/mm/shadow/multi.c
>> @@ -132,7 +132,8 @@ delete_fl1_shadow_status(struct domain *
>>      SHADOW_PRINTK("gfn=%"SH_PRI_gfn", type=%08x, smfn=%"PRI_mfn"\n",
>>                     gfn_x(gfn), SH_type_fl1_shadow, mfn_x(smfn));
>>      ASSERT(mfn_to_page(smfn)->u.sh.head);
>> -    shadow_hash_delete(d, gfn_x(gfn), SH_type_fl1_shadow, smfn);
>> +    if ( !shadow_hash_delete(d, gfn_x(gfn), SH_type_fl1_shadow, smfn) )
>> +        ASSERT_UNREACHABLE();
> 
> I'd recommend crashing the domain here too.  I know the we've already
> got the return value we want, but this represents corruption in the
> shadow pagetable metadata, and I highly doubt it is safe to let the
> guest continue to execute in such circumstances.

I'm happy to add or convert, but please clarify: DYM in addition to
the assertion or in place of it?

Jan



 


Rackspace

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