rbd: add EncryptionLoad2 implementing rbd_encryption_load2 #1061
Conversation
phlogistonjohn
added
the
API
|
I'm looking to add a 2nd test, one that actually tests the use of multiple encryption specs, but I haven't found any good examples yet. In the meantime, while it's still draft, I figured I'd get a test run out of what I have already. |
phlogistonjohn
force-pushed
the
jjm-rbd-enc-load2-1059
branch
from
42c3ed6 to
3aa05cc
Compare
|
Additional test added. |
Fix a couple of comments to make them a bit more accurate. They were probably true at one point in the development of the feature but now referred to functions that don't exist. Signed-off-by: John Mulligan <[email protected]>
Restructure the existing rbd encryption load test function so that it makes use of defer and uses subtests to divide things up more clearly. I needed to make this change in preparation for adding a binding for rbd_encryption_load2 and a similar test - but I couldn't make sense of the existing test in it's more monolithic form. Signed-off-by: John Mulligan <[email protected]>
phlogistonjohn
force-pushed
the
jjm-rbd-enc-load2-1059
branch
from
3aa05cc to
f197e5a
Compare
There was a problem hiding this comment.
I've made few suggestions, all along the same pattern, to some of the length comparison assert statements. Somehow I feel like comparing the length of data read with the length of prior(fixed) data to make more sense than comparing it with the length of read buffer for img.ReadAt(). WDYT?
Add a new Image method EncryptionLoad2 implementing rbd_encryption_load2. This method adds the ability to have different encryption schemes across parent images. Signed-off-by: John Mulligan <[email protected]> Fixes: ceph#1059
Add EncryptionOptionsLUKS type for opening, but not formatting, existing LUKS images generically. Signed-off-by: John Mulligan <[email protected]>
phlogistonjohn
force-pushed
the
jjm-rbd-enc-load2-1059
branch
from
f197e5a to
bef69a2
Compare
|
There must be something else wrong with this change as other old tests are now panicking a bunch, I filed #1063 just to see if this was something pre-existing but those all passed without so much as a poke needed (earlier this week some of the dnf mirrors were being flaky). Unfortunately, I thought this would be a quick and easy thing to add, but I guess not. |
| }, | ||
| { | ||
| "name": "Image.EncryptionLoad2", | ||
| "comment": "EncryptionLoad2 enables IO on an open encrypted image. The difference\nbetween EncryptionLoad and EncryptionLoad2 is that EncryptionLoad2 can open\nancestor images with a different encryption options than the current image.\nThe first EncryptionOptions in the slice is applied to the current image,\nthe second to the first ancestor, the third to the second ancestor and so\non. If the length of the slice is smaller than the number of ancestors the\nfinal item in the slice will be applied to all remaining ancestors, or if\nthe ancestor does not match the encryption format the ancestor will be\ninterpreted as plain-text.\n\nImplements:\n\n\tint rbd_encryption_load2(rbd_image_t image,\n\t const rbd_encryption_spec_t *specs,\n\t size_t spec_count);\n", |
There was a problem hiding this comment.
or if the ancestor does not match the encryption format the ancestor will be interpreted as plain-text.
... only if the encryption format is not known to librbd at all. If e.g. LUKS1 is specified in EncryptionOptions that is being reused but the image has a LUKS2 header (i.e. known to librbd), EncryptionLoad2 would fail. I'd suggest copying librbd.h comment as close as possible -- don't omit anything and make adjustments only for encryption spec -> EncryptionOptions, array -> slice, etc.
There was a problem hiding this comment.
don't omit anything
Or alternatively don't go into details -- keeping just the first two sentences would be fine.
There was a problem hiding this comment.
Eh, ok. I'll update this later to err on the side of being vague.
|
|
||
| // EncryptionOptionsLUKS generic options for either LUKS v1 or v2. May only be | ||
| // used for opening existing images - not valid for the EncryptionFormat call. | ||
| type EncryptionOptionsLUKS struct { |
There was a problem hiding this comment.
Nit: I'd place both this and EncryptionLoad2 implementation in encryption.go, so that that all LUKS structs and related APIs are together.
There was a problem hiding this comment.
Thanks for the suggestion, but that would violate the project's workflow and ability to build on older ceph releases using go build tags. Because of user demand we support older ceph versions. Merging this newer code into encryption.go would break the ability to build against things prior to reef (Go eschews IFDEFs, it accomplishes similar stuff with build tags which than implies adding additional files).
There was a problem hiding this comment.
I see, thanks for the explanation. Since both encryption_opt_luks.go and encryption_load2.go have the same go build tag, perhaps merge them into a single encryption_reef.go file then?
Feel free to just resolve this thread with no further comment if the way it is is preferred ;)
Add a new Image method EncryptionLoad2 implementing rbd_encryption_load2.
This method adds the ability to have different encryption schemes across
parent images.
Fixes: #1059
Checklist
//go:build ceph_previewmake api-updateto record new APIsNew or infrequent contributors may want to review the go-ceph Developer's Guide including the section on how we track API Status and the API Stability Plan.
The go-ceph project uses mergify. View the mergify command guide for information on how to interact with mergify. Add a comment with
@Mergifyiorebaseto rebase your PR when github indicates that the PR is out of date with the base branch.