mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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 --]

  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