F41 Change Proposal: Self Encrypting Drives Support in the Installer (self-contained)

Project Discussion Change Proposals
,
1

Self Encrypting Drives Support in the Installer

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

Add optional support for using native hardware encryption on TCG OPAL2 compliant drives when configuring disk encryption in the installer.

:link: Owner

:link: Detailed Description

Some SATA and NVMe devices support hardware encryption (TCG OPAL2 standard) and with the latest cryptsetup LUKS devices can be configured to use hardware encryption to encrypt the data either by itself or together with the existing dm-crypt software encryption. Support for this feature was added in the latest cryptsetup upstream release and we’d like to provide an option for users to use this feature when installing Fedora with disk encryption.

As this is an expert option, it will be available only through the kickstart interface. The existing --luks-version option which allows choosing between LUKS1 and LUKS2 versions when configuring device encryption will be extended to enable using hardware encryption. There will be two new options to select either hardware encryption only or hardware encryption in combination with software encryption (analogous to the --hw-opal-only and --hw-opal options used when configuring hardware encryption with cryptsetup).

Using hardware encryption only can be beneficial on low-performance systems where utilising the CPU to encrypt the data when reading/writing from/to the disk can significantly affect the system’s performance. Using both software and hardware encryption layers increases the security margin by adding an additional layer of protection.

Note: We’d like to emphasize that we do not intend to enable this feature by default, it must be explicitly selected by the user. Using the option to set up only hardware encryption can be risky as it places the trust fully in the disk manufacturer’s ability to implement the data encryption in the disk firmware correctly.

:link: Benefit to Fedora

:link: Scope

  • Proposal owners:

    • This feature is not yet implemented in the upstream so we’ll need to add support for the new LUKS-OPAL format to both the backend storage libraries (blivet and libblockdev) and the installer itself. As this is only expanding and existing feature (disk encryption) already present in the installer, the changes will be relatively small (especially in the installer itself).

  • Other developers:

    • No work from other developers should be needed.

  • Release engineering: #Releng issue number

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy:

:link: Upgrade/compatibility impact

This change will affect only new installations.

:link: How To Test

A special hardware is required for testing – you need a disk that supports the OPAL specification. You can check for OPAL support using the sedutil-cli utility (provided by the sedutil package), simply run sudo sedutil-cli --scan to scan for OPAL compliant disks.

Because this feature is not configurable from the GUI you need to run a kickstart installation. Sample kickstart file for encrypted automatic partitioning is shown below.

autopart --type=lvm --encrypted --passphrase=“passphrase” --luks-version=luks2-hw-opal --opal-admin-passphrase=“…”

(The exact syntax might change, we’ll provide more detailed kickstart files for testing later.)

After the installation check that the correct setup for LUKS was used by running sudo cryptsetup luksDump <device>. Check the Data segments section, it should say either hw-opal-crypt for combination of hardware and software encryption

LUKS header information Version: 2 … Data segments: 0: hw-opal-crypt

or hw-opal for hardware encryption only

LUKS header information Version: 2 … Data segments: 0: hw-opal

(crypt is shown for software encryption only which is default behaviour).

:link: User Experience

After the installation users shouldn’t notice any differences, the system will behave in the same way as with “normal” disk encryption.

:link: Dependencies

Following projects needs to be changed for this feature: anaconda, blivet, kickstart, libblockdev. All necessary changes will be done by the change owners.

cryptsetup with the LUKS-OPAL support is already available in Fedora 41 and no other changes will be needed for the support in the installer.

Once configured the LUKS-OPAL device works in the same way any other “normal” LUKS devices work so there is no need to change any other tools for this feature to work (e.g. unlocking the LUKS-OPAL device doesn’t require special configuration).

:link: Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
    • No specific contingency plan is needed, we will simply not include the feature if we fail to implement all the necessary changes in time.
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? No

:link: Documentation

:link: Release Notes

Last edited by @amoloney 2024-07-12T15:59:50Z

3 Likes
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply giving that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

Question: if this is done in hardware, is the algorithm embedded in the firmware? Are these devices supported by fwupd? Otherwise they may get a security flaw which is not patchable

4

if this is done in hardware, is the algorithm embedded in the firmware?

Yes.

Are these devices supported by fwupd?

As always depends on the vendor and device. For example Lenovo provides firmware updates through fwupd and that includes firmware updates for the NVMe drives. Just a quick look at the latest updates on fwupd.org shows some firmware updates from Dell for Micron SSDs that also support OPAL. So there are vendors that provide firmware updates but there definitely are some that don’t.

1 Like
5

Thanks! I would include a warning about this in the docs :slight_smile:

1 Like
6

Which Doc ?

7

The docs that have to be made if this gets accepted :wink:

2 Likes
8

FWIW I have implemented this in the Debian Installer (for the next Debian release) in pretty much the same way - an “expert only” option in the partition menu, that is not visible in the default guided installation screen, and allows choosing between hw-only and hw+sw.

3 Likes
9

Having systemd-homed support is really a good option as having a encrypted system is not that important rather having encrypted vaulted home drive makes it better suited it maybe look like a android modern android os

10

This change proposal has now been submitted to FESCo with ticket #3250 for voting.

To find out more, please visit our Changes Policy documentation.

1 Like
11

This change has been accepted by FESCo for Fedora Linux 41. A full list of approved changes to date can be found on the Change Set Page.

To find out more about how our changes policy works, please visit our docs site.

12

I’m not sure if this is the correct place to report issues, although isn’t an implementation issue, so please direct me as needed.

I was trying out the HW OPAL installation - ran a regular installation to get a kickstart file, modified it with encryption parameters, reset the drive to HW defaults (I’ve tried with both sedutil and crypsetup, tried setting admin password with sedutil) but it was giving me weird errors.
Turns out I had to reset the drive without powering it down, so in the same boot, before running any cryptsetup commands via kickstart.

I am not sure if all drives are like this (but it does corellate with drive locking semantics), since I did not have any prior experience/knowledge it took me quite some time to figure it out.

I think this should be mentioned in the documentation somewhere (specifics of factory reset) - at least in this change and maybe in kickstart docs as well?

What I ended up doing was kickstart %pre script that reset the drive on the same boot before the installation.
The drive in question is Samsung 990 PRO.

Thanks!

13

Unfortunately hardware encryption with Samsung 990 is broken, I’ve asked cryptsetup developers and they’ve seen similar issues with this drive during testing and development. And even BitLocker has problems with this drive so there’s unfortunately nothing we can do. Interestingly other Samsung drives from the 900 series work fine, it’s just 990 that behaves this way.

1 Like
14

Thanks!
What a mess… disappointing to find this out after purchase :frowning:
But it does seem to work now… should I be worried?
I guess I should look for information in cryptsetup community communication channels?

15

I would probably stick to the software encryption only with this drive. It’s probably just the PSID reset behaving weirdly and the rest is working, but I wouldn’t risk it personally – if something goes wrong later recovering the data would be impossible.

1 Like
16

You can ask on our cryptsetup list, but the answer will be this:

It is not a problem in cryptsetup, but in the kernel - we just use kernel SED-ioctl, which behaves wrongly on the 990 models. Samsung 980 (both normal and PRO) works without issues.

If you reset it through PSID and configure it, it will work (for one luksFormat). It looks like 990 cannot use configured credentials later. Any subsequent reformat fails.

I will perhaps report it to Samsung, but I doubt they will fix it, as it seems 990 is no longer presented on the product pages. There are more older models that claim Opal2 support but are broken (Samsung all 840 and 850 PRO SSD cannot be used for cryptsetup; surprisingly, 850 EVO works - all have broken firmware).

2 Likes
17

I’ve just tried encrypting another partition and it has worked… So maybe it is indeed PSID revert behaving differently. It accepts HW passphrase now and everything seems to work fine :sweat_smile: