[U-Boot] interaction between CONFIG_CMD_SAVEENV and CONFIG_BOOTCOMMAND
Wolfgang Denk
wd at denx.de
Wed Sep 14 17:00:45 CEST 2016
Dear Nicolas,
In message <CAJZhe_gXm8zFhek9zZaXuV6j6CpHHFweS1FyDDGL2B+Gnb+B3Q at mail.gmail.com> you wrote:
>
> Of course, the user will be able to modify the content of the script, to
> fit with their needs. But on our side, provider of this primary bootloader,
> we want to be sure that the environment of this u-boot won't be changed by
> the user, so that we want to disable all access to "saveenv" command.
Would that really be enough? Please keep in mind that "env save" (or
"saveenv") is only responsible for storing the current environment
into persistant storage. It does not modify the environment at all.
To modify the environment, you can use quite a number of commands,
including "env set", "env import" etc. You would have to disable all
of these to prevent modifications of the environment settings - and
probably cripple U-Boot to a level where it becomes unusable.
> That's why we configure: #undef CONFIG_CMD_SAVEENV
>
> With this modifications, saveenv command is not available in the u-boot
> commands, that's nice. But bootcmd is empty. It's like there was an
> interaction between both settings, maybe the saveenv primitive is necessary
> one time to construct the environment content.
This would be a bug. Whcih exact version of U-Boot are you talking
about?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"There are three principal ways to lose money: wine, women, and en-
gineers. While the first two are more pleasant, the third is by far
the more certain." -- Baron Rothschild, ca. 1800
More information about the U-Boot
mailing list