From: Andrew Donnellan <ajd@linux.ibm.com>
To: Michael Ellerman <mpe@ellerman.id.au>,
Russell Currey <ruscur@russell.cc>,
linuxppc-dev@lists.ozlabs.org
Cc: nayna@linux.ibm.com, gregkh@linuxfoundation.org,
gcwilson@linux.ibm.com, linux-kernel@vger.kernel.org,
zohar@linux.ibm.com
Subject: Re: [PATCH v2 7/7] powerpc/pseries: Implement secvars for dynamic secure boot
Date: Tue, 10 Jan 2023 14:59:26 +1100 [thread overview]
Message-ID: <5710fa2a1763fe82ca6ae95a1d3b4cc80be410f7.camel@linux.ibm.com> (raw)
In-Reply-To: <87zgawgcpa.fsf@mpe.ellerman.id.au>
On Fri, 2023-01-06 at 21:49 +1100, Michael Ellerman wrote:
>
> > +static int plpks_get_variable(const char *key, uint64_t key_len,
> > + u8 *data, uint64_t *data_size)
> > +{
> > + struct plpks_var var = {0};
> > + u16 ucs2_namelen;
> > + u8 *ucs2_name;
> > + int rc = 0;
> > +
> > + ucs2_namelen = get_ucs2name(key, &ucs2_name);
> > + if (!ucs2_namelen)
> > + return -ENOMEM;
> > +
> > + var.name = ucs2_name;
> > + var.namelen = ucs2_namelen;
> > + var.os = PLPKS_VAR_LINUX;
> > + rc = plpks_read_os_var(&var);
> > +
> > + if (rc)
> > + goto err;
> > +
> > + *data_size = var.datalen + sizeof(var.policy);
> > +
> > + // We can be called with data = NULL to just get the object
> > size.
> > + if (data) {
> > + memcpy(data, &var.policy, sizeof(var.policy));
> > + memcpy(data + sizeof(var.policy), var.data,
> > var.datalen);
> > + }
>
> There's a lot of allocation and copying going on. The secvar-sysfs.c
> data_read() has kzalloc'ed data, but only after already doing the
> hcall
> to get the size. Then plpks_read_os_var() does an allocation for the
> hcall and then another allocation of the exact data size. Then
> data_read()
> does another copy into the sysfs supplied buffer.
>
> So to read a single variable we do the hcall twice, and allocate/copy
> the content of the variable 4 times?
>
> - Hypervisor into "output" in plpks_read_var().
> - "output" into "var->data" in plpks_read_var().
> - "var.data" into "data" in plpks_get_variable().
> - "data" into "buf" in data_read().
>
> As long as maxobjsize is < PAGE_SIZE I think we could do the hcall
> directly into "buf". Maybe we want to avoid writing into "buf"
> directly
> in case the hcall fails or something, but the other 3 copies seem
> unnecessary.
In the general case, I don't like passing buffer pointers straight from
parameters into hcalls, since the address has to be in the linear map,
and that's a detail I'd rather hide from callers. But otherwise, yes I
think we can probably shift to having the caller allocate the buffers.
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
next prev parent reply other threads:[~2023-01-10 4:00 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-30 4:20 [PATCH v2 0/7] pseries dynamic secure boot interface using secvar Russell Currey
2022-12-30 4:20 ` [PATCH v2 1/7] powerpc/pseries: Log hcall return codes for PLPKS debug Russell Currey
2023-01-04 4:45 ` Andrew Donnellan
2022-12-30 4:20 ` [PATCH v2 2/7] powerpc/secvar: WARN_ON_ONCE() if multiple secvar ops are set Russell Currey
2023-01-04 7:10 ` Andrew Donnellan
2022-12-30 4:20 ` [PATCH v2 3/7] powerpc/secvar: Use sysfs_emit() instead of sprintf() Russell Currey
2023-01-04 7:12 ` Andrew Donnellan
2022-12-30 4:20 ` [PATCH v2 4/7] powerpc/secvar: Handle format string in the consumer Russell Currey
2023-01-04 7:31 ` Andrew Donnellan
2022-12-30 4:20 ` [PATCH v2 5/7] powerpc/secvar: Handle max object size " Russell Currey
2023-01-04 7:50 ` Andrew Donnellan
2022-12-30 4:20 ` [PATCH v2 6/7] powerpc/secvar: Extend sysfs to include config vars Russell Currey
2023-01-05 7:28 ` Andrew Donnellan
2023-01-06 6:33 ` Russell Currey
2023-01-06 4:15 ` Michael Ellerman
2023-01-06 6:35 ` Russell Currey
2022-12-30 4:20 ` [PATCH v2 7/7] powerpc/pseries: Implement secvars for dynamic secure boot Russell Currey
2023-01-05 8:15 ` Andrew Donnellan
2023-01-06 6:49 ` Russell Currey
2023-01-09 4:42 ` Andrew Donnellan
2023-01-06 10:49 ` Michael Ellerman
2023-01-09 3:33 ` Andrew Donnellan
2023-01-09 3:34 ` Russell Currey
2023-01-09 5:20 ` Andrew Donnellan
2023-01-10 1:27 ` Russell Currey
2023-01-10 3:59 ` Andrew Donnellan [this message]
2023-01-11 3:57 ` 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=5710fa2a1763fe82ca6ae95a1d3b4cc80be410f7.camel@linux.ibm.com \
--to=ajd@linux.ibm.com \
--cc=gcwilson@linux.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=nayna@linux.ibm.com \
--cc=ruscur@russell.cc \
--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).