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 D103AC54EBD for ; Mon, 9 Jan 2023 16:55:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 51AF38E0007; Mon, 9 Jan 2023 11:55:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4A4288E0001; Mon, 9 Jan 2023 11:55:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 345048E0007; Mon, 9 Jan 2023 11:55:42 -0500 (EST) 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 1FD828E0001 for ; Mon, 9 Jan 2023 11:55:42 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E6AC5140B41 for ; Mon, 9 Jan 2023 16:55:41 +0000 (UTC) X-FDA: 80335862082.14.C86BB34 Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) by imf27.hostedemail.com (Postfix) with ESMTP id 458BF40012 for ; Mon, 9 Jan 2023 16:55:40 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=OOJuw8OW; spf=pass (imf27.hostedemail.com: domain of dionnaglaze@google.com designates 209.85.216.45 as permitted sender) smtp.mailfrom=dionnaglaze@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=1673283340; 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=81sjJWzHO6Ovjo5Gl60AAk0+/2Zuzb6zOrT24WH6r3o=; b=Wu8hXKVqVs77ZvmSDNP5MeD71DHOtNSv0JZjVh0PqbOoIXY2O2LYzhMlppoge8oPLaIDdj 8ohyjuEylOaBXbgJCpIGTRAy5K+m8LNq3RO8JZPzybYkdwWeFeQlWvbPb21EyZyub6iQYw ei4lS3tStsHtKthFMTahkYuKyz21Vxo= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=OOJuw8OW; spf=pass (imf27.hostedemail.com: domain of dionnaglaze@google.com designates 209.85.216.45 as permitted sender) smtp.mailfrom=dionnaglaze@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673283340; a=rsa-sha256; cv=none; b=3Kq44ZpltzuQsYr+8II/Wmkk68POL/bV9e06Q/TtlzkfqfyMryvGH155sX0PqNJ0lCKCvm mMUnz0mSGxdG8LYRfrACgPhJeWXO9+lb2MwySxDx0UAIRzFqWRwtPVAIaI2Qry97naDraR ZIFB13Bz0ZXYh32zuHhZeEtcBWEidUU= Received: by mail-pj1-f45.google.com with SMTP id o1-20020a17090a678100b00219cf69e5f0so13440827pjj.2 for ; Mon, 09 Jan 2023 08:55:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=81sjJWzHO6Ovjo5Gl60AAk0+/2Zuzb6zOrT24WH6r3o=; b=OOJuw8OWU9nGb+CL4TUgcpiaj0SA2J1CLUj7NLENcLFdDRo7NoHkTYncpkkO8iVYRl 74LR+OZkKxRfS5/+S70XDs2suGpDD6t9Hkh0kUhKuWlV9iwZpbsPPDe3G2gtcCd3m4nw jkzOl8rELfTy/SlBdk23Ea03QIoTSoMfnf+EXS6eQOBKw7jDv0FTj3yFjQUvJjfapk4T kf0Zy5ZqxRUUFZpsVxuA5H0Hw8apONfzLomEcmRWF/IHy93TJuSvzGiXQ8CJ/tb6x6h9 egX2evheI9vwF5TD/jWWy9FQg5kL0XyYYoEFICAoU2fjCkLhF9MUnLleCSPuBSDqBe0M DX8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=81sjJWzHO6Ovjo5Gl60AAk0+/2Zuzb6zOrT24WH6r3o=; b=oX+uWraTu9w1KT5ctS+UfLMYMoCz6gAQLgYJyoI+rIyEPrJ0FaeXWVbQK5oo353RsF CMxKf1JRwSDYNyvi1P5Rk+Ih6Q9l1q9VU5jW3oa6fTyLb8cZSFja0WyPRhVoVjau/MaP YXwAhq3KJSif4MNLgxd7rZjcfLYnUOnLyH4nOKJBuzTuO5rqACyqmFmzhIG2gYwnG9qI oV0nxXoKpP0a5qWfOTlfLB0RICm8RB+tEyJ1zkFu84F6OqiyupZRXbj2qiW75Tocw6yr BIWVqv2GAQk4BZaU/rGgiPQG1AbL3t2GuYeDSn5C/Gh3muYeYuPT8cTaZzGCnWnRWPt3 IiMQ== X-Gm-Message-State: AFqh2kq6qp/PWqZNQSR1xFzICTsXceQPfx3RgsqzeJH5DIvmpRHrZoAg MvpBlYnlig3OdP7SZKkWc0LcJDWVDdOUwrEdofdJvQ== X-Google-Smtp-Source: AMrXdXsPdoZHVqBzLP7WRcXcNC4Xd6GTdeUcwaefhv8fy9Lwb6M6BmFfgkXiH/ADLsV/yr8LRaT3J6DHlJCmHzvZGPY= X-Received: by 2002:a17:902:82cb:b0:192:a04b:c624 with SMTP id u11-20020a17090282cb00b00192a04bc624mr2581882plz.134.1673283338843; Mon, 09 Jan 2023 08:55:38 -0800 (PST) MIME-Version: 1.0 References: <20221214194056.161492-1-michael.roth@amd.com> <20221214194056.161492-63-michael.roth@amd.com> <1c02cc0d-9f0c-cf4a-b012-9932f551dd83@linux.ibm.com> In-Reply-To: <1c02cc0d-9f0c-cf4a-b012-9932f551dd83@linux.ibm.com> From: Dionna Amalie Glaze Date: Mon, 9 Jan 2023 08:55:27 -0800 Message-ID: Subject: Re: [PATCH RFC v7 62/64] x86/sev: Add KVM commands for instance certs To: Dov Murik 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, seanjc@google.com, vkuznets@redhat.com, wanpengli@tencent.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, 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, dgilbert@redhat.com, jarkko@kernel.org, ashish.kalra@amd.com, harald@profian.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 458BF40012 X-Rspam-User: X-Stat-Signature: sjynb9dugk11r3nxx5nc6koubybn5jyq X-HE-Tag: 1673283340-230861 X-HE-Meta: U2FsdGVkX195fS7FQ599ahmco+spJywsRjFkJ4uxTaBloXkLoClVs906TIcf2i9KwR7kz4DBN8r0M4k6npx86UgjizSMtqdhki0nAPPHSAAcIAB4NpajyjOjMbW6L+Zxx0eMsGM714vLd9A7kt9cSpQhbut+B3iWAlD40Rb41vVMVJFPP+UT2TcigZcvXQx7DwxyVsOntcQ7vEe7iDSR59aesR0HEoPt5GUdkUy8gWvhztapc4G9hYlhaYWzrrKos6s2Spqpryo+T12p3xxOpxstZZ5cJlCs2wl1pCRHMI26uFIKRDbMlsH6Ob1KYktMxvjufx91Ry+CryLXd/mriAcjF7XW4kZgRnu/tTHRSd7i0ysA9uqWskwAsATf8P0M+YoZBybfJVqv6tQnhkdUFfZ5AD8sPu3QDi5YICWIHUoEpGNaBTyCQWrQ9E0O1nummXSXmegzr7hqq/ufoqYTD3/ionTUN6IcbGR09Joq4TGJCvYge+3ECKsPm1OuRRVtMowNdxCmQqqKaQCDTjNUedu+eRe9WjkTT9Wt/b2hGXtH7smd12fe/P1ojVre53/hOc8xmyvsnALaofLd1kRHC40LkUSwYPdmcZfHDLKYK1+GGdMvg+yQD1fWXOvoc7aXOjx4ZgGFayjAt1dGBv4KG9PE7vAtCfOT3gwAeIDtl+wb3JOzk1fiOvStKCbkH+Jb4IuGt5vylDnFG6eSr6byCkFmlGZCXRft9JGDBWtEF1irBUFaZZrpNqwZNH0/2mSVjQ59YqbfbSXnPhTREr7iC+GpMY/GFO1IbQoWyT8El+rYXPeYVT3v/QzkiENOJ1iBSYN4rdytvN/FYuEHiI78vAoDDAl54ylFRluyKMxtVcYwA3LYf854Cn1fiiqNwzjjRuLTbYeS2SrJ49urwNaQY2iqSmEN2JmhUCAN2sgd7/bIUMYtHfZ/GS1KHaulMLp2znILwzuy5raiEtNGtca Dmg6Htq7 TYFU/HSvAjDR1EFU= 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: > > + > > +static int snp_set_instance_certs(struct kvm *kvm, struct kvm_sev_cmd *argp) > > +{ > [...] > > Here we set the length to the page-aligned value, but we copy only > params.cert_len bytes. If there are two subsequent > snp_set_instance_certs() calls where the second one has a shorter > length, we might "keep" some leftover bytes from the first call. > > Consider: > 1. snp_set_instance_certs(certs_addr point to "AAA...", certs_len=8192) > 2. snp_set_instance_certs(certs_addr point to "BBB...", certs_len=4097) > > If I understand correctly, on the second call we'll copy 4097 "BBB..." > bytes into the to_certs buffer, but length will be (4096 + PAGE_SIZE - > 1) & PAGE_MASK which will be 8192. > > Later when fetching the certs (for the extended report or in > snp_get_instance_certs()) the user will get a buffer of 8192 bytes > filled with 4097 BBBs and 4095 leftover AAAs. > > Maybe zero sev->snp_certs_data entirely before writing to it? > Yes, I agree it should be zeroed, at least if the previous length is greater than the new length. Good catch. > Related question (not only for this patch) regarding snp_certs_data > (host or per-instance): why is its size page-aligned at all? why is it > limited by 16KB or 20KB? If I understand correctly, for SNP, this buffer > is never sent to the PSP. > The buffer is meant to be copied into the guest driver following the GHCB extended guest request protocol. The data to copy back are expected to be in 4K page granularity. > [...] > > > > -#define SEV_FW_BLOB_MAX_SIZE 0x4000 /* 16KB */ > > +#define SEV_FW_BLOB_MAX_SIZE 0x5000 /* 20KB */ > > > > This has effects in drivers/crypto/ccp/sev-dev.c > (for > example in alloc_snp_host_map). Is that OK? > No, this was a mistake of mine because I was using a bloated data encoding that needed 5 pages for the GUID table plus 4 small certificates. I've since fixed that in our user space code. We shouldn't change this size and instead wait for a better size negotiation protocol between the guest and host to avoid this awkward hard-coding. -- -Dionna Glaze, PhD (she/her)