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 X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 71844C4338F for ; Thu, 19 Aug 2021 13:03:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 560D4610FA for ; Thu, 19 Aug 2021 13:03:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239630AbhHSNDe (ORCPT ); Thu, 19 Aug 2021 09:03:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51286 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239585AbhHSNDd (ORCPT ); Thu, 19 Aug 2021 09:03:33 -0400 Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 36E0BC061757 for ; Thu, 19 Aug 2021 06:02:57 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id bk29so1275669qkb.8 for ; Thu, 19 Aug 2021 06:02:57 -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=/uITF9PsXzVGX7hd3I0YUfetvnjHbmqb4UwwTMwonFI=; b=MPi0hnE/ra70VrPe/cNO1Ormx0fhJ3InR0Y4lORCcGbpHnwdkrxn1VeXvH+TSBCUTU v0oNczhQ45wov/kN+l3jtld33Kte9pDI7LQjdbpJ6VesA3zUtrn7vRlwd08l5CwfMpDU GlQPWNOam5K6Fiq2V6Tbbttqwgpactcl62UgdWtN/WPmIXzluJIqO6nt1o0a/sj/A3Kb Gxj3Qr4qTluQCE1kJnhok4GHfTTD2AXsJ1YntzkD+POopVeAhimTW2k9AryGeRJHHuhp kdJHiN3MnWJN2tX98TIbuatikanJs4miyWRTUopfWqD7Nq7cZCv8w0OJZFNZnDNw+tSN yv7g== 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=/uITF9PsXzVGX7hd3I0YUfetvnjHbmqb4UwwTMwonFI=; b=tvBmY+Rp8q7Sfvtyjx8zCVFlTFqAHwP0bQdFoc6aX+fhfgapKZc92Wo9gbGoou1y6a QlUXpEf9Wiatpre0DUGr94iuDep14L9H8XIRmTwdj4obe6K51SqnxqZ7f/EFG2klRkxT U13+XMO7XNGyfuD6woKCZlyiji6RlwypS7dn94pJeeqLfl7bnmoBi6wNHw0y5QWpHone l97WlbOqGwQr5jaB669mpnD5V5xr86JihJYxa6hIZsqrB2Zht7c9kSBVEPxmRbJ8As0Z 9jKD8n100H6lEUXZQEjgFzooh6d2vBGHG/JiMFeKhvAfQaaiE/ZY9prTOWmLjSmBEldo U0Ug== X-Gm-Message-State: AOAM532vzZjkUW23knz7iT2VBIbbOnmzIilz+eu6cokmxuUgFfdrnSAO z0JMVEXC75Kzkcmt6l7a7u/aTfbf4ay0XJiD3vmY9Q== X-Google-Smtp-Source: ABdhPJy5I18zBxQ1LGmdihiCjtGWvx+HuJJjQQGxxo70NaOSKWyTzogqPmmLqLM1CdEM2C4vIeoyMMoZ809yk2xCmpI= X-Received: by 2002:a37:dcc7:: with SMTP id v190mr3652195qki.445.1629378176061; Thu, 19 Aug 2021 06:02:56 -0700 (PDT) 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: Thu, 19 Aug 2021 14:02:44 +0100 Message-ID: Subject: Re: [PATCH 3/3] virt: Add sev_secret module to expose confidential computing secrets To: Ard Biesheuvel Cc: Dov Murik , 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: > > > The new sev_secret module exposes the confidential computing (coco) > > > secret area via securityfs interface. > > > > > > When the module is loaded (and securityfs is mounted, typically under > > > /sys/kernel/security), a "coco/sev_secret" directory is created in > > > securityfs. In it, a file is created for each secret entry. The name > > > of each such file is the GUID of the secret entry, and its content is > > > the secret data. > > > > > > This allows applications running in a confidential computing setting to > > > read secrets provided by the guest owner via a secure secret injection > > > mechanism (such as AMD SEV's LAUNCH_SECRET command). > > > > > > Removing (unlinking) files in the "coco/sev_secret" directory will zero > > > out the secret in memory, and remove the filesystem entry. If the > > > module is removed and loaded again, that secret will not appear in the > > > filesystem. > > > > We've also been looking into a similar secret mechanism recently in the > > context of Android and protected KVM [1]. Our secrets would come from a > > different source, likely described as a reserved-memory node in the DT, > > but would need to be exposed to userspace in the same way as the SEV > > secrets. Originally I tried using a character device, but this approach > > with securityfs feels neater to me. > > > > Agreed. I particularly like how deleting the file wipes the secret from memory. > > > We're also looking to pass secrets from the bootloader to Linux, outside > > of any virtualization or confidential compute context (at least a far as > > I have understood the meaning of the term). Again, this feels like it > > would be exposed to userspace in the same way. > > > > Indeed. > > > It would be good to be able to share the parts that would be common. I > > expect that would mean the operations for a secret file and for a > > directory of secrets at a minimum. But it might also influence the paths > > in securityfs; I see, looking back, that the "coco" directory was added > > since the RFC but would a generalized "secret" subsystem make sense? Or > > would it be preferable for each case to define their own path? > > > > I think we should avoid 'secret', to be honest. Even if protected KVM > is not riding the SEV/TDX wave, I think confidential computing is > still an accurate description of its semantics. I agree that protected KVM fits with the ideas of confidential computing. It was the non-virtualization context that I was less certain about. For example, the Open Profile for DICE [2] starts with a hardware secret and derives, at each boot stage, a secret that is passed to the next stage. It's a process that applies both to a VM, matching confidential compute as I understand it, but also the host Linux, which is the part that I wasn't so clear on. [2] -- https://pigweed.googlesource.com/open-dice/+/refs/heads/main/docs/specification.md > > [1] -- https://lwn.net/Articles/836693/ > > > > > +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. > > > > + e->guid = NULL_GUID; > > > + } > > > + > > > + inode->i_private = NULL; > > > + > > > + for (i = 0; i < SEV_SECRET_NUM_FILES; i++) > > > + if (s->fs_files[i] == dentry) > > > + s->fs_files[i] = NULL; > > > + > > > + /* > > > + * securityfs_remove tries to lock the directory's inode, but we reach > > > + * the unlink callback when it's already locked > > > + */ > > > + inode_unlock(dir); > > > + securityfs_remove(dentry); > > > + inode_lock(dir); > > > + > > > + return 0; > > > +} From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f173.google.com (mail-qk1-f173.google.com [209.85.222.173]) (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 53DDA2FAD for ; Thu, 19 Aug 2021 13:02:57 +0000 (UTC) Received: by mail-qk1-f173.google.com with SMTP id p22so6993478qki.10 for ; Thu, 19 Aug 2021 06:02:57 -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=/uITF9PsXzVGX7hd3I0YUfetvnjHbmqb4UwwTMwonFI=; b=MPi0hnE/ra70VrPe/cNO1Ormx0fhJ3InR0Y4lORCcGbpHnwdkrxn1VeXvH+TSBCUTU v0oNczhQ45wov/kN+l3jtld33Kte9pDI7LQjdbpJ6VesA3zUtrn7vRlwd08l5CwfMpDU GlQPWNOam5K6Fiq2V6Tbbttqwgpactcl62UgdWtN/WPmIXzluJIqO6nt1o0a/sj/A3Kb Gxj3Qr4qTluQCE1kJnhok4GHfTTD2AXsJ1YntzkD+POopVeAhimTW2k9AryGeRJHHuhp kdJHiN3MnWJN2tX98TIbuatikanJs4miyWRTUopfWqD7Nq7cZCv8w0OJZFNZnDNw+tSN yv7g== 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=/uITF9PsXzVGX7hd3I0YUfetvnjHbmqb4UwwTMwonFI=; b=aQ3BrEBzzSP/i+t4efj6FjhmMhjW8CqwBlBKZ+9cLLgi3JYWWEx20c25YaUngBB8YA 8Jwx45ymMNEsHugjOiWucKMZK3lpzFyCDOVvhK92HE2zPurVICwuhT02yGAx9MDTVUed YVA8+tsXzUJznGM6wzRIkwd5ySI8V9jZkx7mRFXvlxC1DsoSWYG/fFUEnOWXLI8LbHl+ NRvOMEW5RSF+x7l7psHx8RoUYOr+VZyWrHphkj5I+ruoBTPB9XdR9dLNGRO7ZwLGPzuG FgK9465CsRrBwMCeFu/CGB2+4KjhewaEahVKWdv0NBlXKk83WbwLNmrgZBI9cOpBtHaJ O5NA== X-Gm-Message-State: AOAM532VD19gR+1O+VjUEMmrVevjzWJ+YTiOkP52t3L9y7q0dd4Aj/Qf +zQVCQV/seFJR9yiAiXaZQIDY73f/3A0cceoybK2aw== X-Google-Smtp-Source: ABdhPJy5I18zBxQ1LGmdihiCjtGWvx+HuJJjQQGxxo70NaOSKWyTzogqPmmLqLM1CdEM2C4vIeoyMMoZ809yk2xCmpI= X-Received: by 2002:a37:dcc7:: with SMTP id v190mr3652195qki.445.1629378176061; Thu, 19 Aug 2021 06:02:56 -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: Thu, 19 Aug 2021 14:02:44 +0100 Message-ID: Subject: Re: [PATCH 3/3] virt: Add sev_secret module to expose confidential computing secrets To: Ard Biesheuvel Cc: Dov Murik , 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 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: > > > The new sev_secret module exposes the confidential computing (coco) > > > secret area via securityfs interface. > > > > > > When the module is loaded (and securityfs is mounted, typically under > > > /sys/kernel/security), a "coco/sev_secret" directory is created in > > > securityfs. In it, a file is created for each secret entry. The name > > > of each such file is the GUID of the secret entry, and its content is > > > the secret data. > > > > > > This allows applications running in a confidential computing setting to > > > read secrets provided by the guest owner via a secure secret injection > > > mechanism (such as AMD SEV's LAUNCH_SECRET command). > > > > > > Removing (unlinking) files in the "coco/sev_secret" directory will zero > > > out the secret in memory, and remove the filesystem entry. If the > > > module is removed and loaded again, that secret will not appear in the > > > filesystem. > > > > We've also been looking into a similar secret mechanism recently in the > > context of Android and protected KVM [1]. Our secrets would come from a > > different source, likely described as a reserved-memory node in the DT, > > but would need to be exposed to userspace in the same way as the SEV > > secrets. Originally I tried using a character device, but this approach > > with securityfs feels neater to me. > > > > Agreed. I particularly like how deleting the file wipes the secret from memory. > > > We're also looking to pass secrets from the bootloader to Linux, outside > > of any virtualization or confidential compute context (at least a far as > > I have understood the meaning of the term). Again, this feels like it > > would be exposed to userspace in the same way. > > > > Indeed. > > > It would be good to be able to share the parts that would be common. I > > expect that would mean the operations for a secret file and for a > > directory of secrets at a minimum. But it might also influence the paths > > in securityfs; I see, looking back, that the "coco" directory was added > > since the RFC but would a generalized "secret" subsystem make sense? Or > > would it be preferable for each case to define their own path? > > > > I think we should avoid 'secret', to be honest. Even if protected KVM > is not riding the SEV/TDX wave, I think confidential computing is > still an accurate description of its semantics. I agree that protected KVM fits with the ideas of confidential computing. It was the non-virtualization context that I was less certain about. For example, the Open Profile for DICE [2] starts with a hardware secret and derives, at each boot stage, a secret that is passed to the next stage. It's a process that applies both to a VM, matching confidential compute as I understand it, but also the host Linux, which is the part that I wasn't so clear on. [2] -- https://pigweed.googlesource.com/open-dice/+/refs/heads/main/docs/specification.md > > [1] -- https://lwn.net/Articles/836693/ > > > > > +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. > > > > + e->guid = NULL_GUID; > > > + } > > > + > > > + inode->i_private = NULL; > > > + > > > + for (i = 0; i < SEV_SECRET_NUM_FILES; i++) > > > + if (s->fs_files[i] == dentry) > > > + s->fs_files[i] = NULL; > > > + > > > + /* > > > + * securityfs_remove tries to lock the directory's inode, but we reach > > > + * the unlink callback when it's already locked > > > + */ > > > + inode_unlock(dir); > > > + securityfs_remove(dentry); > > > + inode_lock(dir); > > > + > > > + return 0; > > > +}