blk/kernel: Fix error code mapping in KernelDevice::read.
Reviewed-by: Robin H. Johnson <robbat2@orbis-terrarum.net>
Reviewed-by: Igor Fedotov <igor.fedotov@croit.io>
In response to https://tracker.ceph.com/issues/58173, it would have helped to have the PR label librados test files with core, so the PR would have been tagged for rados qa.
Signed-off-by: Laura Flores <lflores@redhat.com>
There seems to be some extra tabs in rados cppool error message which might confuse users.In reality there should not be any extra spaces on warning messages.
Fixes: https://tracker.ceph.com/issues/58165
Signed-off-by: shreyanshjain7174 <ssanchet@redhat.com>
Note that we are hitting https://tracker.ceph.com/issues/58160 here
because by the time we get to "rbd resize" RAW_DEV mapping owns the
lock (due to a write to /dev/mapper/cryptsetupdev being last).
While at it, resurrect the ability to easily run this script on
vstart clusters -- see commit f737c2855a ("qa/workunits/rbd: make
luks-encryption test work on vstart cluster").
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
If no --encryption-format specified at all, default to "luks" for each
specified --encryption-passphrase-file.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Since RBD_ENCRYPTION_FORMAT_LUKS1, RBD_ENCRYPTION_FORMAT_LUKS2
and RBD_ENCRYPTION_FORMAT_LUKS aren't treated the same when loading
encryption anymore, "luks1" and "luks2" formats need to be accepted
in addition to "luks" format.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Commit 9892ead7fc ("librbd/crypto: allow loading luks format
without specifying version") introduced RBD_ENCRYPTION_FORMAT_LUKS
format identifier, matching cryptsetup's CRYPT_LUKS ("load any LUKS
version happens to be there"). However, in an effort to enable an
obscure "layered encryption with the same passphrase + old QEMU" use
case, it also introduced decaying of RBD_ENCRYPTION_FORMAT_LUKS1 and
RBD_ENCRYPTION_FORMAT_LUKS2 format identifiers, making it impossible
to assert on the format that is being loaded. This new behavior was
then extended to standalone images.
Treating RBD_ENCRYPTION_FORMAT_LUKS1, RBD_ENCRYPTION_FORMAT_LUKS2
and RBD_ENCRYPTION_FORMAT_LUKS the same when loading encryption can
be construed as an opening for a format downgrade attack. Let's
resurrect the previous standalone images behavior and extend it to
layered encryption instead.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
"rbd encryption format" handler sets up a scope guard to zero out
the passphrase string on return but also makes a copy of same which
isn't zeroed out.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
One of the stated goals is compatibility with standard LUKS tools,
in particular being able to load encryption on images formatted with
cryptsetup. cryptsetup doesn't do this and this really interferes
with randomly generated (binary) passphrases.
While at it, open passphrase files as binary -- it communicates the
intent if nothing else on POSIX.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Apply similar "reduce overlap and respect area" logic to places
that don't use prune_parent_extents(). Changes to FlattenRequest
and TrimRequest here should complete the long tail of encrypted
I/O path and flatten fixes.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
DATA area in the parent may be smaller than the part of DATA area in
the clone that is still within the overlap. This would occur e.g. in
LUKS2-formatted parent + LUKS1-formatted clone case, due to LUKS2
header usually being bigger than LUKS1 header:
parent: raw size = 64M
LUKS2 header area = 16M
data area = 48M
clone: raw size = 64M (raw overlap 64M)
LUKS1 header area = 4M
data area = 60M
Currently, because parent extents are pruned only according to raw
overlap (64M), the clone ends up attempting to reach the parent for all
of its data area (60M < 64M) even though the parent only has 48M worth
of data. All kinds of bugs ensue for 48M..60M offsets and this range
basically becomes inaccessible to the user.
A related issue is that prune_parent_extents() ignores area.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
This fixes cases where CRYPTO HEADER area is larger than DATA area.
In particular, it was effectively impossible to flatten unformatted
clones of such images.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
When encryption is loaded, rbd_get_overlap() and Image::overlap() now
return "effective" overlap, similar to rbd_get_size() and Image::size().
Previously, returned overlap could have been bigger than "effective"
size.
Note that get_effective_image_size() successor doesn't take snap_id
because passing anything but ictx->snap_id was broken. Since the size
of the crypto header is stored in the crypto header itself, image areas
are defined only for the "opened at" snap_id. Getting "effective" size
for an arbitrary snapshot requires actually opening it and loading
encryption on it.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Make it clear that get_parent_overlap() returns the raw parent overlap
value (i.e. physical offset into the parent image). Also drop redundant
ceph_mutex_is_locked assert -- get_parent_info() already has one.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
When encryption is loaded, rbd_get_size() and Image::size() return
"effective" size, but rbd_resize() and Image::resize() continue to take
raw size. The user has to constantly keep these domains in mind.
Saying that resize must be done without encryption loaded is not an
answer because shrinking a clone that has snapshots involves copying up
objects in the affected range (identical to flattening). In addition,
even if a clone doesn't have snapshots, shrinking it to a size that
isn't an object boundary is going to involve a copyup for the victim
object as well.
To avoid subtle data corruption on shrink, treat resize operation the
same as flatten operation (including on the CLI).
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Currently it's done in FormatRequest but not in LoadRequest. However
an image can be deep copied or exported and imported with a different
stripe pattern such that an area boundary would fall in the middle of
an object.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Currently it's done in FormatRequest but not in LoadRequest. However
an image can be shrunk to a size such that encryption can loaded (i.e.
enough of the header is still present) but nothing else can, breaking
implicit assumptions all around.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Proceed with formatting an image even if all space would be consumed by
the crypto header. There is no reason to be strict here since we allow
creating zero-sized images as well as shrinking any image to 0.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(Temporarily) shutting down crypto can lead to data corruption in the
face of concurrent I/O, especially when flatten operation is proxied to
the remote lock owner. This was added to be able to read, optionally
modify and write crypto header without it being subjected to remapping
and encryption itself. read_header() and write_header() now achieve
that by specifying CRYPTO_HEADER area explicitly.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
This method doesn't propagate area. Since its only user is
CryptoObjectDispatch which is now applied only to DATA area,
move get_file_offset() there to avoid misuse in the future.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Objects in CRYPTO_HEADER area should not be subjected to encryption.
Unit tests needed adjustment because MockCryptoInterface is configured
with DATA_OFFSET = 4 * 1024 * 1024, thus disqualifying object 0.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
- readahead and PWL cache are limited to DATA area as explained in
the previous commit
- DATA area is assumed for the journal as encryption can't be used
with journaling anyway
To postpone the churn associated with passing area through
ImageDispatchInterface (where only WriteLogImageDispatch and
ImageDispatch care), add a new image dispatch flag.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
