Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 30DA4C61DA4 for ; Wed, 22 Feb 2023 21:53:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231384AbjBVVxZ (ORCPT ); Wed, 22 Feb 2023 16:53:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231536AbjBVVxW (ORCPT ); Wed, 22 Feb 2023 16:53:22 -0500 Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1EFEF23322 for ; Wed, 22 Feb 2023 13:53:20 -0800 (PST) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-536c02ed619so90262587b3.8 for ; Wed, 22 Feb 2023 13:53:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=vw/kaBZELDn3iRLryB4mmdN5p7w2c/XEDF0NvAc29OA=; b=lxoHUtiZD2a0lkFM1BjQCq6yxSLFOIYuWQzolUrNyKa2FSIrxH8LVVfQtq9f5R/afK LHQpddlnFrOzOB60DXpCwlJJw63AzRfX5jLu5Id0pSE95MxYIsHOiRMLmY5+eU+D3dNu ISieEqZtTt7V23yoxD/xPf7/3fga5CcMm+ewnI7GoqsPeiEDxyu5fgTeEv68la2saMCH djvTvh7dGkVnNbuuTGqlzh9NJbQdVF3quszT4E0e+TCktqOo19NSlqE9gEsehIyDyrqF 4K9oJAEiTWIdzJKlakhzoBeyFOaEj14vWK7iNd4k7zj5V9qLb9MFJbOpw5pQ3v+f49KY Vb8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vw/kaBZELDn3iRLryB4mmdN5p7w2c/XEDF0NvAc29OA=; b=4vLIMcDRh/xSCn3zV5ClESMZPHHfoeLJ40jim/reV4mY5AX131mxIaeokRB5QmfFm2 zfek7MaAthE3F548rVw1IxhdCRxl1N+OIyED4nZJJlKOJfIQzNRHZ6DqMPD2pJf1DGdF KDqUfg1DaVLYs+WVxdCbk8mZf5BsPVkxMLHCtOisdcvEmMM7R773rEzidukYMqspcs1k yXGnNgSLYOCdLV5NaNGzGlcwQwlpHGpbjrLqbuA5r2qLnutQ9Djb7vzbtIVN2JJpYaL+ 1MYWEGcB4Qm3lqZif6zwJAFmEyiHlLSWjYYKDyEihPI+AHO+CisLIRyG2N0e3vQbNs90 ZmGw== X-Gm-Message-State: AO0yUKXJYVyNiqCwi1hqCOmUMJpwxch+KJlm4rZN4tTlfHite4PEJxj6 TUn/lErLEVwSyic3xbfVGIE/aUkGzcE= X-Google-Smtp-Source: AK7set94YqDAGISpJ88nU9GpVOq8HahVScAJcl3isAOv812VxstdjXukBVCA+QkJjTDNRjuqp0jo+ZxoQ0w= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:1183:b0:a27:3ecc:ffe7 with SMTP id m3-20020a056902118300b00a273eccffe7mr460686ybu.3.1677102799291; Wed, 22 Feb 2023 13:53:19 -0800 (PST) Date: Wed, 22 Feb 2023 13:53:17 -0800 In-Reply-To: <62c84fa8-d7c4-5163-fe1e-f2c7e5a2c7aa@redhat.com> Mime-Version: 1.0 References: <20221202061347.1070246-1-chao.p.peng@linux.intel.com> <62c84fa8-d7c4-5163-fe1e-f2c7e5a2c7aa@redhat.com> Message-ID: Subject: Re: [PATCH v10 0/9] KVM: mm: fd-based approach for supporting KVM From: Sean Christopherson To: David Hildenbrand Cc: Mike Rapoport , Chao Peng , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Arnd Bergmann , Naoya Horiguchi , Miaohe Lin , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Shuah Khan , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , tabba@google.com, Michael Roth , mhocko@suse.com, wei.w.wang@intel.com Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 16, 2023, David Hildenbrand wrote: > On 16.02.23 06:13, Mike Rapoport wrote: > > Hi, > > > > On Fri, Dec 02, 2022 at 02:13:38PM +0800, Chao Peng wrote: > > > This patch series implements KVM guest private memory for confidential > > > computing scenarios like Intel TDX[1]. If a TDX host accesses > > > TDX-protected guest memory, machine check can happen which can further > > > crash the running host system, this is terrible for multi-tenant > > > configurations. The host accesses include those from KVM userspace like > > > QEMU. This series addresses KVM userspace induced crash by introducing > > > new mm and KVM interfaces so KVM userspace can still manage guest memory > > > via a fd-based approach, but it can never access the guest memory > > > content. > > > > Sorry for jumping late. > > > > Unless I'm missing something, hibernation will also cause an machine check > > when there is TDX-protected memory in the system. When the hibernation > > creates memory snapshot it essentially walks all physical pages and saves > > their contents, so for TDX memory this will trigger machine check, right? For hibernation specifically, I think that should be handled elsewhere as hibernation is simply incompatible with TDX, SNP, pKVM, etc. without paravirtualizing the guest, as none of those technologies support auto-export a la s390. I suspect the right approach is to disallow hibernation if KVM is running any protected guests. > I recall bringing that up in the past (also memory access due to kdump, > /prov/kcore) and was told that the main focus for now is preventing > unprivileged users from crashing the system, that is, not mapping such > memory into user space (e.g., QEMU). In the long run, we'll want to handle > such pages also properly in the other events where the kernel might access > them. Ya, unless someone strongly objects, the plan is to essentially treat "attacks" from privileged users as out of to scope for initial support, and then iterate as needed to fix/enable more features. FWIW, read accesses, e.g. kdump, should be ok for TDX and SNP as they both play nice with "bad" reads. pKVM is a different beast though as I believe any access to guest private memory will fault. But my understanding is that this series would be a big step forward for pKVM, which currently doesn't have any safeguards.