From: Chris White <chriswhite@gentoo.org>
To: Anderson Lizardo <anderson.lizardo@indt.org.br>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.arm.linux.org.uk,
"Russell King - ARM Linux" <linux@arm.linux.org.uk>,
David Brownell <david-b@pacbell.net>,
Tony Lindgren <tony@atomide.com>,
Anderson Briglia <anderson.briglia@indt.org.br>,
Carlos Eduardo Aguiar <carlos.aguiar@indt.org.br>
Subject: Re: [patch 3/5] Add MMC password protection (lock/unlock) support V2
Date: Thu, 29 Dec 2005 18:07:11 +0900 [thread overview]
Message-ID: <200512291807.16111.chriswhite@gentoo.org> (raw)
In-Reply-To: <20051228185412.736374000@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 3606 bytes --]
On Thursday 29 December 2005 03:40, Anderson Lizardo wrote:
Something that sort of caught my eye while looking at this (I generally don't
post here so I'm bitting the bullet and hoping I don't screw up), it seems
that this is an experimental driver, but doesn't contain any sort of uniquely
seperated verbose debug information. Let me try and narrow that down:
> +int mmc_key_instantiate(struct key *key, const void *data, size_t datalen)
> +{
> + struct mmc_key_payload *mpayload;
> + struct device *dev;
> + struct mmc_card *card;
> + int ret;
> +
> + ret = -EINVAL;
> + if (datalen <= 0 || datalen > MMC_KEYLEN_MAXBYTES || !data)
> + goto error;
Right here something about the data being passed to the function is invalid.
> + ret = key_payload_reserve(key, datalen);
> + if (ret < 0)
> + goto error;
> +
> + ret = -ENOMEM;
> + mpayload = kmalloc(sizeof(*mpayload) + datalen, GFP_KERNEL);
> + if (!mpayload)
> + goto error;
Unable to allocate mpayload structure, or something of the like.
> + /* attach the data */
> + mpayload->datalen = datalen;
> + memcpy(mpayload->data, data, datalen);
> + rcu_assign_pointer(key->payload.data, mpayload);
> +
> + ret = -EINVAL;
> + dev = bus_find_device(&mmc_bus_type, NULL, NULL, mmc_match_lockable);
> + if (!dev)
> + goto error;
Unable to locate device.
> + card = dev_to_mmc_card(dev);
> + if (mmc_card_locked(card)) {
> + ret = mmc_lock_unlock(card, key, MMC_LOCK_MODE_UNLOCK);
> + mmc_remove_card(card);
> + mmc_register_card(card);
> + } else
> + ret = mmc_lock_unlock(card, key, MMC_LOCK_MODE_SET_PWD);
> + if (ret)
> + ret = -EKEYREJECTED;
Key was rejected, though I suppose EKEYREJECTED pretty much states that.
[snip snip]
> +
> +/*
> + * update a mmc key
> + * - the key's semaphore is write-locked
> + */
> +int mmc_key_update(struct key *key, const void *data, size_t datalen)
> +{
> + struct mmc_key_payload *mpayload, *zap;
> + struct device *dev;
> + struct mmc_card *card;
> + int ret;
> +
> + ret = -EINVAL;
> + if (datalen <= 0 || datalen > MMC_KEYLEN_MAXBYTES || !data)
> + goto error;
See above about invalid data
> + /* construct a replacement payload */
> + ret = -ENOMEM;
> + mpayload = kmalloc(sizeof(*mpayload) + datalen, GFP_KERNEL);
> + if (!mpayload)
> + goto error;
This code almost seemed similiar to mmc_key_instantiate.. I almost wonder if
the code could be consolidated into a single function with some sort of
update conditional code. With that the debug information wouldn't be
duplicated. so snip
> +#ifdef CONFIG_MMC_PASSWORDS
> + else {
> + ret = register_key_type(&mmc_key_type);
> + if (ret) {
Something about the registration failing.
> + class_unregister(&mmc_host_class);
> + bus_unregister(&mmc_bus_type);
> + }
> + }
> +#endif
> }
> return ret;
> }
> @@ -345,6 +501,9 @@ static void __exit mmc_exit(void)
> {
> class_unregister(&mmc_host_class);
> bus_unregister(&mmc_bus_type);
> +#ifdef CONFIG_MMC_PASSWORDS
> + unregister_key_type(&mmc_key_type);
> +#endif
> }
>
> module_init(mmc_init);
That was mainly it. The verbose debug information is more of a "this would be
nice" sort of thing. Just from a user's perspective of debuggin experimental
drivers, this sort of thing is always nice. The code duplication in
mmc_key_instantiate/update still catches my eye though, there may be a
functional code flow to this that I'm not aware of, so again I bite the
bullet. Best hope that I don't make a fool of myself :).
Chris White
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-12-29 9:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-28 18:40 [patch 0/5] " Anderson Lizardo
2005-12-28 18:40 ` [patch 1/5] " Anderson Lizardo
2005-12-28 18:40 ` [patch 2/5] " Anderson Lizardo
2005-12-28 18:40 ` [patch 3/5] " Anderson Lizardo
2005-12-29 9:07 ` Chris White [this message]
2005-12-28 18:40 ` [patch 4/5] " Anderson Lizardo
2005-12-28 21:23 ` Arnd Bergmann
2005-12-28 18:40 ` [patch 5/5] " Anderson Lizardo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200512291807.16111.chriswhite@gentoo.org \
--to=chriswhite@gentoo.org \
--cc=anderson.briglia@indt.org.br \
--cc=anderson.lizardo@indt.org.br \
--cc=carlos.aguiar@indt.org.br \
--cc=david-b@pacbell.net \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome