From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2] efi_loader: implement GetNextVariableName()
Date: Thu, 17 Jan 2019 11:14:00 +0900 [thread overview]
Message-ID: <20190117021358.GO20286@linaro.org> (raw)
In-Reply-To: <f41ae90f-b2d5-7853-bfb9-86b9949a4bc6@gmx.de>
Heinrich,
Thank you for your quick review.
On Wed, Jan 16, 2019 at 07:43:47PM +0100, Heinrich Schuchardt wrote:
> On 12/14/18 10:47 AM, AKASHI Takahiro wrote:
> > The current GetNextVariableName() is a placeholder.
> > With this patch, it works well as expected.
> >
> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > ---
> > lib/efi_loader/efi_variable.c | 116 +++++++++++++++++++++++++++++++++-
> > 1 file changed, 115 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
> > index 19d9cb865f25..dac2f49aa1cc 100644
> > --- a/lib/efi_loader/efi_variable.c
> > +++ b/lib/efi_loader/efi_variable.c
> > @@ -8,6 +8,9 @@
> > #include <malloc.h>
> > #include <charset.h>
> > #include <efi_loader.h>
> > +#include <environment.h>
> > +#include <search.h>
> > +#include <uuid.h>
> >
> > #define READ_ONLY BIT(31)
> >
> > @@ -241,14 +244,125 @@ efi_status_t EFIAPI efi_get_variable(u16 *variable_name, efi_guid_t *vendor,
> > return EFI_EXIT(EFI_SUCCESS);
> > }
> >
> > +static char *efi_variables_list;
> > +static char *efi_cur_variable;
> > +
>
> Please, provide a comment describing what this function is meant to do.
I think that the function name describes itself clearly, but OK.
> Describe every parameter
>
> Clearly state set variable_name_size is in bytes (cf.
> EmuGetNextVariableName() in EDK2)
Right.
> This function duplicates some of the code in efi_get_variable. So,
> please, use it in efi_get_variable too.
Which part of code do you mean? I don't think so.
> > +static efi_status_t parse_uboot_variable(char *variable,
> > + efi_uintn_t *variable_name_size,
> > + u16 *variable_name,
> > + efi_guid_t *vendor,
> > + u32 *attribute)
> > +{
>
>
>
> > + char *guid, *name, *end, c;
> > + unsigned long name_size;
> > + u16 *p;
> > +
> > + guid = strchr(variable, '_');
> > + if (!guid)
> > + return EFI_NOT_FOUND;
> > + guid++;
> > + name = strchr(guid, '_');
> > + if (!name)
> > + return EFI_NOT_FOUND;
> > + name++;
> > + end = strchr(name, '=');
> > + if (!end)
> > + return EFI_NOT_FOUND;
> > +
> > + /* FIXME: size is in byte or u16? */
>
> It is in bytes. See comment above.
OK
> > + name_size = end - name;
> > + if (*variable_name_size < (name_size + 1)) {
> > + *variable_name_size = name_size + 1;
> > + return EFI_BUFFER_TOO_SMALL;
> > + }
> > + end++; /* point to value */
> > +
> > + p = variable_name;
> > + utf8_utf16_strncpy(&p, name, name_size);
> > + variable_name[name_size] = 0;
> > +
> > + c = *(name - 1);
> > + *(name - 1) = '\0'; /* guid need be null-terminated here */
> > + uuid_str_to_bin(guid, (unsigned char *)vendor, UUID_STR_FORMAT_GUID);
> > + *(name - 1) = c;
> > +
> > + parse_attr(end, attribute);
>
> You have to update variable_name_size.
Right.
> > +
> > + return EFI_SUCCESS;
> > +}
> > +
> > /* http://wiki.phoenix.com/wiki/index.php/EFI_RUNTIME_SERVICES#GetNextVariableName.28.29 */
>
> Please add a description of the function here like we have it in
> efi_bootefi.c
OK, but not for efi_get/set_variable() as I didn't touch anything there.
> > efi_status_t EFIAPI efi_get_next_variable_name(efi_uintn_t *variable_name_size,
> > u16 *variable_name,
> > efi_guid_t *vendor)
> > {
> > + char *native_name, *variable;
> > + ssize_t name_len, list_len;
> > + char regex[256];
> > + char * const regexlist[] = {regex};
> > + u32 attribute;
> > + int i;
> > + efi_status_t ret;
> > +
> > EFI_ENTRY("%p \"%ls\" %pUl", variable_name_size, variable_name, vendor);
> >
> > - return EFI_EXIT(EFI_DEVICE_ERROR);
> > + if (!variable_name_size || !variable_name || !vendor)
> > + EFI_EXIT(EFI_INVALID_PARAMETER);
> > +
> > + if (variable_name[0]) {
>
> This code partially duplicates code in in efi_get_variable. Please,
> carve out a common function.
Which part of code do you mean? I don't see any duplication.
> > + /* check null-terminated string */
> > + for (i = 0; i < *variable_name_size; i++)
> > + if (!variable_name[i])
> > + break;
> > + if (i >= *variable_name_size)
> > + return EFI_EXIT(EFI_INVALID_PARAMETER);
> > +
> > + /* search for the last-returned variable */
> > + ret = efi_to_native(&native_name, variable_name, vendor);
> > + if (ret)
> > + return EFI_EXIT(ret);
> > +
> > + name_len = strlen(native_name);
> > + for (variable = efi_variables_list; variable && *variable;) {
> > + if (!strncmp(variable, native_name, name_len) &&
> > + variable[name_len] == '=')
> > + break;
> > +
>
> You miss to compare the GUID.
No, "native_name" already contains a given guid.
> Consider the case that the GUID changes between two calls.
UEFI specification, section 8.2, clearly describes;
When VariableName is a pointer to a Null character, VendorGuid is ignored.
etNextVariableName() cannot be used as a filter to return variable names
with a specific GUID. Instead, the entire list of variables must be
retrieved, and the caller may act as a filter if it chooses.
> > + variable = strchr(variable, '\n');
> > + if (variable)
> > + variable++;
> > + }
> > +
> > + free(native_name);
> > + if (!(variable && *variable))
>
> With less parentheses I can read the logic more easily:
>
> if (!variable || !*variable)
>
> But that is just a question of taste.
Well, this "if" clause corresponds with a termination condition of
the previous "for" clause and checks whether a for loop has been exhausted.
So my expression would be better IMO.
> Please, consider the case that the variable is not on the list because
> the variable has already been deleted.
ditto
>
> > + return EFI_EXIT(EFI_INVALID_PARAMETER);
> > +
> > + /* next variable */
> > + variable = strchr(variable, '\n');
> > + if (variable)
> > + variable++;
> > + if (!(variable && *variable))
> > + return EFI_EXIT(EFI_NOT_FOUND);
> > + } else {
> > + /* new search */
>
> Please, put a comment here explaining that the list of the preceding
> search is freed here.
OK
> > + free(efi_variables_list);
> > + efi_variables_list = NULL;
> > + efi_cur_variable = NULL;
> > +
> > + snprintf(regex, 256, "efi_.*-.*-.*-.*-.*_.*");
> > + list_len = hexport_r(&env_htab, '\n',
> > + H_MATCH_REGEX | H_MATCH_KEY,
> > + &efi_variables_list, 0, 1, regexlist);
> > + if (list_len <= 0)
> > + return EFI_EXIT(EFI_NOT_FOUND);
>
> You miss to compare the vendor GUIDs.
No. Please see UEFI specification quoted above.
Thanks,
-Takahiro Akashi
> Please, assume that variables are deleted or inserted while the caller
> loops over the variables.
> > +
> > + variable = efi_variables_list;
> > + }
> > +
> > + ret = parse_uboot_variable(variable, variable_name_size, variable_name,
> > + vendor, &attribute);
> > +
> > + return EFI_EXIT(ret);
> > }
> >
> > /* http://wiki.phoenix.com/wiki/index.php/EFI_RUNTIME_SERVICES#SetVariable.28.29 */
> >
>
> Thanks a lot for filling this gap in our EFI implementation.
>
> Best regards
>
> Heinrich
next prev parent reply other threads:[~2019-01-17 2:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-14 9:47 [U-Boot] [PATCH 1/2] efi_loader: implement GetNextVariableName() AKASHI Takahiro
2018-12-14 9:47 ` [U-Boot] [PATCH 2/2] efi_selftest: fix variables test for GetNextVariableName() AKASHI Takahiro
2019-01-16 17:54 ` Heinrich Schuchardt
2019-01-16 7:08 ` [U-Boot] [PATCH 1/2] efi_loader: implement GetNextVariableName() AKASHI Takahiro
2019-01-16 18:43 ` Heinrich Schuchardt
2019-01-17 2:14 ` AKASHI Takahiro [this message]
2019-01-17 7:09 ` Heinrich Schuchardt
2019-01-17 8:15 ` AKASHI Takahiro
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=20190117021358.GO20286@linaro.org \
--to=takahiro.akashi@linaro.org \
--cc=u-boot@lists.denx.de \
/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