Re: cryptoapi highmem bug

[Christophe Saout]

On Wed, Feb 25, 2004 at 03:46:51PM -0500, Jean-Luc Cooke wrote:

> > >  Can we do this?
> > 
> > It's very non-trivial. Think about journalling filesystems, write
> > ordering and atomicity. If the system crashes between two write
> > operations we must be able to still correctly read the data. And
> > write to these "crypto info blocks" should be done in a ways that
> > doesn't kill performance. Do you have a proposal?
> 
> I see.  From a security point of view, no.  OMACs need to be updated after
> the data is updated to keep integrity checks passing.

Yes. But if the machine doesn't get to update the OMAC but the data has
already been written you must be able to still read the data somehow.

> IVs need to be updated before the data is updated or plaintext is leaked.

Hmm? What could be done: The IV "sequence number" is incremented by one
every time a sector gets written. The IV sequence numbers get written
to the info block later (after a timeout, memory pressure and we to
free some space in the cache or if the sequence has gone too far). When
we read and the OMAC doesn't match we can try to increase the IV
several times until it matches. Still the problem with the OMAC
atomicity...

> (IV + data + OMAC can be written to device at once).

You can't guarantee that anything gets written at once. You can only
make sure that something has been written. Or that something gets
written before something else (using barriers, but I don't know if that
is stable, it has never been used on bio level yet).

> I assume then that IVs and OMACs will not be stored in the same read-chunk as
> the data then?  Bummer if this is the case.

Well, we can't store it in the same sector because all 512 bytes are
already used data.

We could store less than 512 bytes in a sector but that would mean
splitting up data on a sub-sector level. That means we have to read
some sectors with untouched data (the first and the last), update
the data and write several sectors. But then we can't even guarantee
that sectors are atomicically written as seen by the filesystem.
This is... yuck.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/