Re: [PATCH 0/4] RFC: "New" /dev/crypto user-space interface

[Neil Horman <nhorman@xxxxxxxxxx>]

On Tue, Aug 10, 2010 at 09:24:31AM -0400, Steve Grubb wrote:
> On Tuesday, August 10, 2010 08:46:28 am Neil Horman wrote:
> > Specifically, my concerns are twofold:
> > 
> > 1) struct format.  By passing down a structure as your doing through an
> > ioctl call, theres  no way to extend/modify that structure easily for
> > future use.  For instance the integration of aead might I think requires a
> > blocking factor to be sepcified, and entry for which you have no available
> > field in your crypt_ops structure.  If you extend the structure in a later
> > release of this code, you create a potential incompatibility with user
> > space because you are no longer guaranteed that the size of the crypt_op
> > structure is the same, and you need to be prepared for a range of sizes to
> > get passed down, at which point it becomes difficult to differentiate
> > between older code thats properly formatted, and newer code thats
> > legitimately broken.  You might could add a version field to mitigate
> > that, but it gets ugly pretty quickly.
> 
> Yeah, this does call out for versioning. But the ioctls are just for crypto 
> parameter setup. Hopefully, that doesn't change too much since its just to 
> select an algorithm, possibly ask for a key to be wrapped and loaded, or ask 
> for a key to be created and exported. After setup, you just start using the 
> device.
>  
> 
> > Thats why I had suggested the use of a netlink protocol to manage this kind
> > of interface.  There are other issue to manage there, but they're really
> > not that big a deal, comparatively speaking, and that interface allows for
> > the easy specification of arbitrary length data in a fashion that doesn't
> > cause user space breakage when additional algorithms/apis are added.
> 
> The problem with the netlink approach is that auditing is not as good because 
> netlink is an async protocol. The kernel can only use the credentials that 
> ride in the skb with the command since there is no guarantee the process has 
> not changed credentials by the time you get the packet. Adding more 
> credentials to the netlink headers is also not good. As it is now, the 
> auditing is synchronous with the syscall and we can get at more information 
> and reliably create the audit records called out by the protection profiles or 
> FIPS-140 level 2.
> 
> -Steve

I think thats pretty easy to serialize though.  All you need to do is enforce a
rule in the kernel that dictates any creditial changes to a given context must
be serialized behind all previously submitted crypto operations.  It might make
life a bit tougher on the audit code, but netlink contains pid/sequence data in
all messages so that audit can correlate requests and responses easily.

Neil
 
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html