From: David Howells <dhowells@redhat.com>
To: David =?iso-8859-1?Q?H=E4rdeman?= <david@2gen.com>
Cc: linux-kernel@vger.kernel.org, dhowells@redhat.com
Subject: Re: [PATCH 03/04] Add encryption ops to the keyctl syscall
Date: Tue, 24 Jan 2006 10:58:24 +0000 [thread overview]
Message-ID: <17515.1138100304@hades.cambridge.redhat.com> (raw)
In-Reply-To: <1138048952965@2gen.com>
David Härdeman <david@2gen.com> wrote:
> Changes the keyctl syscall to accept six arguments (is it valid to do so?)
> and adds encryption as one of the supported ops for in-kernel keys.
I tried to avoid doing that for it required arch support as I recall, but I'm
not sure which arch I was thinking of. It looks like it ought to be okay...
it's no worse than mmap.
> + * - should return the amount of data that would be returned from the
> + * encryption even if the buffer is NULL
> + * - expects the output buffer to be able to hold the result
> + */
Can you use TAB chars here please.
> #define KEYCTL_ASSUME_AUTHORITY 16 /* assume request_key() authorisation */
> +#define KEYCTL_ENCRYPT 17 /* encrypt a chunk of data using key */
And here.
> + key = key_ref_to_ptr(key_ref);
> +
> + /* see if we can read it directly */
> + ret = key_permission(key_ref, KEY_READ);
You don't actually need to calculate key until after you've done all those
checks, so I'd move it further down the file. You can use the function to
release key references in the error handling or have a separate error handling
return path.
> + down_read(&key->sem);
> + ret = key->type->encrypt(key, data, dlen, result, rlen);
> + up_read(&key->sem);
Do we really want to restrict the key type implementor to using the r/w
semaphore. Would it be better to let the type decide whether it wants to use
the semaphore or let it use RCU if it so desires?
David
next prev parent reply other threads:[~2006-01-24 10:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <11380489522552@2gen.com>
2006-01-23 20:42 ` [PATCH 02/04] Add dsa crypto ops David Härdeman
2006-01-23 20:42 ` [PATCH 03/04] Add encryption ops to the keyctl syscall David Härdeman
2006-01-23 20:42 ` [PATCH 04/04] Add dsa key type David Härdeman
2006-01-24 11:08 ` David Howells
2006-01-25 19:14 ` David Härdeman
2006-01-26 9:41 ` David Howells
2006-01-24 4:33 ` [PATCH 03/04] Add encryption ops to the keyctl syscall Randy.Dunlap
2006-01-24 10:58 ` David Howells [this message]
2006-01-25 20:40 ` David Härdeman
2006-01-26 9:43 ` David Howells
2006-01-24 11:09 ` David Howells
2006-01-24 1:22 ` [PATCH 02/04] Add dsa crypto ops Herbert Xu
2006-01-24 6:49 ` David Härdeman
2006-01-24 10:37 ` [PATCH 01/04] Add multi-precision-integer maths library David Howells
2006-01-25 20:46 ` David Härdeman
2006-01-26 9:45 ` David Howells
2006-01-26 21:58 [PATCH 00/04] Add DSA key type David Härdeman
2006-01-26 21:58 ` [PATCH 03/04] Add encryption ops to the keyctl syscall David Härdeman
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=17515.1138100304@hades.cambridge.redhat.com \
--to=dhowells@redhat.com \
--cc=david@2gen.com \
--cc=linux-kernel@vger.kernel.org \
/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