zfs code - May 2006 - Data set from zio_t

With encryption enabled each data set is going to have its own 
cryptographic key material (a crypto_key_t and maybe a 
crypto_ctx_template_t as well).

This means I need to be able to find out which data set a given zio_t 
belongs to while in the ZIO pipeline functions that do the encrypt
and decrypt of the data.

Is this a "sane" thing to want to do ? [ ie is my architecture okay ]
Is is a "safe" thing to do ?

-- 
Darren J Moffat

On Fri, May 05, 2006 at 05:39:29PM +0100, Darren J Moffat
wrote:
> With encryption enabled each data set is going to have its own 
> cryptographic key material (a crypto_key_t and maybe a 
> crypto_ctx_template_t as well).
> 
> This means I need to be able to find out which data set a given zio_t 
> belongs to while in the ZIO pipeline functions that do the encrypt
> and decrypt of the data.
> 
> Is this a "sane" thing to want to do ? [ ie is my architecture
okay ]
> Is is a "safe" thing to do ?
You can''t really do arbitrary DSL operations (such as looking up a
property) from within ZIO context.  However, we already pass down
information on the logical block (including dataset id) as part of the
zbookmark_t.  You could either:

1. Create a SPA-wide hash that allows you to lookup crypto functions
   from arbitrary context without parsing on-disk state.

2. Pass down additional crypto information (a la zbookmark_t) at the
   time each I/O is created.

The latter requires more code but seems cleaner.  You could hack up a
quick prototype just by sticking an extra field in the zbookmark_t,
although you wouldn''t want this as a permanent solution (since the
zbookmark_t is used elsewhere).

- Eric

--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock

Eric Schrock wrote:
> You can''t really do arbitrary DSL operations (such as looking up a
> property) from within ZIO context.  However, we already pass down
> information on the logical block (including dataset id) as part of the
> zbookmark_t.  You could either:
Cool so zbookmark_t is what I thought it was!
> 1. Create a SPA-wide hash that allows you to lookup crypto functions
>    from arbitrary context without parsing on-disk state.
> 
> 2. Pass down additional crypto information (a la zbookmark_t) at the
>    time each I/O is created.
What I''ll do is pass the zbookmark_t to zio_*crypt_data() they can then
call a function in zio_crypt.c that uses the information in the 
zbookmark_t to get hold of the appropriate crypto_key_t pointer.

This function, say zio_crypt_bookmark_to_key() can then be "pluggable"
to support different key management systems - which is something we need 
to be able to do.

The simple case will just be something like a hash table based on the 
dataset id, more complex cases may even initiate network IO to some 
remote key manager (probably by calling up to a userland assistant); 
where remote maybe a specific zone on the machine or really some remote 
key manager over some key exchange protocol).

Thanks.

-- 
Darren J Moffat