All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas le bayon <nlebayon@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] interaction between CONFIG_CMD_SAVEENV and CONFIG_BOOTCOMMAND
Date: Wed, 14 Sep 2016 18:43:01 +0200	[thread overview]
Message-ID: <CAJZhe_jhWpQLgwquHZ2U5jHL7hvkBFc=Kz0joyELDAM5vR+t7A@mail.gmail.com> (raw)
In-Reply-To: <20160914150045.44128100BA3@atlas.denx.de>

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.

>> Our objective is just to avoid the user to modify the content in the
persistent storage. Indeed, we have to retrieve the original content at
each reboot.
If the user makes something wrong in its current environment, this is its
responsability, but after the reset, we have to gat back the original
content we stored once for all. In that case, saveenv would maybe be
enough, don't you think?

Which exact version of U-Boot are you talking about?
>>  a quite old one, v2015.01 :-( And we do not plan to upgrade this
"primary bootloader" u-boot.

Regards,
Nicolas

2016-09-14 17:00 GMT+02:00 Wolfgang Denk <wd@denx.de>:

> Dear Nicolas,
>
> In message <CAJZhe_gXm8zFhek9zZaXuV6j6CpHHFweS1Fy
> DDGL2B+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
>

  reply	other threads:[~2016-09-14 16:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-14 14:46 [U-Boot] interaction between CONFIG_CMD_SAVEENV and CONFIG_BOOTCOMMAND Nicolas le bayon
2016-09-14 15:00 ` Wolfgang Denk
2016-09-14 16:43   ` Nicolas le bayon [this message]
2016-09-14 18:38     ` Wolfgang Denk
2016-09-15  7:56       ` Nicolas le bayon

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='CAJZhe_jhWpQLgwquHZ2U5jHL7hvkBFc=Kz0joyELDAM5vR+t7A@mail.gmail.com' \
    --to=nlebayon@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.