Hi Wolfgang,
On 21/11/18 12:45, Wolfgang Denk wrote:
Dear Stefano,
In message 9efc8990-118c-d5b9-802d-8190db2326d3@denx.de you wrote:
True, but this has side effect and limitation. You cannot change a variable in the deafult environment if you need it because you do not know it. If some changes are needed, even if for very small things like activating a gpio before ooting, you need to update the bootloader.
Just my words. (Mis) using the default environment for such purposes is broken by design.
Let's get rid of this!
Moving to shared library should be done in U-Boot project, then. Some changes are then required, at least how the environment is locked (it is not clean as it is done now - locking should be done by the library and not by the caller).
Speaking of security... shared libraries open a number of new attack vectors, too...
This is the reason why these libraries are in meta-swupdate built as static libraries. Up now I had no requests that someone else wants to use them.
In a secure boot environment, you cannot allow to load the environment from an untrusted source. We need a default environment in this case.
Or you make that changes are trusted.
Right, when we sign (and check the signatures) of all other images, then why not do the very same for some environment image?
The weird thing is with "saveenv" - if we just read the env, it is fine, but if we want to change it, we need to sign, and this requires a private key on target.
That would even be _better_ as currently there is no, absolutely no check if the builtin default environment is in any way consistent.
This is not true. If the environment is linked to u-boot, it is signed together with u-boot and its consistency is automatically verified.
Best regards, Stefano