[coreboot] Add mutable variable support to CBFS (was: Re: how to implement variable read/write variable in coreboot)

[Nico Huber]

Hi Peter,

On 01.10.2017 00:48, Peter Stuge wrote:> Nico Huber wrote:
>> wear leveling
>> ring buffer
>> sanitation phase
>> optimizing every update
>> Defragmentation
> ..
>> Might work?
>
> Please don't invent a new format
Can you give an example of an existing format that might do? I have
to admit, I didn't took the time yet to look at related work.

> don't reinvent JFFS2 and/or UBI..
These implement wear leveling for NAND flashes, AIUI. We are talking
about NOR flashes. I'm pretty sure you know the difference better than
I do.

>
> Let's make CBFS work for this, please. Reusing the existing data
> structure is incredibly valuable, even if it means some overhead.
There are a few obstacles to overcome and decisions to make if we want
to use CBFS. First, what level of compatibility should we target? Some
ideas, only some are mutually exclusive:

   1. Just reuse the CBFS data structures for a new kind of entry
      (without implied compatibility to other entry types).

   2. Handle any kind of CBFS entry in the variable storage implemen-
      tation that fits an erase block and can easily be moved around.

   3. Handle any kind of CBFS entry in the variable storage implemen-
      tation. (even "complex" entries, e.g. bigger than erase block
      size, entries with fixed alignment or positions).

   4. Always keep the variable storage in a state such that current
      CBFS readers succeed to read it.

   5. Bloat current CBFS readers until they can handle the variable
      storage in any state (including fail states due to interrupted
      updates).

   6. Always keep the variable storage in a state such that current
      `cbfstool` can alter a dump safely.

   7. Bloat `cbfstool` until it can alter a dump safely.

I hope we can agree that 1. alone would only result in confusion and is
to be avoided.

2. seems to be easily accomplished, but I don't see any benefit.

3. together with 4. or 5. would allow us to put mutable variables into
the same CBFS space that we use for the coreboot stages. It implies
that we could never have a per erase block header but I've tried to
avoid that in my drafts anyway, so far.

I don't see how 4. and 6. could be accomplished without always keeping
things in order and, thus, not having a backup in case an update fails.
Maybe I miss something, could it be done?

I don't like 5. and 7. (that's why I used the word bloat). But so far
the only combination where I see a win by reusing CBFS structures with-
out a loss in reliability is 3. + 5. (+ optionally 7.).

Peter, please choose your preferred combination of compatibility targets
(add new ones that you miss).

Nico