[PATCH v3 1/1] fastboot: introduce 'oem board' subcommand

[Quentin Schulz]

Hi Alexey,

On 4/8/24 12:15, Alexey Romanov wrote:
> Currently, fastboot protocol in U-Boot has no opportunity
> to execute vendor custom code with verifed boot. This patch
> introduce new fastboot subcommand fastboot oem board:<cmd>,
> which allow to run custom oem_board function.
> 
> Default implementation is __weak. Vendor must redefine it in
> board/ folder with his own logic.
> 
> For example, some vendors have their custom nand/emmc partition
> flashing or erasing. Here some typical command for such use cases:
> 
> - flashing:
> 
>    $ fastboot stage bootloader.img
>    $ fastboot oem board:write_bootloader
> 
> - erasing:
> 
>    $ fastboot oem board:erase_env
> 
> Signed-off-by: Alexey Romanov <avromanov at salutedevices.com>
> ---
>   doc/android/fastboot.rst      | 18 ++++++++++++++++++
>   drivers/fastboot/Kconfig      |  7 +++++++
>   drivers/fastboot/fb_command.c | 30 ++++++++++++++++++++++++++++++
>   include/fastboot.h            |  1 +
>   4 files changed, 56 insertions(+)
> 
> diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst
> index 05d8f77759..2020590657 100644
> --- a/doc/android/fastboot.rst
> +++ b/doc/android/fastboot.rst
> @@ -30,6 +30,7 @@ The following OEM commands are supported (if enabled):
>   - ``oem bootbus``  - this executes ``mmc bootbus %x %s`` to configure eMMC
>   - ``oem run`` - this executes an arbitrary U-Boot command
>   - ``oem console`` - this dumps U-Boot console record buffer
> +- ``oem board`` - this executes an custom board function which is defined by vendor

s/an/a/

+the vendor? (missing "the")

>   
>   Support for both eMMC and NAND devices is included.
>   
> @@ -246,6 +247,23 @@ including multiple commands (using e.g. ``;`` or ``&&``) and control structures
>   (``if``, ``while``, etc.). The exit code of ``fastboot`` will reflect the exit
>   code of the command you ran.
>   
> +Running Custom Vendor Code
> +^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +U-Boot allows you to execute custom fastboot logic, which can be defined
> +in board/ files. It can still be used for production devices with verified
> +boot, because vendor define logic at compile time by overriding weak

s/vendor define/the vendor defines/

Suggestion:

Replace "by overriding weak implementation of fastboot_oem_board()" with 
"by implementing fastboot_oem_board()", the weak symbol is an 
implementation detail I don't think we need to keep in the documentation?

> +implementation of fastboot_oem_board() function. The attacker will
> +not able to execute his commands / code. For example, this can be useful

+be able (missing be)

s/his/custom/ or s/his/their/

> +for custom flashing or erasing protocols::
> +
> +    $ fastboot stage bootloader.img
> +    $ fastboot oem board:write_bootloader
> +
> +In this case, ``cmd_parameter`` argument of the function ``fastboot_oem_board()``
> +will contain string "write_bootloader" and ``data`` argument is a pointer to
> +fastboot input buffer, which containing the contents of bootloader.img file.
> +

Either

-which (remove "which")

s/which containing/which contains/

Cheers,
Quentin