Re: [Linux-ima-user] Offline image creation: evm signing files problem with ubifs.

[Martin T. <mto...@gm...>]

Hi Daniel,

Thank you for the reply and a great idea and one I would have no doubt
tried.  But after reading through the mkfs.ubifs source code it dawned
on me that the inode numbers should be the same if I copy the files
across, sign the image once and recreate the ubifs, then reload this
back into the NAND simulator and sign again and recreate the ubifs. On
the second time the inode numbering should stay the same as no new
inodes have been created (ie no new extended attributes or new key
files).

This worked (haven't tried it on the HW yet but evmctl verify reports
success).  It does double the time it takes but a small price to pay
considering the amount of time it's going to save in the factory where
the alternative is to sign all the files on the target hardware during
production.

Many Thanks,
Martin.

On Wed, Oct 11, 2017 at 8:04 PM, Daniel Glöckner <dg...@em...> wrote:
> Hello Martin,
>
> Am 10/11/17 um 19:50 schrieb Martin Townsend:
>> I will also look at how mkfs.ubifs works with regards to inode numbers
>> to see if anything can be done here.  If anyone has any ideas they
>> would be greatly appreciated.
>
> I'd try to extract the UBI volume from /dev/ubiX_Y or the nandsim data
> instead of running mkfs.ubifs a second time. You can cut off all blocks
> at the end that contain only 0xff. The image is probably a bit bigger
> than with mkfs.ubifs because of the old data that has not yet been
> garbage collected.
>
> Best regards,
>
>   Daniel
>
> --
> Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com
> Fon +49 551 30664-0, Fax +49 551 30664-11,
> Bertha-von-Suttner-Straße 9, 37085 Göttingen, Germany
> Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
> Geschäftsführung: Heike Jordan, Dr. Uwe Kracke
> Ust-IdNr.: DE 205 198 055
>
> emlix - your embedded linux partner