[U-Boot] [RFC PATCH] fastboot: Implement fetching uboot env variables via fastboot getvar

[Eugeniu Rosca]

Hi Priit,

On Tue, Jul 09, 2019 at 02:52:56PM +0300, Priit Laes wrote:
> From: Priit Laes <priit.laes at paf.com>
> 
> Add u-boot specific getvar "extension" to fetch u-boot environment
> variables via `fastboot getvar uboot:var`. This makes it possible
> to gather certain data (like mac addresses) in an automated way
> during initial fastboot flashing for inventory purposes:
> 
> $ fastboot getvar uboot:ethaddr
> uboot:ethaddr: 12:23:45:56:78:90
> 
> Output is currently truncated at 64 bytes, but this is good enough
> for my own requirements.
> 
> Signed-off-by: Priit Laes <priit.laes at paf.com>
> ---
>  drivers/fastboot/fb_getvar.c | 14 ++++++++++++++

[..]

> +static void getvar_ubootenv(char *var_parameter, char *response)
> +{
> +	const char *value = env_get(var_parameter);

This would bring a lot of flexibility to the users. My only concern is
that it exposes to the outside world an internal U-Boot API (env_get)
which might have weaknesses (or might acquire them in time). I am not
sure how env_get() behaves in below corner cases:
 - NULL pointer
 - empty string
 - hugely long string

IMHO the internal APIs are usually not designed to sustain high level of
stress/fuzziness in their input parameters. Once made available to the
users of fastboot tool, this will open room for more experiments to the
CVE seekers.

Another observation is that this patch will contribute with a deviation
from the vanilla fastboot protocol (which might be fine).

Since there are already multiple getvar functions which fetch the
information from the U-Boot environment, I wonder if all of these could
be centralized in a table like below:

 {
 	/* fastboot    U-Boot */
 	{ "serialno", "serial#" },
 	{ "product",  "board" },
 	{ "platform", "platform" },
 	{ "ethaddr",  "ethaddr" },
 	{ "anything", "anything" },
 }

The upsides of this approach:
 - Unification, readability, decreased code size
The downsides:
 - Inflexible for getting arbitrary environment variables

-- 
Best Regards,
Eugeniu.