From: Andrew Donnellan <ajd@linux.ibm.com>
To: Nicholas Piggin <npiggin@gmail.com>,
linuxppc-dev@lists.ozlabs.org, linux-integrity@vger.kernel.org
Cc: gjoyce@linux.ibm.com, erichte@linux.ibm.com,
gregkh@linuxfoundation.org, nayna@linux.ibm.com,
linux-kernel@vger.kernel.org, zohar@linux.ibm.com,
sudhakar@linux.ibm.com, ruscur@russell.cc, joel@jms.id.au,
bgray@linux.ibm.com, gcwilson@linux.ibm.com
Subject: Re: [PATCH v4 22/24] powerpc/pseries: Implement secvars for dynamic secure boot
Date: Tue, 31 Jan 2023 13:54:22 +1100 [thread overview]
Message-ID: <9f16d86e855f22823ee24e6a6236a16556425f29.camel@linux.ibm.com> (raw)
In-Reply-To: <CQ05ZDYG6KNU.1G9O3ITQDIHEM@bobo>
On Tue, 2023-01-24 at 15:17 +1000, Nicholas Piggin wrote:
> > +static const char * const plpks_var_names[] = {
> > + "PK",
> > + "KEK",
> > + "db",
> > + "dbx",
> > + "grubdb",
> > + "grubdbx",
> > + "sbat",
> > + "moduledb",
> > + "trustedcadb",
> > + NULL,
> > +};
>
> Var and key are used somewhat interchangeably? These are keys, I
> think?
> And plpks could have other vars but we're only interested in (at
> least a
> subset of) keys here if I understood right.
>
> I guess the terminology is like that throughout secvar so maybe
> nothing
> to be done.
The "key" terminology seems to come from OPAL, while on the PLPKS side
it's a bit of a mess but "var" follows the usage in existing code (the
spec refers more to "objects").
>
> > +
> > +static int plpks_get_variable(const char *key, u64 key_len, u8
> > *data,
> > + u64 *data_size)
> > +{
> > + struct plpks_var var = {0};
> > + int rc = 0;
> > +
> > + var.name = kcalloc(key_len - 1, sizeof(wchar_t),
> > GFP_KERNEL);
> > + if (!var.name)
> > + return -ENOMEM;
> > + rc = utf8s_to_utf16s(key, key_len - 1, UTF16_LITTLE_ENDIAN,
> > (wchar_t *)var.name,
> > + key_len - 1);
> > + if (rc < 0)
> > + goto err;
>
> Okay I can't work out why it's key_len - 1 rather than key_len.
The existing code in secvar-sysfs.c calls secvar_ops->get() with
key_len = strlen(name) + 1, to include the null byte, which is what
OPAL expects. For PLPKS, the variable name explicitly does not include
a trailing null byte.
I'll add a comment indicating as such, perhaps at some later point it
can be reworked.
>
> > + var.namelen = rc * 2;
> > +
> > + var.os = PLPKS_VAR_LINUX;
> > + if (data) {
> > + var.data = data;
> > + var.datalen = *data_size;
> > + }
> > + rc = plpks_read_os_var(&var);
> > +
> > + if (rc)
> > + goto err;
> > +
> > + *data_size = var.datalen;
> > +
> > +err:
> > + kfree(var.name);
> > + if (rc && rc != -ENOENT) {
> > + pr_err("Failed to read variable '%s': %d\n", key,
> > rc);
> > + // Return -EIO since userspace probably doesn't
> > care about the
> > + // specific error
> > + rc = -EIO;
> > + }
> > + return rc;
> > +}
> > +
> > +static int plpks_set_variable(const char *key, u64 key_len, u8
> > *data,
> > + u64 data_size)
> > +{
> > + struct plpks_var var = {0};
> > + int rc = 0;
> > + u64 flags;
> > +
> > + // Secure variables need to be prefixed with 8 bytes of
> > flags.
> > + // We only want to perform the write if we have at least
> > one byte of data.
> > + if (data_size <= sizeof(flags))
>
> So it's unstructured 8 byte of flags, not a u64 integer? Why not u8
> flags[8] then?
No, it's a u64 and it's passed in the hcall as a single u64.
>
> > + return -EINVAL;
> > +
> > + var.name = kcalloc(key_len - 1, sizeof(wchar_t),
> > GFP_KERNEL);
> > + if (!var.name)
> > + return -ENOMEM;
> > + rc = utf8s_to_utf16s(key, key_len - 1, UTF16_LITTLE_ENDIAN,
> > (wchar_t *)var.name,
> > + key_len - 1);
> > + if (rc < 0)
> > + goto err;
> > + var.namelen = rc * 2;
> > +
> > + memcpy(&flags, data, sizeof(flags));
> > +
> > + var.datalen = data_size - sizeof(flags);
> > + var.data = data + sizeof(flags);
> > + var.os = PLPKS_VAR_LINUX;
> > + var.policy = get_policy(key);
> > +
> > + // Unlike in the read case, the plpks error code can be
> > useful to
> > + // userspace on write, so we return it rather than just -
> > EIO
> > + rc = plpks_signed_update_var(&var, flags);
> > +
> > +err:
> > + kfree(var.name);
> > + return rc;
> > +}
> > +
> > +// PLPKS dynamic secure boot doesn't give us a format string in
> > the same way OPAL does.
> > +// Instead, report the format using the SB_VERSION variable in the
> > keystore.
> > +static ssize_t plpks_secvar_format(char *buf, size_t bufsize)
> > +{
> > + struct plpks_var var = {0};
> > + ssize_t ret;
> > +
> > + var.component = NULL;
> > + // Only the signed variables have null bytes in their
> > names, this one doesn't
> > + var.name = "SB_VERSION";
> > + var.namelen = 10;
>
> Could you make that strlen(var.name) for the benefit of those of us
> with
> missing fingers?
Will do.
>
> > + var.datalen = 1;
> > + var.data = kzalloc(1, GFP_KERNEL);
>
> This could just point to a u8 on stack I think?
Until we get VMAP_STACK and we'll have to switch back.
>
>
> > + if (!var.data)
> > + return -ENOMEM;
> > +
> > + // Unlike the other vars, SB_VERSION is owned by firmware
> > instead of the OS
> > + ret = plpks_read_fw_var(&var);
> > + if (ret) {
> > + if (ret == -ENOENT) {
> > + ret = snprintf(buf, bufsize, "ibm,plpks-sb-
> > unknown");
> > + } else {
> > + pr_err("Error %ld reading SB_VERSION from
> > firmware\n", ret);
> > + ret = -EIO;
> > + }
>
> Is there a meaningful distinction? Does anything good come of
> advertising an unknown format like this?
Our thinking was simply to distinguish between cases where the API is
otherwise working happily but for some reason simply not advertising a
version number (you might still want to try to interact with the key
store regardless) vs the case where the hypervisor is returning a real
error.
I plan to keep this as is for the next revision, but I'm happy to
change it if there's a strong objection, it could go either way.
>
> > + goto err;
> > + }
> > +
> > + // This string is made up by us - the hypervisor doesn't
> > provide us
> > + // with a format string in the way that OPAL firmware does.
> > Hypervisor
> > + // defines SB_VERSION as a "1 byte unsigned integer value".
>
> I'd put the comment about SB_VERSION at the top where you use/define
> it
> or mention it in the comment.
Will fix.
>
> > + ret = snprintf(buf, bufsize, "ibm,plpks-sb-v%hhu",
> > var.data[0]);
> > +
> > +err:
> > + kfree(var.data);
> > + return ret;
> > +}
> > +
> > +static int plpks_max_size(u64 *max_size)
> > +{
> > + // The max object size reported by the hypervisor is
> > accurate for the
> > + // object itself, but we use the first 8 bytes of data on
> > write as the
> > + // signed update flags, so the max size a user can write is
> > larger.
> > + *max_size = (u64)plpks_get_maxobjectsize() + 8;
>
> You have this 8 open coded twice (once as sizeof(u64)). You could
> make
> it a #define at the top with a brief overview of the hcall format so
> you
> don't need so much commentage for it. Although a note here that the
> objsize does not include the flags bytes is good to keep.
Will do.
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
next prev parent reply other threads:[~2023-01-31 2:55 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-20 7:42 [PATCH v4 00/24] pSeries dynamic secure boot secvar interface + platform keyring loading Andrew Donnellan
2023-01-20 7:42 ` [PATCH v4 01/24] powerpc/pseries: Fix handling of PLPKS object flushing timeout Andrew Donnellan
2023-01-20 7:42 ` [PATCH v4 02/24] powerpc/pseries: Fix alignment of PLPKS structures and buffers Andrew Donnellan
2023-01-25 13:09 ` Michael Ellerman
2023-01-26 17:19 ` Segher Boessenkool
2023-01-26 17:31 ` David Laight
2023-01-27 3:20 ` Andrew Donnellan
2023-01-27 9:05 ` David Laight
2023-01-27 11:08 ` Michael Ellerman
2023-01-27 10:52 ` Michael Ellerman
2023-01-20 7:42 ` [PATCH v4 03/24] powerpc/secvar: Use u64 in secvar_operations Andrew Donnellan
2023-01-20 7:42 ` [PATCH v4 04/24] powerpc/secvar: Warn and error if multiple secvar ops are set Andrew Donnellan
2023-01-20 7:42 ` [PATCH v4 05/24] powerpc/secvar: Use sysfs_emit() instead of sprintf() Andrew Donnellan
2023-01-20 7:42 ` [PATCH v4 06/24] powerpc/secvar: Handle format string in the consumer Andrew Donnellan
2023-01-20 7:42 ` [PATCH v4 07/24] powerpc/secvar: Handle max object size " Andrew Donnellan
2023-01-20 7:42 ` [PATCH v4 08/24] powerpc/secvar: Clean up init error messages Andrew Donnellan
2023-01-20 7:42 ` [PATCH v4 09/24] powerpc/secvar: Extend sysfs to include config vars Andrew Donnellan
2023-01-20 7:42 ` [PATCH v4 10/24] powerpc/secvar: Allow backend to populate static list of variable names Andrew Donnellan
2023-01-20 7:42 ` [PATCH v4 11/24] powerpc/secvar: Warn when PAGE_SIZE is smaller than max object size Andrew Donnellan
2023-01-20 7:42 ` [PATCH v4 12/24] powerpc/secvar: Don't print error on ENOENT when reading variables Andrew Donnellan
2023-01-20 7:42 ` [PATCH v4 13/24] powerpc/pseries: Move plpks.h to include directory Andrew Donnellan
2023-01-20 7:42 ` [PATCH v4 14/24] powerpc/pseries: Move PLPKS constants to header file Andrew Donnellan
2023-01-20 7:42 ` [PATCH v4 15/24] powerpc/pseries: Expose PLPKS config values, support additional fields Andrew Donnellan
2023-01-20 7:42 ` [PATCH v4 16/24] powerpc/pseries: Implement signed update for PLPKS objects Andrew Donnellan
2023-01-24 4:16 ` Nicholas Piggin
2023-01-30 4:43 ` Andrew Donnellan
2023-01-31 4:23 ` Russell Currey
2023-01-20 7:42 ` [PATCH v4 17/24] powerpc/pseries: Log hcall return codes for PLPKS debug Andrew Donnellan
2023-01-20 7:43 ` [PATCH v4 18/24] powerpc/pseries: Make caller pass buffer to plpks_read_var() Andrew Donnellan
2023-01-20 7:43 ` [PATCH v4 19/24] powerpc/pseries: Turn PSERIES_PLPKS into a hidden option Andrew Donnellan
2023-01-24 4:26 ` Nicholas Piggin
2023-01-20 7:43 ` [PATCH v4 20/24] powerpc/pseries: Add helpers to get PLPKS password Andrew Donnellan
2023-01-20 7:43 ` [PATCH v4 21/24] powerpc/pseries: Pass PLPKS password on kexec Andrew Donnellan
2023-01-24 4:36 ` Nicholas Piggin
2023-01-24 4:40 ` Andrew Donnellan
2023-01-25 3:59 ` Michael Ellerman
2023-01-31 2:43 ` Russell Currey
2023-01-20 7:43 ` [PATCH v4 22/24] powerpc/pseries: Implement secvars for dynamic secure boot Andrew Donnellan
2023-01-24 5:17 ` Nicholas Piggin
2023-01-31 2:54 ` Andrew Donnellan [this message]
2023-01-31 4:25 ` Andrew Donnellan
2023-01-31 8:55 ` Nicholas Piggin
2023-02-01 2:15 ` Andrew Donnellan
2023-01-20 7:43 ` [PATCH v4 23/24] integrity/powerpc: Improve error handling & reporting when loading certs Andrew Donnellan
2023-01-24 15:42 ` Mimi Zohar
2023-01-20 7:43 ` [PATCH v4 24/24] integrity/powerpc: Support loading keys from pseries secvar Andrew Donnellan
2023-01-24 5:24 ` Nicholas Piggin
2023-01-24 15:14 ` Mimi Zohar
2023-01-25 0:45 ` Andrew Donnellan
2023-01-25 2:23 ` Russell Currey
2023-01-25 2:47 ` Mimi Zohar
2023-01-31 1:03 ` Andrew Donnellan
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=9f16d86e855f22823ee24e6a6236a16556425f29.camel@linux.ibm.com \
--to=ajd@linux.ibm.com \
--cc=bgray@linux.ibm.com \
--cc=erichte@linux.ibm.com \
--cc=gcwilson@linux.ibm.com \
--cc=gjoyce@linux.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=joel@jms.id.au \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=nayna@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=ruscur@russell.cc \
--cc=sudhakar@linux.ibm.com \
--cc=zohar@linux.ibm.com \
/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;
as well as URLs for NNTP newsgroup(s).