From mboxrd@z Thu Jan 1 00:00:00 1970 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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 38670C77B72 for ; Thu, 20 Apr 2023 15:17:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5568E900004; Thu, 20 Apr 2023 11:17:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 50661900002; Thu, 20 Apr 2023 11:17:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3CE0D900004; Thu, 20 Apr 2023 11:17:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 2B18C900002 for ; Thu, 20 Apr 2023 11:17:35 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 02B4314038E for ; Thu, 20 Apr 2023 15:17:34 +0000 (UTC) X-FDA: 80702123670.20.970CD0D Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) by imf25.hostedemail.com (Postfix) with ESMTP id 3B2D7A0010 for ; Thu, 20 Apr 2023 15:17:32 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=0Lwk6zvT; spf=pass (imf25.hostedemail.com: domain of 3ildBZAYKCGcXJFSOHLTTLQJ.HTRQNSZc-RRPaFHP.TWL@flex--seanjc.bounces.google.com designates 209.85.214.201 as permitted sender) smtp.mailfrom=3ildBZAYKCGcXJFSOHLTTLQJ.HTRQNSZc-RRPaFHP.TWL@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682003852; h=from:from:sender: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:dkim-signature; bh=0Fvh5Bs16xnW1weT2SPid3PSg+u8/Q14PbTNxokyuWo=; b=Odfs5wIw3INivt+NTFklM/NsVJw9lnw8z/jhZR/SOEELKiO2muoaLRqbA+E6KwRo2QVzBr HsQQcqUWlgi9Bjhs19QB2ilLwBlPI93GbjnDRMxFpYz5NRqz3R08uU7dpt4uT4SCyivzdK WnFRCcpvmP0gCgCcPN0Tnd28lxEliEU= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=0Lwk6zvT; spf=pass (imf25.hostedemail.com: domain of 3ildBZAYKCGcXJFSOHLTTLQJ.HTRQNSZc-RRPaFHP.TWL@flex--seanjc.bounces.google.com designates 209.85.214.201 as permitted sender) smtp.mailfrom=3ildBZAYKCGcXJFSOHLTTLQJ.HTRQNSZc-RRPaFHP.TWL@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682003852; a=rsa-sha256; cv=none; b=PRdAObssKcGSToNaIl+ApkRONAikp3Sd137A5tPGRbFWMczuUi77/FO2UtTgeVMpYPVaEq h0YAcNskDymMX1k7EGlHshxwOoU/xuTDXNap3a2V/Y97yDka+bf1dGrVYTnocr+9wJJ1Vc 2/W5YEvGg75c3RltrdwlRjmvwlsvKPU= Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-1a682ad2f8cso7745935ad.1 for ; Thu, 20 Apr 2023 08:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1682003851; x=1684595851; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=0Fvh5Bs16xnW1weT2SPid3PSg+u8/Q14PbTNxokyuWo=; b=0Lwk6zvT1sdE3h8JzGU30U5B2GAF3IGSbkbBGobwWjNzCZvLtIOzkNc+aveiepxTAs WaAK/i7YbEhDG2NDLUpNX6THYw8haqXyojuWZ4wmeO7iGc3cq8HwF3oUxq8Ol92O1z2T hi4MCRBBTGq2u6EMEsQiLxQDCm+QEsU263UVSRUL2PE43LmOVPxu0eFMHRPbEkDg4TfT uobdLbwf2YItMZtIgpTxQ2rIfnYXNx+lpmvnNGMtHXSo0bDbtU6H888CU9MzugYu3YZg DWMBre8DaUAzW3gfyRElbNJemM8dx6YakEoK9mD3yLdn1MRKe/fRStX26QgHS1FoeyUV uNxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682003851; x=1684595851; 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=0Fvh5Bs16xnW1weT2SPid3PSg+u8/Q14PbTNxokyuWo=; b=eeGnjWNTSfmQvRYtwzgQRi8LDwSjYW81GdBdi65419e+XAuZW+NyLyFiG4LafhoHqu M5ulI8x/Ezzrf64dNWjZ5KzDfI0IfHZFHbAyTWX5s4EFWRbaIXW9i6HkQL3/2U9VQZn3 sXJbuzhqo09XxYeBm94/UVTPWPaf7C2sT+4ID9u0P94sZoANm10VeyTs/bbX6AHw/JVt 4KIW890Y0jqYNllgEyOnVWWaDpCegE6MvdONpei7QMG6EWgeh0o6LcGI6S/vc/5M9711 BzrfRNG5562Vy464DtML9RzNu6He448ZXet7mUrmaHcXGbnZXCE89wonI007uyBsQdo/ woRQ== X-Gm-Message-State: AAQBX9e/BJUGs4OrJUKF9hfqXMPJShur0BDl4bujmmNhzFGxXPq7C4oG 2mk9Dg3WfVk342+nQsiRQDgAlS5gR4Q= X-Google-Smtp-Source: AKy350ZBzilYp4PKzE37W4X5nKyyeFADvasG2SeZc5SDTlWjPiAdZDU+NJV1a/nzmUjYdsysw7dwNLoKUeU= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:903:50d:b0:1a6:3fb2:f52d with SMTP id jn13-20020a170903050d00b001a63fb2f52dmr618731plb.3.1682003850946; Thu, 20 Apr 2023 08:17:30 -0700 (PDT) Date: Thu, 20 Apr 2023 08:17:29 -0700 In-Reply-To: <20230419221716.3603068-11-atishp@rivosinc.com> Mime-Version: 1.0 References: <20230419221716.3603068-1-atishp@rivosinc.com> <20230419221716.3603068-11-atishp@rivosinc.com> Message-ID: Subject: Re: [RFC 10/48] RISC-V: KVM: Implement static memory region measurement From: Sean Christopherson To: Atish Patra Cc: linux-kernel@vger.kernel.org, Alexandre Ghiti , Andrew Jones , Andrew Morton , Anup Patel , Atish Patra , "=?iso-8859-1?Q?Bj=F6rn_T=F6pel?=" , Suzuki K Poulose , Will Deacon , Marc Zyngier , linux-coco@lists.linux.dev, Dylan Reid , abrestic@rivosinc.com, Samuel Ortiz , Christoph Hellwig , Conor Dooley , Greg Kroah-Hartman , Guo Ren , Heiko Stuebner , Jiri Slaby , kvm-riscv@lists.infradead.org, kvm@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, Mayuresh Chitale , Palmer Dabbelt , Paolo Bonzini , Paul Walmsley , Rajnesh Kanwal , Uladzislau Rezki Content-Type: text/plain; charset="us-ascii" X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 3B2D7A0010 X-Rspam-User: X-Stat-Signature: 41rha8q9qte4rhboyggutfys7nh3iu5z X-HE-Tag: 1682003852-922366 X-HE-Meta: U2FsdGVkX1/dzI1ysHDUeWHykPF2hZ39h3xXxZA+9qLihu1LToIq3MpNNe8kgEVIuO3Xy5uXvVu1KDNtU9RO7Oo7bHelvPaC1uJZVEwGA47E2SnKnwgMuim4NwjeXPsS0OPIbLDfZRthweP5p+sE4JZQ+PR0+oj1NWwQkvt+wpajGVTY4ELQM4Yo4K5/lR6Wpq/TriPwKZ2TKvGughL949158yEiHLuxLvigEF8Yn3RyRGgOv0jCfXbCruVI1t5ESFBSBVtlcYxiTsAYDrz89aaFZZRAE/4r1MYOzZRRpkG6c3jcOCCw9rXVkuoSDYFwB2JwHmirqn/Oy7PtdBTMuARn6yRNWFOmzmz5IRUBSPlBuaV9dbLknPSK4yoPDPEmJCd+Pjbi6nPJZm0y/+kbo93V4iixEKx2hR2+NCriuXhf5UtmGfmE9Vfp4QFTcnyIMmnv/UONNpl6/484r6Hw0rdpiCmrEwuzOKRg3VQjDZRevd7UuqzMyDohZBfxb4F9mSrCxe4nc67S5zuif8H16XOzNl4cZKoH7AXobKQkqjj3UVxfcm6PiBfgD7vTkYX2Y2u+aYLHffNGrPMyO2XQBIXDd2oxwzRyIbsCh+3T7RPXFDFRwlHlXkHPE6Exjn08O4JF0zOb5tOs4gVlkAtsPAVO+jNMdsTEMeOftNlI90cIk7klmQLankvwFP3N1irqUzE4tri5ftbVNY91ZMGSmaOgSfxh7O8d2vFGBbPkyCdjBGi3VqWxzpnbRf0n7dZaNgxBhuCcDt6o3ifTqtPUc2FdjwmN/aOd0rRSsMqKablQJ5XBhGx5qfbK4QCKBjdZxYYesMlioUBKq24O3RqZJTPj7W6eOtO4xM6xBSumn+AyHGYhnr1tUu3FCu7rW4BaNoom+Obh7pV+ex8+tsHa2f4DTTWtFDEKjZ+wBNYQZ3QE+eB/O/QGHoUAX6AWbupFOT7v9cCf2EZSd1tcUqa hLA/P9qc 4G6lq6zUtavfGf8bh9WaxgQoots16jF5esARt2TJTX1SGW2UmAf5QqEWrsRiwB5SpexJoQnnlEZErC9e/JJEvWhit0n9x4tQ8Us1lUX9K/3yLbkQASLje1iUvJ8aQmhlNBtOOgx5F7qoCQctWiAiVnwPIiu7/VwczdfVNmDiGvkNq07SadesH0Cw2Fy5ixy+s7//UIyX3Yz5HrebrNpRSsTU83tTmXnKvKjUHRmsLUILb1uGOcpmVAsuFkVub4gEy/ellKtY/TCw7b3ERSNJxFul5wUDA0NLzznv7Z0RusIS0w3nkqGol5f6R5XQXO7mBqWuPVJS72N+K99BIwqWMbiLJMRZtF/7sQouNvN12wM/xdA7kDFK1KFwIk26blUFFsmec5dVRf5+f4dVqM/jUC6ngsrzXtRfA5SbBjSJCFo4sF3xB27b4IYL1eFyQDlMlb9V3ouDpYvhDwiKx6IuvNsYfmVu5b1NQpNnzmVRVMMt/T9YEr8hpxvsDEy/Ty7WQyenJbmGPTbvKNmEGc8bQfvg9ai/Oq0WCtxOPz+eF9O5uQHgMdk4i93uHQpKMPGav/8jS4txApXlAkhlCMmPhJNsAQSSghMx+5S0m X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Apr 19, 2023, Atish Patra wrote: > +int kvm_riscv_cove_vm_measure_pages(struct kvm *kvm, struct kvm_riscv_cove_measure_region *mr) > +{ > + struct kvm_cove_tvm_context *tvmc = kvm->arch.tvmc; > + int rc = 0, idx, num_pages; > + struct kvm_riscv_cove_mem_region *conf; > + struct page *pinned_page, *conf_page; > + struct kvm_riscv_cove_page *cpage; > + > + if (!tvmc) > + return -EFAULT; > + > + if (tvmc->finalized_done) { > + kvm_err("measured_mr pages can not be added after finalize\n"); > + return -EINVAL; > + } > + > + num_pages = bytes_to_pages(mr->size); > + conf = &tvmc->confidential_region; > + > + if (!IS_ALIGNED(mr->userspace_addr, PAGE_SIZE) || > + !IS_ALIGNED(mr->gpa, PAGE_SIZE) || !mr->size || > + !cove_is_within_region(conf->gpa, conf->npages << PAGE_SHIFT, mr->gpa, mr->size)) > + return -EINVAL; > + > + idx = srcu_read_lock(&kvm->srcu); > + > + /*TODO: Iterate one page at a time as pinning multiple pages fail with unmapped panic > + * with a virtual address range belonging to vmalloc region for some reason. I've no idea what code you had, but I suspect the fact that vmalloc'd memory isn't guaranteed to be physically contiguous is relevant to the panic. > + */ > + while (num_pages) { > + if (signal_pending(current)) { > + rc = -ERESTARTSYS; > + break; > + } > + > + if (need_resched()) > + cond_resched(); > + > + rc = get_user_pages_fast(mr->userspace_addr, 1, 0, &pinned_page); > + if (rc < 0) { > + kvm_err("Pinning the userpsace addr %lx failed\n", mr->userspace_addr); > + break; > + } > + > + /* Enough pages are not available to be pinned */ > + if (rc != 1) { > + rc = -ENOMEM; > + break; > + } > + conf_page = alloc_page(GFP_KERNEL | __GFP_ZERO); > + if (!conf_page) { > + rc = -ENOMEM; > + break; > + } > + > + rc = cove_convert_pages(page_to_phys(conf_page), 1, true); > + if (rc) > + break; > + > + /*TODO: Support other pages sizes */ > + rc = sbi_covh_add_measured_pages(tvmc->tvm_guest_id, page_to_phys(pinned_page), > + page_to_phys(conf_page), SBI_COVE_PAGE_4K, > + 1, mr->gpa); > + if (rc) > + break; > + > + /* Unpin the page now */ > + put_page(pinned_page); > + > + cpage = kmalloc(sizeof(*cpage), GFP_KERNEL_ACCOUNT); > + if (!cpage) { > + rc = -ENOMEM; > + break; > + } > + > + cpage->page = conf_page; > + cpage->npages = 1; > + cpage->gpa = mr->gpa; > + cpage->hva = mr->userspace_addr; Snapshotting the userspace address for the _source_ page can't possibly be useful. > + cpage->is_mapped = true; > + INIT_LIST_HEAD(&cpage->link); > + list_add(&cpage->link, &tvmc->measured_pages); > + > + mr->userspace_addr += PAGE_SIZE; > + mr->gpa += PAGE_SIZE; > + num_pages--; > + conf_page = NULL; > + > + continue; > + } > + srcu_read_unlock(&kvm->srcu, idx); > + > + if (rc < 0) { > + /* We don't to need unpin pages as it is allocated by the hypervisor itself */ This comment makes no sense. The above code is doing all of the allocation and pinning, which strongly suggests that KVM is the hypervisor. But this comment implies that KVM is not the hypervisor. And "pinned_page" is cleared unpinned in the loop after the page is added+measured, which looks to be the same model as TDX where "pinned_page" is the source and "conf_page" is gifted to the hypervisor. But on failure, e.g. when allocating "conf_page", that reference is not put. > + cove_delete_page_list(kvm, &tvmc->measured_pages, false); > + /* Free the last allocated page for which conversion/measurement failed */ > + kfree(conf_page); Assuming my guesses about how the architecture works are correct, this is broken if sbi_covh_add_measured_pages() fails. The page has already been gifted to the TSM by cove_convert_pages(), but there is no call to sbi_covh_tsm_reclaim_pages(), which I'm guessing is necesary to transition the page back to a state where it can be safely used by the host.