From: Anderson Briglia <anderson.briglia@indt.org.br>
To: ext Frank Seidel <frank@kernalert.de>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>,
"Lizardo Anderson (EXT-INdT/Manaus)"
<anderson.lizardo@indt.org.br>,
Pierre Ossman <drzeus-list@drzeus.cx>,
linux-kernel@vger.kernel.org,
"Aguiar Carlos (EXT-INdT/Manaus)" <carlos.aguiar@indt.org.br>,
Tony Lindgren <tony@atomide.com>,
ext David Brownell <david-b@pacbell.net>
Subject: Re: [PATCH 2/4] Add MMC Password Protection (lock/unlock) support V8: mmc_key_retention.diff
Date: Thu, 14 Dec 2006 10:10:02 -0400 [thread overview]
Message-ID: <45815B3A.1010805@indt.org.br> (raw)
In-Reply-To: <20061213155531.1kpbmi3pk40kkoos@webmail.kernalert.de>
Hi,
ext Frank Seidel wrote:
> Quoting Anderson Briglia <anderson.briglia@indt.org.br>:
>> [...]
> Hi,
> thats really cool stuff you're providing with your patches. :)
> I have some feedback or questions some parts here.
> But as i just started trying to get into kernelhacking you probably
> better don't take my notes to serious, please.
All comments are welcome, thanks for the revision. :)
>
>> Index: linux-linus-2.6/drivers/mmc/mmc_sysfs.c
>> ===================================================================
>> --- linux-linus-2.6.orig/drivers/mmc/mmc_sysfs.c 2006-12-04 [...]
>> +static int mmc_key_instantiate(struct key *key, const void *data,
>> size_t datalen)
>> +{
>> + struct mmc_key_payload *mpayload, *zap;
>> + int ret;
>> +
>> + zap = NULL;
> What is zap here for? future use?
> And wouldn't it be good to also initialize mplayload here?
The code was based on code presents at security/keys/user_defined.c. This is the reason of why the MMC PWD code was
implemented using this returns types and others implementations.
That file (user_defined.c) implements generic functions to handle keys inside the kernel, using the Kernel Key Retention
Service. Maybe you can take a look there, :).
That zap variable was used to expand the key payload when a new password exceeded a previous configured size. But the
Kernel Key Retention Service has changed and that zap variable is not used on key_instantiate function implemented at
user_defined.c, anymore. I'll update the MMC PWD code.
>
>> + ret = -EINVAL;
> Is there a special reason why you already assign the errors to the
> return value variable before its clear that the assignment is needed?
See the reply above.
>
>
>> + if (datalen <= 0 || datalen > MMC_KEYLEN_MAXBYTES || !data) {
> Isn't the last "|| !data" redundant as you already tested if datalen ==0?
data = 0 is different from !data.
>
>> + pr_debug("Invalid data\n");
>> + goto error;
>> + }
>> +
>> + ret = key_payload_reserve(key, datalen);
>> + if (ret < 0) {
>> + pr_debug("ret = %d\n", ret);
>> + goto error;
>> + }
>> +
>> + ret = -ENOMEM;
> Same as above: Why do you in any case want to assign it here?
Reply above.
>
>> + mpayload = kmalloc(sizeof(*mpayload) + datalen, GFP_KERNEL);
> I may be totally wrong, but is dereferencing a not initialized pointer
> (even just for using sizeof) really ok?
Yes. I believe sizeof is a compiler operation and it does not access the data pointed by that pointer, it access just
the type of the pointer.
Wouldn't it be safer to use
> a sizeof(struct mmc_key_payload) here?
I believe there is no difference on using this one and that other declaration.
Thanks,
Anderson Briglia
next prev parent reply other threads:[~2006-12-14 14:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-13 14:55 [PATCH 2/4] Add MMC Password Protection (lock/unlock) support V8: mmc_key_retention.diff Frank Seidel
2006-12-14 14:10 ` Anderson Briglia [this message]
2006-12-15 17:24 ` Pierre Ossman
2006-12-15 18:57 ` Anderson Briglia
-- strict thread matches above, loose matches on Subject: below --
2006-12-04 20:12 Anderson Briglia
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=45815B3A.1010805@indt.org.br \
--to=anderson.briglia@indt.org.br \
--cc=anderson.lizardo@indt.org.br \
--cc=carlos.aguiar@indt.org.br \
--cc=david-b@pacbell.net \
--cc=drzeus-list@drzeus.cx \
--cc=frank@kernalert.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk+lkml@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.