[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Checksummed environments

From: Kristian Amlie
Subject: Re: Checksummed environments
Date: Fri, 6 Apr 2018 15:08:23 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 06/04/18 14:35, Daniel Kiper wrote:
> On Fri, Apr 06, 2018 at 11:25:22AM +0200, Kristian Amlie wrote:
>> Hey, I work for, developing update software for embedded
>> Linux devices.
>> I have a question about GRUB's environment block: This block is not
> I am not sure what exactly you mean by "GRUB's environment block".
> Could you send me some references to the code?

Of course, sorry if the context wasn't clear. I'm talking about the
environment block mentioned here:,
which is used to store information from one boot to the next, using
save_env and load_env.

>> checksummed, and hence I reckon it can become corrupt if power is lost
>> in the middle of a write.
> What about the other blocks?

In theory, there is only one block, because it is written in-place,
directly on disk, without changing any other filesystem blocks. Is that
what you meant by "other blocks"?

>> This is an important safety criterion for us, so we've been thinking of
>> developing environment block checksumming as an extension to the
>> existing save_env and load_env commands. The most likely approach will
>> be to grab X amount of bytes at the end of the block and use these for
>> the checksum.
> Could you tell us more about that?

The idea comes from U-Boot [1], which uses a dedicated block on a
storage device to store data, and uses a CRC32 checksum to make sure it
is consistent. The motivation is to be able to detect that the block is
corrupt, rather than accepting a block of data that may have incorrect
data in if a write was interrupted midway by a powerloss. You can read
more about it in the link.



>> This would also allow us to fall back to an earlier environment file if
>> the current one is corrupt, hence implementing redundancy.
>> Is this something that the GRUB project would be interested in? We want
>> to upstream this if possible, since we think many people may benefit
>> from this.
> Great! However, first of all we need some more info about that.
> Daniel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]