Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp443502rwb; Thu, 11 Aug 2022 04:32:08 -0700 (PDT) X-Google-Smtp-Source: AA6agR56lEVnGeSEdDKhkGOv6AApc6PD9ca7oNLe3wKU9tRtFSBSo/mT2ihklEtBSVPACk+mbUqY X-Received: by 2002:a05:6402:11cf:b0:43d:fc84:c51a with SMTP id j15-20020a05640211cf00b0043dfc84c51amr29884789edw.80.1660217528059; Thu, 11 Aug 2022 04:32:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660217528; cv=none; d=google.com; s=arc-20160816; b=KWQDlm+VXGj9DFhNokaCFKm8n/YEZfoQTBsLhlcX5h4ihZ6rjJ1O9ZAQJTdDCiqOSn JfN6ER5+p9bBj9fWS2wT16UQtlwl5rG4pKiK2H8CkThKLW3V/egRdy1nBuQHoCtvfCBF EoFDjYiEwnS2NYeXhYQgO1fwQLRqm9jCxLrm9yZ7dFtMD11o8WUyh5tCqsPUG3ec3Kmv hgF4NBpSbQgTNxtId/S7wzzuFr2XWY+JGCq6jjWBtFvTOjv9vHEW0kmIstyvx0ufSKIh aKjiezh4k7+zQ/YE5eijIpPe4eNrli+P4ALAQR/tQR9dPzu8NjsIiomLJli48ayDOf/x 2yBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=UY0huCcMksTkB4oLQLF5MAgiiZEs9HuLdo2XFb9uvQw=; b=NwvDhq13taUYiQAGg+iLRhgrXE3efSoxMg0KQPxva920NRoeT984GD0lh4H7oQQjqZ xTmw0niI+UNO6QH4hzDVPSBj4mRrGtQ+w77o7V9k2N6ethQYTGnT9sczZXlqbTbrfVqW IfqLkyVUuxVfpJ6KCHJWSFil7A4KDy1Id6sblha8IJfPIQy6dsIr7qAbk7cir9n3cZ0L 7dKXp954uctm3X7cslriNbau93qn8dAGoaz12BrP+cx2TGk7iLjIY4iLk+YU8UGOMc5V PO4c7smSBmEVGDgHFkHDUPtZUcl7gxxbzVVKF9hnxredGjMS8uOY0D5U67C/HgwNgqvA EO7A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=rmFZk2nF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d23-20020a05640208d700b0043c25d25046si12463589edz.249.2022.08.11.04.31.42; Thu, 11 Aug 2022 04:32:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=rmFZk2nF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234773AbiHKL0x (ORCPT + 99 others); Thu, 11 Aug 2022 07:26:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58652 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234724AbiHKL0u (ORCPT ); Thu, 11 Aug 2022 07:26:50 -0400 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9845A11810; Thu, 11 Aug 2022 04:26:49 -0700 (PDT) Received: from zn.tnic (p200300ea971b9854329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:971b:9854:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 247F21EC056D; Thu, 11 Aug 2022 13:26:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1660217204; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=UY0huCcMksTkB4oLQLF5MAgiiZEs9HuLdo2XFb9uvQw=; b=rmFZk2nFgA8PrMSlwDnyIhuf8Azrn/VmdGgQEjg3g7nzV/uXykxOaiNeOXhEuPPb5Y8Xna OomDtJMKKThisqRUyqWX9k0TBb4IO3OpJ68MEGE5BLGOuTXKJt46Pm+o7a6J8CqM8/Q/A5 rNB4EJb0S/cMZ6BULpUInSoHeE/W8AI= Date: Thu, 11 Aug 2022 13:26:40 +0200 From: Borislav Petkov To: Dave Hansen Cc: "Kirill A. Shutemov" , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , Mike Rapoport , David Hildenbrand , marcelo.cerri@canonical.com, tim.gardner@canonical.com, khalid.elmously@canonical.com, philip.cox@canonical.com, x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv7 10/14] x86/mm: Avoid load_unaligned_zeropad() stepping into unaccepted memory Message-ID: References: <20220614120231.48165-1-kirill.shutemov@linux.intel.com> <20220614120231.48165-11-kirill.shutemov@linux.intel.com> <80cc204b-a24f-684f-ec66-1361b69cae39@intel.com> <073c5a97-272c-c5a0-19f2-c3f14f916c72@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <073c5a97-272c-c5a0-19f2-c3f14f916c72@intel.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 03, 2022 at 07:02:31AM -0700, Dave Hansen wrote: > One other thing I remembered as I re-read my write up on this. > > In the "new" mode, guests never get #VE's for unaccepted memory. They > just exit to the host and can never be reentered. They must be killed. Yeah, this is the part which I think is really silly. OSes, in their execution lifetime, can - erroneously or not - but it happens pretty often in real life, touch some unrelated memory. And this has never been a big deal - #PF, that's it. But now they don't even get a chance to correct their mistake - VMEXIT, die. load_unaligned_zeropad() is just one case. Imagine the user loads some buggy driver in the guest and that driver starts doing stray memory accesses through a wild pointer into the fields. Guest dies immediately. Dunno bit it all feels a bit too harsh and unfriendly to me. Sure, if that user is really unlucky, those stray accesses can kill his OS on baremetal too. So maybe you could argue here that such stray accesses are actually a good thing. :) All I know is, there should be a more resilient way to handle those. > In the "old" mode, I _believe_ that the guest always gets a #VE for > non-EPT-present memory. The #VE is basically the same no matter if the > page is unaccepted or if the host goes out and makes a > previously-accepted page non-present. > > One really nasty implication of this "old" mode is that the host can > remove *accepted* pages that are used in the syscall gap. That means > that the #VE handler would need to be of the paranoid variety which > opens up all kinds of other fun. Yeah, I believe this needs to be dealt with anyway, for SNP at least. But on AMD it would simply cause an exception and it'll be handled in the #VC thing. And there's some ugly code to deal with the gap too. > * "Old" - #VE's can happen in the syscall gap > * "New" - #VE's happen at better-defined times. Unexpected ones are > fatal. > > There's a third option which I proposed but doesn't yet exist. The TDX > module _could_ separate the behavior of unaccepted memory #VE's and > host-induced #VEs. This way, we could use load_unaligned_zeropad() with > impunity and handle it in the #VE handler. At the same time, the host > would not be allowed to remove accepted memory and cause problems in the > syscall gap. Kinda the best of both worlds. I like that. This should've been the default from the get-go. Oh well, what's it called in English, hindsight is 20 20...? > But, I'm not sure how valuable that would be now that we have the > (admittedly squirrelly) code to avoid load_unaligned_zeropad() #VE's. I think you should push for the bestest solution and one day we can kill those ugly workarounds. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette