My mistake, I meant image id. Yesterday I decided to put en/decryption into rbd_queue_rq() and process data while traversing buffer_head structures. Do not worry, I am very much aware of Never Roll Out Your Own Crypto :), this is not my idea though. I am just working on someone else's idea.
Thanks for your help.
>
> Thanks for swift answer.
>
> (This is my usage in librbd.cc)
>
> Basically there is a folder with symmetric keys used for block encryption, one key for one disk in some pool. For identification of key I need (pool_id, disk_id) of block. I am temporarily saving key to librbd::ImageCtx structure, so I don't have to get it from file every time. I use this key to encrypt/decrypt block data. Encrypt/decrypt is primitive, I'm not gonna mention it here, but it is done over the data provided by functions rbd_read() and rbd_write().
>
> If you could point how to edit rbd.c content to achieve similar behaviour, I would be much obliged.
I'm not sure what exactly you mean by disk id, but I assume image
id (displayed by "rbd info" in block_name_prefix field) is probably
part of that. It is looked up in rbd_dev_image_id(), called from
rbd_dev_image_probe(). More generally, do_rbd_add() is roughly
equivalent to rbd_open() in librbd. Everything related to "opening"
the image is done in or under do_rbd_add().
struct rbd_device is passed pretty much everywhere, so if you are
storing a key in librbd::ImageCtx, struct rbd_device is probably
the place to put it.
As for encryption, the easiest would probably be to stick it into
__rbd_img_fill_request(). But I want to stress that bolting on
your own crypto is very error-prone and highly unlikely to produce
anything remotely secure. Unless you are doing it to get familiar
with the codebase or just for fun, I would advise against it.
Thanks,
Ilya
