[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <17643.1460806407@warthog.procyon.org.uk>
Date: Sat, 16 Apr 2016 12:33:27 +0100
From: David Howells <dhowells@...hat.com>
To: Mat Martineau <mathew.j.martineau@...ux.intel.com>
Cc: dhowells@...hat.com, pjones@...hat.com, tadeusz.struk@...el.com,
marcel@...tmann.org, dwmw2@...radead.org, keyrings@...r.kernel.org,
linux-crypto@...r.kernel.org,
linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] KEYS: Provide keyctls to do public key operations
Mat Martineau <mathew.j.martineau@...ux.intel.com> wrote:
> > The interface for the active ops is a bit clunky as the syscall interface
> > doesn't provide sufficient argument space to pass everything I need to
> > specify. Some basic integer arguments are specified in a struct and more
> > complex options through a string of key=val pairs - just so I don't have to
> > deal with the compat code for dealing with a struct containing pointers
> > (but I can change to that if it's preferable).
>
> It sounds like the struct would still have pointers to strings that would
> need parsing,
It doesn't:
struct keyctl_pkey_params {
__s32 key_id;
__s32 password_id;
__u32 data_len;
__u32 enc_len;
__u32 __spare[4];
};
because I have sufficient syscall arguments to pass four pointers - the struct
above, one info string and two buffer pointers.
> so I'm not sure it's that much overhead to handle the short
> strings of key=val pairs. But I'll agree that it feels clunky.
... fixes applied ...
> > + info->supported_ops = KEYCTL_SUPPORTS_VERIFY;
>
> Did you intend to include encrypt/decrypt/sign here?
When they're implemented there.
David
Powered by blists - more mailing lists