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 A6BE3CDB474 for ; Tue, 17 Oct 2023 16:27:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4048980041; Tue, 17 Oct 2023 12:27:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 38CF78003F; Tue, 17 Oct 2023 12:27:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 22DDD80041; Tue, 17 Oct 2023 12:27:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 0CE128003F for ; Tue, 17 Oct 2023 12:27:17 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id ADC00160D77 for ; Tue, 17 Oct 2023 16:27:16 +0000 (UTC) X-FDA: 81355483272.09.62135DB Received: from mail-yw1-f202.google.com (mail-yw1-f202.google.com [209.85.128.202]) by imf06.hostedemail.com (Postfix) with ESMTP id E1AD218000B for ; Tue, 17 Oct 2023 16:27:14 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=anEFm+lJ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of 34rUuZQYKCDknZVieXbjjbgZ.Xjhgdips-hhfqVXf.jmb@flex--seanjc.bounces.google.com designates 209.85.128.202 as permitted sender) smtp.mailfrom=34rUuZQYKCDknZVieXbjjbgZ.Xjhgdips-hhfqVXf.jmb@flex--seanjc.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697560034; 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=/hJkp0YS8fbA60ZiTgrrQsXxvsEIWpcMYoRPyADSAvk=; b=JKo/WgBj93IvHlYsnS38EtDrzmF0vJFcPgUTfgcDyqbWn5KJQoWxzGYaaDHEZTgLTovsxu grDPyWvGLP8O4zgr1YWANFByYBhp5kXG9FPq0ioqnqhEBe/sg7EKdZzepsB+lRGSkTFDko L1HdaJzxOgGeF7R+LgOXqSzOapZVa5Q= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=anEFm+lJ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of 34rUuZQYKCDknZVieXbjjbgZ.Xjhgdips-hhfqVXf.jmb@flex--seanjc.bounces.google.com designates 209.85.128.202 as permitted sender) smtp.mailfrom=34rUuZQYKCDknZVieXbjjbgZ.Xjhgdips-hhfqVXf.jmb@flex--seanjc.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697560034; a=rsa-sha256; cv=none; b=loyZUROpB5yVBkasnK+PhcFkuLqnULxALju9qXZwNJgZ3z8jq7muDCCPtkwqIpCz2TAtrO X9idPeYk3qjIh3As+f61wpOdyb+EJaoDSJGpVAw6iey1ICgzJ8xGpMmwWqzZHpjOM97CXC C1/JxXKgEAp0MpXtfV4PsvTUahD0ZYo= Received: by mail-yw1-f202.google.com with SMTP id 00721157ae682-5a7b9e83b70so44466537b3.0 for ; Tue, 17 Oct 2023 09:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1697560034; x=1698164834; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=/hJkp0YS8fbA60ZiTgrrQsXxvsEIWpcMYoRPyADSAvk=; b=anEFm+lJWB9rTcFp/Qtsi6Aj5mv9GIolZDacmBMLTFh9YhDpEBrWVTjaJ4sNRJyOW5 /UF1k8CvU0MForaxAKix4PW0l1RgXHM1tftkN0VbXMhlY5LCtVV6fjEkps/6H5444JCX 6fs4Seobt7NvtfXnw7iCsce6qAW6iU6ZsmIQN5UBc3iILUzeURv881QSbUb4AwPKe1ZV yqJySqONT0ihMk4k2Kf2V2QHPyjZor+lRK4g4QesGgEUEYzd9J9MKll9Vv9qiUt5gFCf mObvdt/Wx5PziezFIeG2DdRPJdYSVInW4PvdTSBjzyIGScJmTBiMHs8oOAXBJwyWnAPC Zn5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697560034; x=1698164834; 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=/hJkp0YS8fbA60ZiTgrrQsXxvsEIWpcMYoRPyADSAvk=; b=t6p1x5x4mhJQHmhRS2nVD6bonulqvIKpfYJK306D4rJUd8BBZKfLneL137MpcgANXA sLvMk9ikSdUB4JKhZ8QwnL2qVa4aQ6FJpwz5tNr2Qo/rweyQ8b8ejYckM9hFpVIVfJyG cMFhUh8U4IrH9MD9ppcq9MZaUcQh3GK4qUCwQWc4YwhidO+pIvhpIDYs+13Q6KGaTym3 kyZEiHJtJ99rL8FtN/uwYHLrB1y0ny/fe2gVgZnq9D8GuzXPYpTWmHPOwKPToQUSvr72 XFCu62M4NAcYfhDLN+VWlUWA7n3TzkgSezkvK1uirHcxn1p8rKUffh5XYQXX30rBpsbI WW+Q== X-Gm-Message-State: AOJu0YyjXAjH0FGdnZKZp/+ZMIqNM/mjrwI8TKo50K+fK1XWPGwXQVYG crOKyZNEDT5qgyFslOzwnpct/5j6pfk= X-Google-Smtp-Source: AGHT+IHTqfMaDOaUACBBNjywMbrRhxv3au8SZnqO5B/WdcHe7acDDk0Hy7ETXXqWEiO/SZnVQovTmDtZn3c= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:690c:88a:b0:5a7:b87d:9825 with SMTP id cd10-20020a05690c088a00b005a7b87d9825mr74938ywb.5.1697560034031; Tue, 17 Oct 2023 09:27:14 -0700 (PDT) Date: Tue, 17 Oct 2023 09:27:12 -0700 In-Reply-To: Mime-Version: 1.0 References: <20231016132819.1002933-1-michael.roth@amd.com> <20231016132819.1002933-49-michael.roth@amd.com> Message-ID: Subject: Re: [PATCH v10 48/50] KVM: SEV: Provide support for SNP_GUEST_REQUEST NAE event From: Sean Christopherson To: Dionna Amalie Glaze Cc: Michael Roth , kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, jroedel@suse.de, thomas.lendacky@amd.com, hpa@zytor.com, ardb@kernel.org, pbonzini@redhat.com, vkuznets@redhat.com, jmattson@google.com, luto@kernel.org, dave.hansen@linux.intel.com, slp@redhat.com, pgonda@google.com, peterz@infradead.org, srinivas.pandruvada@linux.intel.com, rientjes@google.com, dovmurik@linux.ibm.com, tobin@ibm.com, bp@alien8.de, vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com, jarkko@kernel.org, ashish.kalra@amd.com, nikunj.dadhania@amd.com, pankaj.gupta@amd.com, liam.merwick@oracle.com, zhi.a.wang@intel.com, Brijesh Singh , Alexey Kardashevskiy Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: E1AD218000B X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: i1upzhf37b7wkcmzjyynde17mb3e5rc6 X-HE-Tag: 1697560034-602356 X-HE-Meta: U2FsdGVkX1+ZEzudfdF5uMel4U+AME7RfjVIhyYrIZ7PZ2SjI6HTjKwCoYRhAKdZfwG6JqkOPbd6BcI0TS+GXbtWBh0Dz1Es9N/lS9TW+cGLdZr3S0VozNUxKCVcvYZSHILdIZzzhBA6fdAcDYb+5YJH3r+xWcfNET5f7TP2g4cycuw0M/5RVIaaDn7gcCXctrhxHAWgHqd6zRc6L4zB1rHWl0k95l4XIY7+MpuFO44lUxAVyV4Fv2ZIKcSi7Xj7jKCtrpWMef/EpacPjSN99WYntcd2k6V07HlPXj6yjm4z/Gv6PDJl+I41XO7x9cLBMhFeOr8xY//y7CS7nzkkW008JMWDIF7weTqwwc/4k+vD9rFIRfd6UXWx775J3uy9hbc+cl7H8oM8JQGOaRVOGqVrDXYsXzgF7YbaCOgp+U7QNrqfx7bDmvqra8WU0X45KH61y25t+WuGU0DoDcyxLf1PoFHCALDXKowCzMNxb6wg9UbceR20PUgC7Psyq+mXwSbL+Ysjmo0Bm1elhWg7F4OxXTGYXH8O2Rrddsy/x6wcKYl49wa1b+yg0jLeMWT/ofq/1SvVGsRCF6e9ig3b4qwaW9ff2zpFzZ7VjhNG5SvLxud3/UHWQToL5LGnUmihV09ipF8lA8WT47YQAThxqJFBMLWS5FaM8wos6BB4o5iD/I1K2ir0QHXCXRgWWHOUy3tEXoWqez4VNNgZFnjDkOYU09UI95D9gfCOb4gaQN8HLxTFdvIItkHVsBf83NG28Efb/4c/QxFIY6Glac8V5zr/Hf2GDLm7vEH715jFNR1YUsKn3jveCY4ILo+qMlWwysvsrNHQh/N6IzDIHUWAV1671+W/l5j1/r7e9yWDExluGD86Xmd/JWAS7dOd/PHF82oQo8MeJbPve29jCNCMAY2Rgl2B9uawZZQXNVzpow5an3ub7RtnaNke/n2X3Y5J6raiMq1ouf5mCl+4tpB FvWUrHk+ JtMeJDwLTQMuK8+10gWuEXxiea4HNPTWzLiu5HWmkZM44Y3fFlyr8mF+ABkgMul4y7v178NMHbpH+j6eNCUEm+9bBTwGde3g3a+dOtyC0Ah0BH2tzLk5KjiUS51ghBMGSruUObNdJFWSgEH/BcfUto4v7zwt7oN+VcHwkgiX3ODSc3fvReJgeW3IyWBgtigjNKR8a74lbbP08i3hydkWwoXfFFbfl+LB56wuDRLkDg5lFz5k4c/XmLTyZL+hmqoj1b1d2dHJ6jx/2tx10YMGldXS+ir2ExExGqJ960oeVI66vOVIJvpznVkdUcigja/p5UQ1EaRexXYz0OMQVvu1RSDwAair+q8irG0C70odfLXhUdaPJE4Rej7dtUOcpSQLNpbn2s+/dAQPTfyNlTwUQFAFpcPLIW/okR5kITd1W232TBWGQr0/yxCOdsrFvUQuljNGpnpmhyGYpQGNoJojS9SCIhlCXBk7IUe5c7egFm9TnhoP28JTO9NIzafVEoTlwWWVm50wjRnl6lRN6PG1Pu7NWyhUB5i3dZIvSCwUfoW9xFRz3175d5UHHF+uVHmYraq5zR0tRDODuQXs31Qxb2RriAoFZEycBojX+InYGnEc9FKS/XBu7hHe1Kiz6Cmupal+D X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Oct 16, 2023, Dionna Amalie Glaze wrote: > > + > > + /* > > + * If a VMM-specific certificate blob hasn't been provided, grab the > > + * host-wide one. > > + */ > > + snp_certs = sev_snp_certs_get(sev->snp_certs); > > + if (!snp_certs) > > + snp_certs = sev_snp_global_certs_get(); > > + > > This is where the generation I suggested adding would get checked. If > the instance certs' generation is not the global generation, then I > think we need a way to return to the VMM to make that right before > continuing to provide outdated certificates. > This might be an unreasonable request, but the fact that the certs and > reported_tcb can be set while a VM is running makes this an issue. Before we get that far, the changelogs need to explain why the kernel is storing userspace blobs in the first place. The whole thing is a bit of a mess. sev_snp_global_certs_get() has data races that could lead to variations of TOCTOU bugs: sev_ioctl_snp_set_config() can overwrite psp_master->sev_data->snp_certs while sev_snp_global_certs_get() is running. If the compiler reloads snp_certs between bumping the refcount and grabbing the pointer, KVM will end up leaking a refcount and consuming a pointer without a refcount. if (!kref_get_unless_zero(&certs->kref)) return NULL; return certs; If allocating memory for the certs fails, the kernel will have set the config but not store the corresponding certs. ret = __sev_do_cmd_locked(SEV_CMD_SNP_CONFIG, &config, &argp->error); if (ret) goto e_free; memcpy(&sev->snp_config, &config, sizeof(config)); } /* * If the new certs are passed then cache it else free the old certs. */ if (input.certs_len) { snp_certs = sev_snp_certs_new(certs, input.certs_len); if (!snp_certs) { ret = -ENOMEM; goto e_free; } } Reasoning about ordering is also difficult, e.g. what is KVM's contract with userspace in terms of recognizing new global certs? I don't understand why the kernel needs to manage the certs. AFAICT the so called global certs aren't an input to SEV_CMD_SNP_CONFIG, i.e. SNP_SET_EXT_CONFIG is purely a software defined thing. The easiest solution I can think of is to have KVM provide a chunk of memory in kvm_sev_info for SNP guests that userspace can mmap(), a la vcpu->run. struct sev_snp_certs { u8 data[KVM_MAX_SEV_SNP_CERT_SIZE]; u32 size; u8 pad[]; }; When the guest requests the certs, KVM does something like: certs_size = READ_ONCE(sev->snp_certs->size); if (certs_size > sizeof(sev->snp_certs->data) || !IS_ALIGNED(certs_size, PAGE_SIZE)) certs_size = 0; if (certs_size && (data_npages << PAGE_SHIFT) < certs_size) { vcpu->arch.regs[VCPU_REGS_RBX] = certs_size >> PAGE_SHIFT; exitcode = SNP_GUEST_VMM_ERR(SNP_GUEST_VMM_ERR_INVALID_LEN); goto cleanup; } ... if (certs_size && kvm_write_guest(kvm, data_gpa, sev->snp_certs->data, certs_size)) exitcode = SEV_RET_INVALID_ADDRESS; If userspace wants to provide garbage to the guest, so be it, not KVM's problem. That way, whether the VM gets the global cert or a per-VM cert is purely a userspace concern. If userspace needs to *stall* cert requests, e.g. while the certs are being updated, then that's a different issue entirely. If the GHCB allows telling the guest to retry the request, then it should be trivially easy to solve, e.g. add a flag in sev_snp_certs. If KVM must "immediately" handle the request, then we'll need more elaborate uAPI.