lkml.org 
[lkml]   [2004]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: cryptoapi highmem bug
    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:01    [W:3.921 / U:0.328 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site