From: Atish Kumar Patra <atishp@rivosinc.com>
To: Sean Christopherson <seanjc@google.com>
Cc: linux-kernel@vger.kernel.org, "Alexandre Ghiti" <alex@ghiti.fr>,
"Andrew Jones" <ajones@ventanamicro.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Anup Patel" <anup@brainfault.org>,
"Atish Patra" <atishp@atishpatra.org>,
"Björn Töpel" <bjorn@rivosinc.com>,
"Suzuki K Poulose" <suzuki.poulose@arm.com>,
"Will Deacon" <will@kernel.org>, "Marc Zyngier" <maz@kernel.org>,
linux-coco@lists.linux.dev, "Dylan Reid" <dylan@rivosinc.com>,
abrestic@rivosinc.com, "Samuel Ortiz" <sameo@rivosinc.com>,
"Christoph Hellwig" <hch@infradead.org>,
"Conor Dooley" <conor.dooley@microchip.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Guo Ren" <guoren@kernel.org>, "Heiko Stuebner" <heiko@sntech.de>,
"Jiri Slaby" <jirislaby@kernel.org>,
kvm-riscv@lists.infradead.org, kvm@vger.kernel.org,
linux-mm@kvack.org, linux-riscv@lists.infradead.org,
"Mayuresh Chitale" <mchitale@ventanamicro.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Rajnesh Kanwal" <rkanwal@rivosinc.com>,
"Uladzislau Rezki" <urezki@gmail.com>
Subject: Re: [RFC 10/48] RISC-V: KVM: Implement static memory region measurement
Date: Sat, 22 Apr 2023 00:20:08 +0530 [thread overview]
Message-ID: <CAHBxVyGGsvYrRpx1=ahW-5ALskAQJsgjF=9a=BMreuQov0En6Q@mail.gmail.com> (raw)
In-Reply-To: <ZEFXiXu+0XLSdRkQ@google.com>
On Thu, Apr 20, 2023 at 8:47 PM Sean Christopherson <seanjc@google.com> wrote:
>
> 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.
>
Ahh. That makes sense. Thanks.
> > + */
> > + 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.
>
Yeah. Currently, the hva in the kvm_riscv_cove_page is not used
anywhere in the code. We can remove it.
> > + 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.
>
I mean to say here the conf_page is allocated in the kernel using
alloc_page. So no pinning/unpinning is required.
It seems the comment is probably misleading & confusing at best. I
will remove it.
> 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.
>
Thanks. Will fix it.
> > + 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
Yeah. The last conf_page should be reclaimed as well if measured_pages
fail at any point in the loop.
All other allocated ones would be reclaimed as a part of cove_delete_page_list.
> 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.
next prev parent reply other threads:[~2023-04-21 18:50 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-19 22:16 [RFC 00/48] RISC-V CoVE support Atish Patra
2023-04-19 22:16 ` [RFC 01/48] mm/vmalloc: Introduce arch hooks to notify ioremap/unmap changes Atish Patra
2023-04-20 19:42 ` Lorenzo Stoakes
2023-04-20 22:01 ` Atish Kumar Patra
2023-04-19 22:16 ` [RFC 02/48] RISC-V: KVM: Improve KVM error reporting to the user space Atish Patra
2023-04-19 22:16 ` [RFC 03/48] RISC-V: KVM: Invoke aia_update with preempt disabled/irq enabled Atish Patra
2023-04-19 22:16 ` [RFC 04/48] RISC-V: KVM: Add a helper function to get pgd size Atish Patra
2023-04-19 22:16 ` [RFC 05/48] RISC-V: Add COVH SBI extensions definitions Atish Patra
2023-04-19 22:16 ` [RFC 06/48] RISC-V: KVM: Implement COVH SBI extension Atish Patra
2023-04-19 22:16 ` [RFC 07/48] RISC-V: KVM: Add a barebone CoVE implementation Atish Patra
2023-04-19 22:16 ` [RFC 08/48] RISC-V: KVM: Add UABI to support static memory region attestation Atish Patra
2023-04-19 22:16 ` [RFC 09/48] RISC-V: KVM: Add CoVE related nacl helpers Atish Patra
2023-04-19 22:16 ` [RFC 10/48] RISC-V: KVM: Implement static memory region measurement Atish Patra
2023-04-20 15:17 ` Sean Christopherson
2023-04-21 18:50 ` Atish Kumar Patra [this message]
2023-04-19 22:16 ` [RFC 11/48] RISC-V: KVM: Use the new VM IOCTL for measuring pages Atish Patra
2023-04-19 22:16 ` [RFC 12/48] RISC-V: KVM: Exit to the user space for trap redirection Atish Patra
2023-04-19 22:16 ` [RFC 13/48] RISC-V: KVM: Return early for gstage modifications Atish Patra
2023-04-19 22:16 ` [RFC 14/48] RISC-V: KVM: Skip dirty logging updates for TVM Atish Patra
2023-04-19 22:16 ` [RFC 15/48] RISC-V: KVM: Add a helper function to trigger fence ops Atish Patra
2023-04-19 22:16 ` [RFC 16/48] RISC-V: KVM: Skip most VCPU requests for TVMs Atish Patra
2023-04-19 22:16 ` [RFC 17/48] RISC-V : KVM: Skip vmid/hgatp management " Atish Patra
2023-04-19 22:16 ` [RFC 18/48] RISC-V: KVM: Skip TLB " Atish Patra
2023-04-19 22:16 ` [RFC 19/48] RISC-V: KVM: Register memory regions as confidential " Atish Patra
2023-04-19 22:16 ` [RFC 20/48] RISC-V: KVM: Add gstage mapping " Atish Patra
2023-04-19 22:16 ` [RFC 21/48] RISC-V: KVM: Handle SBI call forward from the TSM Atish Patra
2023-04-19 22:16 ` [RFC 22/48] RISC-V: KVM: Implement vcpu load/put functions for CoVE guests Atish Patra
2023-04-19 22:16 ` [RFC 23/48] RISC-V: KVM: Wireup TVM world switch Atish Patra
2023-04-19 22:16 ` [RFC 24/48] RISC-V: KVM: Update timer functionality for TVMs Atish Patra
2023-04-19 22:16 ` [RFC 25/48] RISC-V: KVM: Skip HVIP update " Atish Patra
2023-04-19 22:16 ` [RFC 26/48] RISC-V: Add COVI extension definitions Atish Patra
2023-04-19 22:16 ` [RFC 27/48] RISC-V: KVM: Implement COVI SBI extension Atish Patra
2023-04-19 22:16 ` [RFC 28/48] RISC-V: KVM: Add interrupt management functions for TVM Atish Patra
2023-04-19 22:16 ` [RFC 29/48] RISC-V: KVM: Skip AIA CSR updates for TVMs Atish Patra
2023-04-19 22:16 ` [RFC 30/48] RISC-V: KVM: Perform limited operations in hardware enable/disable Atish Patra
2023-04-19 22:16 ` [RFC 31/48] RISC-V: KVM: Indicate no support user space emulated IRQCHIP Atish Patra
2023-04-19 22:17 ` [RFC 32/48] RISC-V: KVM: Add AIA support for TVMs Atish Patra
2023-04-19 22:17 ` [RFC 33/48] RISC-V: KVM: Hookup TVM VCPU init/destroy Atish Patra
2023-04-19 22:17 ` [RFC 34/48] RISC-V: KVM: Initialize CoVE Atish Patra
2023-04-19 22:17 ` [RFC 35/48] RISC-V: KVM: Add TVM init/destroy calls Atish Patra
2023-04-19 22:17 ` [RFC 36/48] RISC-V: KVM: Read/write gprs from/to shmem in case of TVM VCPU Atish Patra
2023-04-19 22:17 ` [RFC 37/48] RISC-V: Add COVG SBI extension definitions Atish Patra
2023-04-19 22:17 ` [RFC 38/48] RISC-V: Add CoVE guest config and helper functions Atish Patra
2023-04-19 22:17 ` [RFC 39/48] RISC-V: Implement COVG SBI extension Atish Patra
2023-04-19 22:17 ` [RFC 40/48] RISC-V: COVE: Add COVH invalidate, validate, promote, demote and remove APIs Atish Patra
2023-04-19 22:17 ` [RFC 41/48] RISC-V: KVM: Add host side support to handle COVG SBI calls Atish Patra
2023-04-19 22:17 ` [RFC 42/48] RISC-V: Allow host to inject any ext interrupt id to a CoVE guest Atish Patra
2023-04-19 22:17 ` [RFC 43/48] RISC-V: Add base memory encryption functions Atish Patra
2023-04-19 22:17 ` [RFC 44/48] RISC-V: Add cc_platform_has() for RISC-V for CoVE Atish Patra
2023-04-19 22:17 ` [RFC 45/48] RISC-V: ioremap: Implement for arch specific ioremap hooks Atish Patra
2023-04-20 22:15 ` Dave Hansen
2023-04-21 19:24 ` Atish Kumar Patra
2023-04-24 13:48 ` Dave Hansen
2023-04-25 8:00 ` Atish Kumar Patra
2023-04-25 13:10 ` Dave Hansen
2023-04-26 8:02 ` Atish Kumar Patra
2023-04-26 10:30 ` Anup Patel
2023-04-26 13:55 ` Andrew Bresticker
2023-04-19 22:17 ` [RFC 46/48] riscv/virtio: Have CoVE guests enforce restricted virtio memory access Atish Patra
2023-04-19 22:17 ` [RFC 47/48] RISC-V: Add shared bounce buffer to support DBCN for CoVE Guest Atish Patra
2023-04-19 22:17 ` [RFC 48/48] drivers/hvc: sbi: Disable HVC console for TVMs Atish Patra
2023-04-19 22:58 ` [RFC 00/48] RISC-V CoVE support Atish Patra
2023-04-20 16:30 ` Sean Christopherson
2023-04-20 19:13 ` Atish Kumar Patra
2023-04-20 20:21 ` Sean Christopherson
2023-04-21 15:35 ` Michael Roth
2023-04-24 12:23 ` Christophe de Dinechin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHBxVyGGsvYrRpx1=ahW-5ALskAQJsgjF=9a=BMreuQov0En6Q@mail.gmail.com' \
--to=atishp@rivosinc.com \
--cc=abrestic@rivosinc.com \
--cc=ajones@ventanamicro.com \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=anup@brainfault.org \
--cc=atishp@atishpatra.org \
--cc=bjorn@rivosinc.com \
--cc=conor.dooley@microchip.com \
--cc=dylan@rivosinc.com \
--cc=gregkh@linuxfoundation.org \
--cc=guoren@kernel.org \
--cc=hch@infradead.org \
--cc=heiko@sntech.de \
--cc=jirislaby@kernel.org \
--cc=kvm-riscv@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=maz@kernel.org \
--cc=mchitale@ventanamicro.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=pbonzini@redhat.com \
--cc=rkanwal@rivosinc.com \
--cc=sameo@rivosinc.com \
--cc=seanjc@google.com \
--cc=suzuki.poulose@arm.com \
--cc=urezki@gmail.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox