[U-Boot] UBI/UBIFS complete integrity check

[Liam Beguin]

On 11/06/2017 12:57 PM, Ladislav Michl wrote:
> On Mon, Nov 06, 2017 at 12:31:32PM -0500, Liam Beguin wrote:
>> Hi,
>>
>> Thanks for taking the time to answer.
>>
>> On 11/05/2017 03:37 AM, Ladislav Michl wrote:
>>> On Tue, Oct 31, 2017 at 11:01:21AM -0400, Liam Beguin wrote:
>>>> Hi everyone,
>>>>
>>>> I'm currently using a UBIFS root file system (stored on SPI-NOR flash)
>>>> and would like to perform a full integrity check before booting it.
>>>> The rootfs is read-only and until now, I've been computing an md5sum on
>>>> the whole mtd device from an initramfs and comparing it to a stored
>>>> md5sum. If both md5sums don't match, I need to stop the boot process
>>>> completely.
>>>
>>> Above doesn't sound right even in theory as UBI layer is free to correct
>>> bit-flips (unlikely on SPI-NOR) and shuffle eraseblocks around even
>>> if read only filesystem is sitting on top of it. See this faq:
>>> http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubiblock> So, if you
>>> are computing md5sum of underlaying mtd device you might get
>>> different checksum even for the same UBI content.
>>>
>>
>> I forgot to mention that the flash I use has a hardware lock which is enabled
>> after the filesystem is first written (the flash is locked during boot).
>> I'm quite confident this works as I've been using the md5sum mechanism for
>> some time now.
> 
> I see. Btw, have you considered using for example squashfs on top of static UBI
> volume? Given the fact your fs is read only you get:
> - CRC32 checksum of you volume for free
> - filesystem compression
> - you can easily compute mtd5sum of volume content
> - check filesystem consistency using already provided tools (probably overkill).
> 

I have considered squashfs but on rare occasions, I need to be able to write to the
rootfs. This involves disabling the hardware lock, remounting RW and updating the
reference md5sum after writing.

>> As the UBI layer is able to detect/fix bit-flips, what happens if a bit-flip is
>> detected and UBI cannot write to flash? does it fail to attach?
> 
> No, it just logs it. It fails once there is enough bitflips that ECC is unable
> to correct them. But again, it is not case of NOR, I mentioned it just for
> completeness.

I understand that bit-flips are uncommon on NOR flash but in our case, they may
be caused by the environment not the flash technology.

> 
>>>> If possible, I was hoping to drop initramfs and do the integrity check
>>>> from U-Boot. I know UBI/UBIFS does a CRC-32 of the data it writes to
>>>> flash but the intent here is to prevent booting an image where
>>>> even a _single bit_ of flash may have been corrupted.
> 
> Above mentioned solution should fail instantly in case of CRC error. Not sure if
> that's what you want as kernel already took over, so either watchdog will kick in
> or machine will reboot, if configured to do so after panics.
> 

Ideally, I'd like the attach to fail in U-Boot, before loading the kernel.

Something remains obscure to me... When UBI scans the device and potentially
warns of a bit-flip, has the _whole_ data been checked or was it only the
information contained in the UBI headers?

>>>> My question is, does UBI/UBIFS have this kind of complete integrity
>>>> check built-in? If not, can I take advantage of these CRC-32, to do
>>>> something equivalent to my md5sum check from U-Boot.
>>>> Thanks,
>>>
>>> There is md5sum command, question is whenever you UBI volume fits
>>> into RAM to do calculation at once.
>>>
>>>> Liam Beguin
>>>> Xiphos Systems Corp.
>>>> http://xiphos.com
>>>> _______________________________________________
>>>> U-Boot mailing list
>>>> U-Boot at lists.denx.de
>>>> https://lists.denx.de/listinfo/u-boot
>>
>> Thanks,
>>
>> Liam Beguin
>> Xiphos Systems Corp.
>> http://xiphos.com