Bug 2159581
| Summary: | nbdkit command was killed by signal 11 when use luks filter to read LUKS-encrypted disk image | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | mxie <mxie> | ||||
| Component: | nbdkit | Assignee: | Richard W.M. Jones <rjones> | ||||
| Status: | CLOSED ERRATA | QA Contact: | mxie <mxie> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 9.2 | CC: | chhu, eblake, hongzliu, juzhou, lersek, mzhan, rjones, tyan, tzheng, virt-maint, vwu, xiaodwan | ||||
| Target Milestone: | rc | Keywords: | Triaged | ||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | nbdkit-1.32.5-4.el9 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2023-05-09 07:47:50 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
mxie@redhat.com
2023-01-10 03:20:22 UTC
A note about this step:
> 2.2 Use nbdkit luks filer to read the disk image which is copied by nbdcopy
> # nbdkit file data.img --filter=luks passphrase=LETMEPASS --run 'nbdcopy $nbd data-b.img'
Note that 'data.img' is *not* encrypted. In step 2.1 you copied
out the unencrypted content into a new unencrypted image. So
applying the luks filter here will always give an error.
However it should not crash and I have fixed that.
Test the bug with nbdkit-1.32.5-3.el9.x86_64
Steps
1. Prepare a LUKSv1-encrypted image which is converted from VMware by v2v
2. Use nbdkit luks filer to read the disk image
# nbdkit file esx6.7-rhel7.8-swap_lvm_luks-redhat123-sda --filter=luks passphrase=+/home/diskpw --filter=partition partition=1 --run 'nbdinfo $uri'
nbdkit: file[1]: error: this disk does not contain a LUKS header
nbdkit: file[1]: error: this disk does not contain a LUKS header
nbdinfo: nbd_opt_go: server replied with error to opt_go request: No such file or directory for the default export
nbdinfo: suggestion: to list all exports on the server, use --list
protocol: newstyle-fixed without TLS, using structured packets
Hi Richard,
Why can't the luks filter open the LUKS encrypted disk image in the previous step? The luks filter man page says that it is compatible with LUKSv1, from the screenshot we can see the luks version of this disk is 1 and luks header is '/dev/mapper/rhel-swap'. Or is above command correct? Please give me some suggestions, thanks
The error is saying it's not a LUKSv1 disk image. How was it prepared? (In reply to Richard W.M. Jones from comment #5) > The error is saying it's not a LUKSv1 disk image. How was it prepared? The partition is encrypted during OS installation, do LUKSv1 disk images have to be created by qemu command? The luks filter is being applied to the whole disk (not to a single partition). In addition most modern operating systems use LUKSv2, which this filter does not support. Although it might be possible to create an encrypted disk which is compatible with this filter when installing the OS, it's usually better to think of the luks filter as something which is applied outside the guest and which the guest is unaware of. The guest sees an unencrypted disk at all times. The host / hypervisor does the encryption and keeps the key. This is also how disk encryption is meant to be used with the qemu tools (which are compatible with the luks filter). Thanks for explanation, the bug has been fixed because luks filter won't crash when image does not contain a LUKS header Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (nbdkit bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2023:2347 |