* [U-Boot] interaction between CONFIG_CMD_SAVEENV and CONFIG_BOOTCOMMAND @ 2016-09-14 14:46 Nicolas le bayon 2016-09-14 15:00 ` Wolfgang Denk 0 siblings, 1 reply; 5+ messages in thread From: Nicolas le bayon @ 2016-09-14 14:46 UTC (permalink / raw) To: u-boot Hi Let me firstly explain my need. We use U-boot as a primary bootloader, with a bootcmd which loads and executes a script on one external device (SD ou USB). This script will continue the boot process (launch a kernel for example). The corresponding bootcmd defined in CONFIG_BOOTCOMMAND does this load/execute operation. 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. 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. How could we do to have a well-constructed and not updatable env content? Thanls in advance for your answers Best Regards Nicolas ^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] interaction between CONFIG_CMD_SAVEENV and CONFIG_BOOTCOMMAND 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 0 siblings, 1 reply; 5+ messages in thread From: Wolfgang Denk @ 2016-09-14 15:00 UTC (permalink / raw) To: u-boot Dear Nicolas, In message <CAJZhe_gXm8zFhek9zZaXuV6j6CpHHFweS1FyDDGL2B+Gnb+B3Q@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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] interaction between CONFIG_CMD_SAVEENV and CONFIG_BOOTCOMMAND 2016-09-14 15:00 ` Wolfgang Denk @ 2016-09-14 16:43 ` Nicolas le bayon 2016-09-14 18:38 ` Wolfgang Denk 0 siblings, 1 reply; 5+ messages in thread From: Nicolas le bayon @ 2016-09-14 16:43 UTC (permalink / raw) To: u-boot 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 > ^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] interaction between CONFIG_CMD_SAVEENV and CONFIG_BOOTCOMMAND 2016-09-14 16:43 ` Nicolas le bayon @ 2016-09-14 18:38 ` Wolfgang Denk 2016-09-15 7:56 ` Nicolas le bayon 0 siblings, 1 reply; 5+ messages in thread From: Wolfgang Denk @ 2016-09-14 18:38 UTC (permalink / raw) To: u-boot Dear Nicolas, In message <CAJZhe_jhWpQLgwquHZ2U5jHL7hvkBFc=Kz0joyELDAM5vR+t7A@mail.gmail.com> you wrote: > > > 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? It should work as you expect. But since you ask what I _think_ ... :-) As a developer I really hate systems that attempt to lock me down into such a crippled environment. I still love and cherish the old quote: "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn You plan to implement a policy that restricts the freedom of the user for a questionable (to me - I don't know your requirements) advantage. Would it not be possible to implement a more open design, where the user can actually save his changes to the persistent environment (so someone who knows what he is doing can use the full power of the software), and instead provide a way to perform a factory reset (using "env default -f" or similar) to your original settings? That would feel much more U-Boot-like to me :-) > > 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. Hm... this should still not show such behaviour. Check your board config file thoroughly, especially your environment settings. Check that environment definitions are explicitly terminated by NUL characters, and that all string quotes pair. If you have any #ifdef magic there, check that, too. 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 All I ask is a chance to prove that money can't make me happy. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] interaction between CONFIG_CMD_SAVEENV and CONFIG_BOOTCOMMAND 2016-09-14 18:38 ` Wolfgang Denk @ 2016-09-15 7:56 ` Nicolas le bayon 0 siblings, 0 replies; 5+ messages in thread From: Nicolas le bayon @ 2016-09-15 7:56 UTC (permalink / raw) To: u-boot Dear Wolfgang, Regarding your recommendations about U-Boot usage, I completely agree with that. In fact, In my description, I wouldn't give too many details, but your answer leads me to add some :-) As I told you, this "old" u-boot is used only as primary bootloader, and its main objective is just to "source" a script on an external device. Note that this script is only a text file that can be modified by the user. We propose different script examples to the user, the basic one will only start the kernel (all images will be stored on the external device), but the most used one will start a secondary bootloader, so a second u-boot (this one is currently in rebasing phase, on 2016.09 release). And in this second u-boot, there is no access restrictions, user will be able to custom. Finally note that this is an intermediate step of our project. In final release, this "primary u-boot" will be replaced by a "bootrom" (so no more u-boot), and in that case, we will have only one "secondary" u-boot. Hope this clarifies :-) Back to our issue on our "primary" u-boot, we found an alternative. We generate two binaries, the first one used only to flash the second. In that case, we are able te disallow use of external env for the second and flash access (define CONFIG_ENV_IS_NOWHERE and undef CONFIG_XXX_FLASH). It seems functional after further tests. So indeed, there is a bug, but on our side, not in u-boot. We need "saveenv" to flash, our script was using the .elf (via gdb) to flash the .bin. And this flash operation was using the saveenv. So by using two differents binaries, we solve our issue, and u-boot is going well :-) Thanks Wolfgang for tyour reactivity and your recommendations. Please note that in our final product, we'll use u-boot with total respect of its philosophy, and we'll be aligned on one of the latest releases :) Best regards, Nicolas 2016-09-14 20:38 GMT+02:00 Wolfgang Denk <wd@denx.de>: > Dear Nicolas, > > In message <CAJZhe_jhWpQLgwquHZ2U5jHL7hvkBFc=Kz0j > oyELDAM5vR+t7A at mail.gmail.com> you wrote: > > > > > 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? > > It should work as you expect. > > But since you ask what I _think_ ... :-) As a developer I really hate > systems that attempt to lock me down into such a crippled environment. > I still love and cherish the old quote: > > "UNIX was not designed to stop you from doing stupid things, because > that would also stop you from doing clever things." - Doug Gwyn > > You plan to implement a policy that restricts the freedom of the user > for a questionable (to me - I don't know your requirements) advantage. > Would it not be possible to implement a more open design, where the > user can actually save his changes to the persistent environment > (so someone who knows what he is doing can use the full power of the > software), and instead provide a way to perform a factory reset (using > "env default -f" or similar) to your original settings? That would > feel much more U-Boot-like to me :-) > > > > > 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. > > Hm... this should still not show such behaviour. Check your board > config file thoroughly, especially your environment settings. Check > that environment definitions are explicitly terminated by NUL > characters, and that all string quotes pair. If you have any #ifdef > magic there, check that, too. > > > 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 > All I ask is a chance to prove that money can't make me happy. > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-09-15 7:56 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2016-09-14 18:38 ` Wolfgang Denk 2016-09-15 7:56 ` Nicolas le bayon
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.