| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based on documentation SCSI Primary Commands - 4 (SPC-4) only first 7 bits
of first byte in sense data are used to store response code. The current
verification uses all 8 bits for comparison of response code.
Incorrect verification may make impossible to use SATA disks with IMSM,
because IMSM requires verification of the encryption state before use.
There was issue in kernel libata [1]. This issue hides bug in mdadm because
last bit was not set.
Example output with affected mdadm:
Port3 : /dev/sde (BTPR212503EK120LGN)
mdadm: Failed ata passthrough12 ioctl. Device: /dev/sde.
mdadm: Failed to get drive encryption information
The fix is use the first 7 bits of Byte 0, to compare with the expected
values.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/libata/linux.git/commit/?id=38dab832c3f4
Fixes: df38df3052c3 ("Add reading SATA encryption information")
Signed-off-by: Blazej Kucman <blazej.kucman@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Casting void pointer to __u64 works for 64-bit arch but fails to compile
on 32-bit arch like i686.
Fail on i686 platform:
drive_encryption.c: In function ‘nvme_security_recv_ioctl’:
drive_encryption.c:236:25: error: cast from pointer to integer of
different size [-Werror=pointer-to-int-cast]
236 | nvme_cmd.addr = (__u64)response_buffer;
| ^
drive_encryption.c: In function ‘nvme_identify_ioctl’:
drive_encryption.c:271:25: error: cast from pointer to integer of
different size [-Werror=pointer-to-int-cast]
271 | nvme_cmd.addr = (__u64)response_buffer;
| ^
cc1: all warnings being treated as errors
make: *** [Makefile:211: drive_encryption.o] Error 1
This change adds cast void pointer to uintptr_t first to ensure that
proper pointer size is used for casting from pointer type. Then is safe to
cast it to __u64 because it is tracked as u_int, regardless it is 32-bit
or 64-bit arch.
Reported-by: Xiao Ni <xni@redhat.com>
Fixes: cc48406887b3 ("Add reading Opal NVMe encryption information")
Signed-off-by: Blazej Kucman <blazej.kucman@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Print SATA/NVMe disk encryption information in --detail-platform.
Encryption Ability and Status will be printed for each disk.
There is one exception, Opal SATA drives encryption is not checked when
ENCRYPTION_NO_VERIFY key with "sata_opal" value is set in conf, for this
reason such drives are treated as without encryption support.
To test this feature, drives SATA/NVMe with Opal support or SATA drives
with encryption support have to be used.
Example outputs of --detail-platform:
Non Opal, encryption enabled, SATA drive:
Port0 : /dev/sdc (CVPR050600G3120LGN)
Encryption(Ability|Status): Other|Unlocked
NVMe drive without Opal support:
NVMe under VMD : /dev/nvme2n1 (PHLF737302GB1P0GGN)
Encryption(Ability|Status): None|Unencrypted
Unencrypted SATA drive with OPAL support:
- default allow_tpm, we will get an error from mdadm:
Port6 : /dev/sdi (CVTS4246015V180IGN)
mdadm: Detected SATA drive /dev/sdi with Trusted Computing support.
mdadm: Cannot verify encryption state. Requires libata.tpm_enabled=1.
mdadm: Failed to get drive encrytpion information.
- default "allow_tpm" and config entry "ENCRYPTION_NO_VERIFY sata_opal":
Port6 : /dev/sdi (CVTS4246015V180IGN)
Encryption(Ability|Status): None|Unencrypted
- added "libata.allow_tpm=1" to boot parameters(requires reboot),
the status will be read correctly:
Port6 : /dev/sdi (CVTS4246015V180IGN)
Encryption(Ability|Status): SED|Unencrypted
Signed-off-by: Blazej Kucman <blazej.kucman@intel.com>
Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add ENCRYPTION_NO_VERIFY config key and allow to disable checking
encryption status for given type of drives.
The key is introduced because of SATA Opal disks for which TPM commands
must be enabled in libata kernel module, (libata.allow_tpm=1), otherwise
it is impossible to verify encryption status. TPM commands are disabled by
default.
Currently the key only supports the "sata_opal" value, if necessary,
the functionality is ready to support more types of disks. This
functionality will be used in the next patches.
Signed-off-by: Blazej Kucman <blazej.kucman@intel.com>
Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Functionality reads information about SATA disk encryption. Technical
documentation used is given in the implementation.
The implementation is able to recognized two encryption standards for SATA
drives, OPAL and ATA security.
If the SATA drive supports OPAL, encryption status and ability are
determined based on Opal Level 0 discovery response, for ATA security,
based on ATA identify response. If SATA supports OPAL, ability is set to
"SED", for ATA security to "Other".
SED(Self-Encrypting Drive) is commonly used to describe drive which using
OPAL or Enterprise standards developed by Trusted Computing Group. Ability
"Other" is used for ATA security because we rely only on information from
ATA identify which describe the overall state of encryption.
It is allowed to mix disks with different encryption ability such as "SED"
and "Other" and it is not security gap.
Motivation for adding this functionality is to block mixing of disks in
IMSM arrays with encryption enabled and disabled. The main goal is to not
allow stealing data by rebuilding array to not encrypted drive which can be
read elsewhere.
For SATA Opal drives, libata allow_tmp parameter enabled is required, which
is necessary for Opal Security commands to work, therefore, if the
parameter is not enabled, SATA Opal disk cannot be used in case the
encryption will be checked by metadata.
Implemented functions will be used in one of the next patches. In one of
the next patches, a flag will be added to enable disabling SATA Opal
encryption checking due to allow_tpm kernel setting dependency.
Signed-off-by: Blazej Kucman <blazej.kucman@intel.com>
Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
|
|
|
For NVMe devices with Opal support, encryption information, status and
ability are determined based on Opal Level 0 discovery response. Technical
documentation used is given in the implementation.
Ability in general describes what type of encryption is supported, Status
describes in what state the disk with encryption support is. The current
patch includes only the implementation of reading encryption information,
functions will be used in one of the next patches.
Motivation for adding this functionality is to block mixing of disks in
IMSM arrays with encryption enabled and disabled. The main goal is to not
allow stealing data by rebuilding array to not encrypted drive which can be
read elsewhere.
Value ENA_OTHER from enum encryption_ability will be used in the next
patch.
Signed-off-by: Blazej Kucman <blazej.kucman@intel.com>
Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
|
