RfD: Configuration file format

[Tobias Schmidl]

Hi all,

Jan and I have been discussing the need for a configuration file format
for efibootmgr. I've looked into different options:


## INI ##

There is a small [1] library which adds around 1500 LOCs (MIT License).
Additionally, a small parser could be written by ourself.

Pros:
- Simple
- Easy parsable

Cons:
- There isn't really any "standard" for an INI file. [2] has some of the
varying features.
- This means, we would also document *our* supported features.


## systemd's Boot Loader Specification [3] ##

systemd basically invented their own configuration format.

Pros:
- Fairly well documented. Since they opened systemd.io, the
documentation of systemd improved quite a bit.

Cons:
- There doesn't seem to be a concise and simple library for parsing
their format. This *could* be taken from the systemd source code [4],
but this is not trivial.


## TOML ##

TOML was explicitly designed to be a replacement for INI. That also
means we could sell our config format as a "well defined INI format".

Pros:
- Well documented [5].
- There's already a library [6], which is MIT licensed and would add
around 2550 LOCs.

Cons:
- More complex, which *might* add a bigger attack surface. I've looked
for current CVEs and didn't find any.

So far my recommendation would be to use TOML.

Kind regards,

Tobias

[1]: https://github.com/ndevilla/iniparser
[2]: https://en.wikipedia.org/wiki/INI_file#Varying_features
[3]: https://systemd.io/BOOT_LOADER_SPECIFICATION/
[4]: https://github.com/systemd/systemd/blob/main/src/boot/bootctl.c
[5]: https://github.com/toml-lang/toml/wiki
[6]: https://github.com/cktan/tomlc99

[Michael Adler]

Hi Tobias,

> ## INI ##

> ## systemd's Boot Loader Specification [3] ##

> ## TOML ##

what about libconfig [1]? While the license might not be optimal (LGPL), it is typically a dependency of SWUpdate and
thus already available (as a shared object) in many deployment scenarios of efibootguard.
Also, it is available in Debian >= stretch and most other distros [2].

Kind Regards,
Michael

[1] https://github.com/hyperrealm/libconfig
[2] https://repology.org/project/libconfig/versions

--
Michael Adler

Siemens AG
T CED SES-DE
Otto-Hahn-Ring 6
81739 München, Deutschland

Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim Hagemann Snabe; Vorstand: Roland Busch, Vorsitzender; Klaus Helmrich, Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin-Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322

[Schmidl, Tobias]

Hi Michael,

Am Mittwoch, dem 13.07.2022 um 15:31 +0200 schrieb Michael Adler:
> Hi Tobias,
>
> > ## INI ##
> > ## systemd's Boot Loader Specification [3] ##
> > ## TOML ##
>
> what about libconfig [1]? While the license might not be optimal (LGPL),
> it is typically a dependency of SWUpdate and
> thus already available (as a shared object) in many deployment scenarios
> of efibootguard.
> Also, it is available in Debian >= stretch and most other distros [2].
>

LGTM. I don't know whether the syntax is simple enough for our users,
that's for others to decide. The implementation part seems good.

Kind regards,

Tobias

[Michael Adler]

> the need for a configuration file format for efibootmgr.

Just to clarify: with efibootmgr you mean efibootguard? More importantly, at which stage do you want to parse the
configuration file? In "userspace" (bg_setenv and friends) or within the EFI domain? In the EFI domain, you cannot use
shared objects (and might prefer "single header" style libraries). Also, the license might also play a more important
role due to static linking.

Kind Regards,
Michael

[Jan Kiszka]

[switching Tobias' address at this chance]

On 14.07.22 09:02, Michael Adler wrote:
>> the need for a configuration file format for efibootmgr.
>
> Just to clarify: with efibootmgr you mean efibootguard? More importantly, at which stage do you want to parse the
> configuration file? In "userspace" (bg_setenv and friends) or within the EFI domain? In the EFI domain, you cannot use
> shared objects (and might prefer "single header" style libraries). Also, the license might also play a more important
> role due to static linking.

We will need them in both domains, even writing in both (updating
ustate). So, yes, being small or at least easily statically linkable
will play an important role.

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux

[Schmidl, Tobias]

>
> Just to clarify: with efibootmgr you mean efibootguard? More
> importantly, at which stage do you want to parse the
> configuration file? In "userspace" (bg_setenv and friends) or within the
> EFI domain? In the EFI domain, you cannot use
> shared objects (and might prefer "single header" style libraries). 
> Also, the license might also play a more important
> role due to static linking.
>

As Jan said, at both stages. That's why both the license and the code size
is important.

Kind regards,

Tobias

[Jan Kiszka]

I think we should give a very simple solution a try first. That can be
including some helpful lib for an established format, but my feelings
say that implementing a few lines for something along option 1 might be
even simpler.

[Christian Storm]

Hi,

Well, this is just a list of configuration (file) formats.

Usually, it's the other way round: You define what you actually want to
configure, the semantics of this, and in what scopes it is used.
Then you filter the available configuration (file) formats by
their scope and fitness for your needs (e.g. expressiveness, simplicity,
licenses, ...) and choose one or make your own if there's none available.

So, can we have a specification or a (ranked) requirements list to what
the configuration (file) format should actually be able configure, also
to not miss something out and to be future-proof to not switch formats
again?


Kind regards,
Christian

--
Dr. Christian Storm
Siemens AG, Technology, T CED SES-DE
Otto-Hahn-Ring 6, 81739 München, Germany

[Schmidl, Tobias]

Hi all,

Am Montag, dem 25.07.2022 um 11:24 +0200 schrieb Christian Storm:
>
> So, can we have a specification or a (ranked) requirements list to what
> the configuration (file) format should actually be able configure, also
> to not miss something out and to be future-proof to not switch formats
> again?
>

In my understanding the basic requirements are "should be able to replace
bgenv.dat" and "should be configurable in the field, in case something
goes wrong". But I haven't seen a formalized list yet.

Kind regards,

Tobias

[christi...@siemens.com]

Hi,

> > So, can we have a specification or a (ranked) requirements list to what
> > the configuration (file) format should actually be able configure, also
> > to not miss something out and to be future-proof to not switch formats
> > again?
> >
>
> In my understanding the basic requirements are "should be able to replace
> bgenv.dat" and "should be configurable in the field, in case something
> goes wrong". But I haven't seen a formalized list yet.

Needs not to be "formal" but clear in requirements. This is far from it
and doesn't enable me to make an informed decision nor to get into
discussion on this "RfD" thread.
Please elaborate on the requirements/use cases in a more detailed manner.

[Jan Kiszka]

On 27.07.22 13:17, christi...@siemens.com wrote:
> Hi,
>
>>> So, can we have a specification or a (ranked) requirements list to what
>>> the configuration (file) format should actually be able configure, also
>>> to not miss something out and to be future-proof to not switch formats
>>> again?
>>>
>>
>> In my understanding the basic requirements are "should be able to replace
>> bgenv.dat" and "should be configurable in the field, in case something
>> goes wrong". But I haven't seen a formalized list yet.
>
> Needs not to be "formal" but clear in requirements. This is far from it
> and doesn't enable me to make an informed decision nor to get into
> discussion on this "RfD" thread.
> Please elaborate on the requirements/use cases in a more detailed manner.
>

I would put it this way:

- must be able to model existing variables, including user vars, from
bgenv.dat
- must be able to add new variables without breaking older
implementations (appending new vars, appending new sections of vars)
- should be able to signal semantical changes if existing variables
(different meaning of values, new possible values, renaming or
removal of variables)