From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com [209.85.219.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D8E353FC0 for ; Mon, 23 Aug 2021 19:22:11 +0000 (UTC) Received: by mail-qv1-f43.google.com with SMTP id jz1so10330608qvb.13 for ; Mon, 23 Aug 2021 12:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T6iKivFntL9jO7A0bCG8XT9/kFuKhYKYNxAQLHLMCA8=; b=BSRfZn3mjcrNmw8pFTD0zSn1xAXWxcKMU9J2TF+jD2LkWw9I7AhfhljTQwfgv51OLf mE/H3lpQQMB55BLYil6FkPi+0QlqRcAbP2GaIJFgcDsEvfHQE0nlkGDRpvRvr3qSYXp9 i0NnD/y0GbccrRSpP11Icq9wQ2gr/o0otdPKnjS8aYOI681yCT0GilYqs4683pADtHDn jM0Ir2gvmWRo7/awhQZYFYC69CaNV02Evw6mk74Tiik+azOAb1lI5u4Chuycy89p0RWO +rG2TqaSvk6TOtF9TPpgsCHa+YPl2YT29z3zUFDSNayYtOk3VdaquRQcmR37SY8L1Agp 6q9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T6iKivFntL9jO7A0bCG8XT9/kFuKhYKYNxAQLHLMCA8=; b=YsOATi/obmWn5Hsl7dLZdiE7apk3aL8TJ9fUgZqQe1yPROfdW7hd4B0gzWOGWBmME3 rFEtvm0p0yU3wl+R7weMzuVdczVhT4gHC+2Lfc5FPmltQsJ1InM0FLLykQycui2n1iaW MunN2FzA1SEtXAx/VEswwdbu5T8j6TU9NDCvT6JHBro3NS3FkrSoDxvuIvlcjb+o7Dzg 88/erqCIc8j59qx1Ay35X/C04WvUvCgiQ7UT41gh/H4A2l/D6WkDvYfAQOqMbJfe5oXP lXXo9NDDLrpmaMqz3f3ngfxXqTZs7nOdwOcG9XO0dpvr5falTKF4n/VLc9ByvxR5BPhZ kvJQ== X-Gm-Message-State: AOAM533Wm3XvhFIaf7ZyWNWIQQR7VsJiITdHvGpuvA1pYIN5KMpchpaC dHAqA7EF8Q23xXQ37+08ZkMcFn+U60qDRKFyqEL1WQ== X-Google-Smtp-Source: ABdhPJzSmsDDXrKpnjlCjqU/iSM5pI5Vk9qNwlyj24hp3zzEDN+2wjy9BTW6K99y21o6o3AvyFjVbWNT+e3EGt3wGKw= X-Received: by 2002:a05:6214:240b:: with SMTP id fv11mr33382976qvb.28.1629746530676; Mon, 23 Aug 2021 12:22:10 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20210809190157.279332-1-dovmurik@linux.ibm.com> <20210809190157.279332-4-dovmurik@linux.ibm.com> In-Reply-To: From: Andrew Scull Date: Mon, 23 Aug 2021 20:21:59 +0100 Message-ID: Subject: Re: [PATCH 3/3] virt: Add sev_secret module to expose confidential computing secrets To: Dov Murik Cc: Ard Biesheuvel , linux-efi , Borislav Petkov , Ashish Kalra , Brijesh Singh , Tom Lendacky , James Morris , "Serge E. Hallyn" , Andi Kleen , "Dr. David Alan Gilbert" , James Bottomley , Tobin Feldman-Fitzthum , Jim Cadden , linux-coco@lists.linux.dev, linux-security-module@vger.kernel.org, Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" On Fri, 20 Aug 2021 at 19:36, Dov Murik wrote: > > > > On 19/08/2021 16:02, Andrew Scull wrote: > > On Mon, 16 Aug 2021 at 10:57, Ard Biesheuvel wrote: > >> > >> On Fri, 13 Aug 2021 at 15:05, Andrew Scull wrote: > >>> > >>> On Mon, Aug 09, 2021 at 07:01:57PM +0000, Dov Murik wrote: > > [...] > > >>> > >>>> +static int sev_secret_unlink(struct inode *dir, struct dentry *dentry) > >>>> +{ > >>>> + struct sev_secret *s = sev_secret_get(); > >>>> + struct inode *inode = d_inode(dentry); > >>>> + struct secret_entry *e = (struct secret_entry *)inode->i_private; > >>>> + int i; > >>>> + > >>>> + if (e) { > >>>> + /* Zero out the secret data */ > >>>> + memzero_explicit(e->data, secret_entry_data_len(e)); > >>> > >>> Would there be a benefit in flushing these zeros? > >>> > >> > >> Do you mean cache clean+invalidate? Better to be precise here. > > > > At least a clean, to have the zeros written back to memory from the > > cache, in order to overwrite the secret. > > > > I agree, but not sure how to implement this: > > I see there's an arch_wb_cache_pmem exported function which internally > (in arch/x86/lib/usercopy_64.c) calls clean_cache_range which seems to > do what we want (assume the secret can be longer than the cache line). > > But arch_wb_cache_pmem is declared in include/linux/libnvdimm.h and > guarded with #ifdef CONFIG_ARCH_HAS_PMEM_API -- both seem not related to > what I'm trying to do. > > I see there's an exported clflush_cache_range for x86 -- but that's a > clean+flush if I understand correctly. This would be perfectly correct, the invalidation is just unnecessary. > Suggestions on how to approach? I can copy the clean_cache_range > implementation into the sev_secret module but hopefully there's a better > way to reuse. Maybe export clean_cache_range in x86? Exporting sounds much better than duplicating. It looks like the clean-only instruction was added to x86 more recently and with persistent memory as the intended application. d9dc64f30 "x86/asm: Add support for the CLWB instruction" says: "This should be used in favor of clflushopt or clflush in cases where you require the cache line to be written to memory but plan to access the data cache line to be written to memory but plan to access the data" I don't expect the secret table would be accessed with such frequency that it would actually make a difference, but if it's just a quirk of history that the clean-only version isn't exported, now seems as good a time as any to change that! > Since this is for SEV the solution can be x86-specific, but if there's a > generic way I guess it's better (I think all of sev_secret module > doesn't have x86-specific stuff). arch_wb_cache_pmem is the closest to arch agnostic I've seen, but that has it own problems :/