Messages in this thread | | | Date | Wed, 14 Dec 2005 19:51:06 -0400 | From | Anderson Lizardo <> | Subject | Re: [patch 0/5] Add MMC password protection (lock/unlock) support |
| |
On 12/14/05, Pierre Ossman <drzeus-list@drzeus.cx> wrote: > Anderson Briglia wrote: > > - Password caching: when inserting a locked card, the driver should try to > > unlock it with the currently stored password (if any), and if it fails, > > revoke the key containing it and fallback to the normal "no password present" > > situation. > > > > Would it be possible to use the id of the card as a search key for the > password? That way several passwords can coexist.
Yes, we have plans for that. The keys managed by the key retention service have a description field that can be used to uniquely identify keys and allows searching for specific keys. For this first version of the code, we are using simply "mmc:key" as the description, which does not allow more than one MMC password to be stored at a time.
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.
> > - Currently, some host drivers assume the block length will always be a power > > of 2. This is not true for the MMC_LOCK_UNLOCK command, which is a block > > command that accepts arbitratry block lengths. We have made the necessary > > changes to the omap.c driver (present on the linux-omap tree), but the same > > needs to be done for other hosts' drivers. > > > > The MMC layer is designed that way, so it's hardly surprising that > drivers have been coded for it. I'm assuming you've removed blksz_bits > in favor of something in bytes?
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.
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? -- Anderson Lizardo Embedded Linux Lab - 10LE Nokia Institute of Technology - INdT Manaus - Brazil - 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/
| |