grub-devel
[Top][All Lists]
Advanced

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

Re: Checksummed environments


From: Kristian Amlie
Subject: Re: Checksummed environments
Date: Thu, 12 Apr 2018 11:09:07 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 12/04/18 10:58, Daniel Kiper wrote:
> On Thu, Apr 12, 2018 at 10:35:06AM +0200, Kristian Amlie wrote:
>> On 12/04/18 10:33, Daniel Kiper wrote:
>>> On Tue, Apr 10, 2018 at 11:09:33PM +0200, Daniel Kiper wrote:
>>>> On Fri, Apr 06, 2018 at 03:08:23PM +0200, Kristian Amlie wrote:
>>>>> On 06/04/18 14:35, Daniel Kiper wrote:
>>>>>> On Fri, Apr 06, 2018 at 11:25:22AM +0200, Kristian Amlie wrote:
>>>>>>> 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.
>>>>>
>>>>> [2] https://www.denx.de/wiki/DULG/UBootEnvVariables
>>>>
>>>> I am OK with the idea. However, I think that the feature should have
>>>> a kind of switch to turn it off/on. At first sight it looks that new
>>>> environment variable is sufficient for it.
>>>
>>> And/Or an argument for save_env/load_env...
>>
>> Yes, I'm fine with either. How about a variable that determines the
>> default, and you can override it with flags?
> 
> Works for me. However, I would assume that this feature is by default off.

Of course, we need to maintain full backwards compatibility! :-)

-- 
Kristian



reply via email to

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