On Fri, 2012-03-23 at 17:38 +0100, Joel Reardon wrote: > I'll answer some quickly here now while they're fresh in mind and add them > to the doc later. > > > > > > In particular, it does not behave like a > > > +log-structured file system: when a KSA LEB is updated, its contents are > > > +written to a new physical location on the flash memory, UBI's logical map is > > > +then updated to this new physical address and the previous version of the KSA > > > +LEB is then erased. > > > > Am I right that you basically wanted to say that when you update a KSA > > LEB, you make sure that the physical flash does not contain the old > > contents of this LEB? Would be nice to re-phrase. > > > > Side question - how do you do this? > > Here I'm just spelling out atomic update, so nothing fancy except > leb_change() to replace the keys. This will write the new data to a different PEB, and schedule the old PEB for erasure in background. If the UBI thread is alive, it will schedule the erasure soon. But if it is stopped or dead, the erasure may happen only when there is a need in an empty PEB. To make sure the old contents are really erased, you'd have to call 'ubi_sync()'. But the problem with this is that it will force erasure of _all_ the scheduled PEBs, so it may block for long time, especially on NOR. For the security things you'd probably need to extend 'ubi_leb_change()' and add a 'sync' parameter which would make sure the previous PEB is synchronously erased before 'ubi_leb_change()' returns. I think it is very easy to do. > Protected as in the kernel stops joe user from reading raw from /dev/mtd, > no? No, I think both UBI volumes and MTD devices are world-readable. > > Hmm, why is it necessary to re-initialize unused keys? > > > > This can be a mount option actually, it was a response to attack that was > proposed to me about the design. The idea here is that, suppose the > attacker reads the drive at time X with sufficient privilages to read the > keys. Then the attacker will know for certain that those keys will > eventually be used to encrypt data. So they can compromise not only the > current data, but also future data. By replacing unused keys, the attacker > is limited only to compromizing current data. Would be nice to put this to the doc, and I do not think we need a mount option for this. > Ah, yes! Any other tool? No, just this one. > > Hmm, interesting how you manage checkpoints. I guess the easiest would > > be to have a special inode (not visible for users) and store checkpoints > > there? > > > > The first block of the KSA stores only checkpoints, so KSA size is 1 + > minrequired + some slack. So this may need the multiple LEB > approach for one of the other UBIFS areas when its size is too big, but I > havn't done that since its generally so highly compressable that it > wasn't ever a concern. But I guess the larger is the volume the larger the checkpoint is? Also, would you please rename it to something else because checkpoint is a very common word with more or less commonly understood meaning, and using it for something else in context of file-systems is asking for troubles. Even if you call it 'backpack' (random word from my head) - I'll be happier :-) But something more sensible is more appreciated of course :-) -- Best Regards, Artem Bityutskiy
Attachment:
signature.asc
Description: This is a digitally signed message part
