[libubootenv] Does it respect variable flags?

[Lukasz Domowy]

Hello,

Does libubootenv support respect for access flags?

I am able to modify ethaddr (which is write-once):

fw_setenv ethaddr <my-max>

Am I doing something wrong? I do not have --defenv file.

Best regards,

Lukasz

[Pierre-Jean Texier]

Hello Lukasz,

Can you give the libubootenv revision you use ?


BR
Pierre-jean

[Lukasz Domowy]

Hello!

fw_printenv --version
0.1

It comes from:
meta-swupdate        = "ww-warrior:c7a188e82a46e7841e8168cbb567f522e5e7288a"

So its:
SRCREV = "8a7d4030bcb106de11632e85b6a0e7b7d4cb47af"

Best regards,
Lukasz

[Stefano Babic]

Hi Lukasz,

On 24/05/19 21:05, Lukasz Domowy wrote:
> Hello!
>
> On Friday, May 24, 2019 at 8:53:30 PM UTC+2, Pierre-Jean Texier wrote:
>
>> Hello Lukasz,
>>
>> Le 24/05/2019 à 20:44, Lukasz Domowy a écrit :
>> > Hello,
>> >
>> > Does libubootenv support respect for access flags?
>> >

Yes, flags are supported in libubootenv

>> > I am able to modify ethaddr (which is write-once):
>> > fw_setenv ethaddr <my-max>
>> >
>> > Am I doing something wrong? I do not have --defenv file.
>> >

Are you sure you are using the flag ? Variable ethaddr is treated in a
special way in U-Boot. It is implicitly set to read-only in code without
using flags if CONFIG_ENV_OVERWRITE in U-Boot config is not set. Any
tool in user space cannot know this.

Best regards,
Stefano Babic

>> > Best regards,
>> > Lukasz
>> >
>>
>> Can you give the libubootenv revision you use ?
>
> fw_printenv --version
> 0.1
>
> It comes from:
> meta-swupdate        = "ww-warrior:c7a188e82a46e7841e8168cbb567f522e5e7288a"
>
> So its:
> SRCREV = "8a7d4030bcb106de11632e85b6a0e7b7d4cb47af"
>
> Best regards,
> Lukasz
>

> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To post to this group, send email to swup...@googlegroups.com
> <mailto:swup...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/1cc3d5ad-cad0-4044-8264-e5e0005dc7e0%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/1cc3d5ad-cad0-4044-8264-e5e0005dc7e0%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[Lukasz Domowy]

Hello,

On Tuesday, May 28, 2019 at 10:22:44 AM UTC+2, Stefano Babic wrote:
>Hi Lukasz,
>
>On 24/05/19 21:05, Lukasz Domowy wrote:
>> Hello!
>>
>> On Friday, May 24, 2019 at 8:53:30 PM UTC+2, Pierre-Jean Texier wrote:
>>
>>> Hello Lukasz,
>>>
>>> Le 24/05/2019 à 20:44, Lukasz Domowy a écrit :
>>> > Hello,
>>> >
>>> > Does libubootenv support respect for access flags?
>>> >
>
>Yes, flags are supported in libubootenv

So maybe dumb question - where is information about flags physically stored?
Only in U-Boot source code?
Or maybe better question - how to properly initialize U-Boot environment with flags on blank flash?
Is is possible using libubootenv and /etc/u-boot-initial-env? Does this file support flags?

>>> > I am able to modify ethaddr (which is write-once):
>>> > fw_setenv ethaddr <my-max>
>>> >
>>> > Am I doing something wrong? I do not have --defenv file.
>>> >
>
>Are you sure you are using the flag ? Variable ethaddr is treated in a
>special way in U-Boot. It is implicitly set to read-only in code without
>using flags if CONFIG_ENV_OVERWRITE in U-Boot config is not set. Any
>tool in user space cannot know this.

U-Boot (2018.11) seems to work as expected - allows to set it only once:
DEV1# env default -f -a
## Resetting to default environment
DEV1# setenv ethaddr 00:44:44:00:04:01
DEV1# setenv ethaddr 00:44:44:00:04:01
## Error: Can't overwrite "ethaddr"
## Error inserting "ethaddr" variable, errno=1

However, after booting, libubootenv overwrites it without complains:
root@dev1_cpuX_X:~# fw_setenv ethaddr 00:44:44:00:04:01
root@dev1_cpuX_X:~# fw_setenv ethaddr 00:44:44:00:04:02
root@dev1_cpuX_X:~# fw_printenv ethaddr
ethaddr=00:44:44:00:04:02

Best regards,
Lukasz

[Diego Rondini]

Hi Lukasz,

On Wed, May 29, 2019 at 8:26 AM Lukasz Domowy <lukasz...@gmail.com> wrote:
>
> So maybe dumb question - where is information about flags physically stored?

The following article, and in particular Fig. 5, provides a good
answer to your question:
https://www.vermasachin.com/posts/3-u-boot-environment-variables/

--
Diego Rondini
Sr. Embedded Engineer

Kynetics
www.kynetics.com

[Stefano Babic]

Hi Lukasz,

This is *EXACTLY* what I told you above: U-boot has a built-in check
with CONFIG_ENV_OVERWRITE, a user library cannot have. Your U-Boot does
not use flags at all.

Best regards,
Stefano Babic

[uwe.sch...@gmail.com]

I have the same problem as the original poster but not only for ethaddr! I tried the following:
fw_setenv foo "hello"
fw_setenv .flags foo:sr #comment: attributes set to string and read-only
fw_printenv
> .flags=foo:sr
> foo="hello"
fw_setenv foo "new"
fw_printenv
> .flags=foo:sr
> foo="new"

I do expect that I cannot change foo again if attributes are set to read-only.

This works perfectly in u-boot itself but linux user space libubootenv does NOT take care of the special .flags variable!

I had a look at the code from last commit. I can spot the place where all flags (if any) from the internal data table is stored into the .flags variable BUT could not see any place where the content (the flags) of that variable is parsed back into internal database when reading variables or when a variable is accessed!

[Stefano Babic]

Hi Uwe,

I have tested myself and I can confirm the issue - each variable is
checked by the libuboot_validate_flags() when is changed, but the value
of the .flags variable is not parsed after loading the environment. It
must be fixed.

[uwe.sch...@gmail.com]

Hi Stefano,

we tested the latest patches for that issue as they are in the GIT repo. It seems to fix the general problem of parsing and obeying a .flags variable value string when it exists in the enviroment. But I have found still three issues:

1. The write once (o) access atrribute flag is not properly handled if the variable referenced by the .flags value string does not exist yet (as it would be the case with write once variables before they are first written or set). Instead this variables flags gets removed from .flags value and attributes are lost.

This behavior also applies to all other variables which do not exist yet, but in case of write once variables I'd consider it a normal use case.

2. The IP or MAC type attribute flags (i and m) are completely NOT checked for any valid format.

3. When reading the variables from the default env file (like after an erased env flash area or with -f command line flag) and the .flags variable is part of the default env file, it is not parsed, as when read from normal env (after the latest fixes)

Am Montag, 3. Juni 2019 17:50:05 UTC+2 schrieb Stefano Babic:

Hi Uwe,