lkml.org 
[lkml]   [2005]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 0/5] Add MMC password protection (lock/unlock) support
    Anderson Lizardo wrote:

    >Probably using the entire 128-bit CID for the key description would
    >waste too much space though, so we are thinking about using just some
    >CID fields to build a smaller unique ID. The key retention service has
    >quotas for how much space a keyring can use for payload and key
    >description, so we should try to keep the description as short as
    >possible. If a collision occurs and the password is wrong, we can
    >simply invalidate the key and ask for the password again.
    >
    >
    >

    For SD cards we can also use the RCA, which tends to be a bit random.
    Perhaps a generic hash function so that we can extend and tweak this
    algorithm in one place?

    >I actually just did the following change to the OMAP code (drivers/mmc/omap.c):
    >
    >-
    >- block_size = 1 << data->blksz_bits;
    >+ /* password protection: we need to send the exact block size to the
    >+ * card (password + 2), not a 2-exponent. */
    >+ if (req->cmd->opcode == MMC_LOCK_UNLOCK)
    >+ block_size = data->sg[0].length;
    >+ else
    >+ block_size = 1 << data->blksz_bits;
    >
    >Given that for the LOCK_UNLOCK command the sg_len will always be 1, we
    >can get the block size directly from the first entry of the
    >scatterlist. For other block operations, the blksz_bits value is used
    >as usual.
    >
    >
    >

    I can't say that I approve of this code. It's my firm belief that
    drivers that are protocol aware are horribly broken.

    >Maybe removing blksz_bits and using the block size directly would be
    >better? Is there any host/card which expects to always receive a
    >power-of-2 block size for block operations?
    >
    >

    Sounds like a much better solution. Hacking around problems instead of
    solving them usually lead to even more problems.

    I haven't studied all drivers in detail, but I believe all of them
    should be able to handle the transistion.

    Rgds
    Pierre

    -
    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-12-15 07:52    [W:0.033 / U:0.044 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site