From Fedora Project Wiki
No edit summary
No edit summary
Line 59: Line 59:


== Scope ==
== 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).
* 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.
* Other developers:
** No work from other developers should be needed.


* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
Line 77: Line 79:


== How To Test ==
== How To Test ==
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  This can be based off of the above section if early testing has been completed. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be.  
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 [[Anaconda/Kickstart|kickstart installation]]. Sample kickstart file is displayed below.


Remember that you are writing this how to for interested testers to use to check out your change implementation - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your change.
TODO


A good "how to test" should answer these four questions:
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


0. What special hardware / data / etc. is needed (if any)?
  LUKS header information
1. How do I prepare my system to test this change? What packages
  Version:        2
need to be installed, config files edited, etc.?
    ...
2. What specific actions do I perform to check that the change is
  Data segments:
working like it's supposed to?
    0: hw-opal-crypt
3. What are the expected results of those actions?
-->


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.
or `hw-opal` for hardware encryption only


Because this feature is not configurable from the GUI you need to run a [[Anaconda/Kickstart|kickstart installation]]. Sample kickstart file is displayed below.
  LUKS header information
  Version:        2
    ...
  Data segments:
      0: hw-opal


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


== User Experience ==
== User Experience ==
Line 112: Line 118:


* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
** 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)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? No
* Blocks release? No


== Documentation ==
== Documentation ==

Revision as of 08:58, 11 July 2024


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.

Summary

Add optional support for using native hardware encryption on drives that provide an OPAL interface when configuring disk encryption in the installer.

Owner

Current status

  • Targeted release: Fedora Linux 41
  • Last updated: 2024-07-11
  • [Announced]
  • [<will be assigned by the Wrangler> Discussion thread]
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

Some SATA and NVMe devices support hardware encryption through the OPAL2 TCG interface and with the latest cryptsetup the OPAL interface can be used to configure LUKS devices to use hardware encryption to encrypt the data either by itself or together with the existing dm-crypt software encryption. 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 will be extended to allow configuring hardware encryption as an addition to the software encryption layer or to select hardware encryption only.

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

Note: We'd like to emphasis that we do not intent 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 manufacturers ability to implement the data encryption in the disk firmware correctly. There are known instances of security issues in the hardware encryption implementations.

Benefit to Fedora

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.
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with the Fedora Strategy:

Upgrade/compatibility impact

This change will affect only new installations.

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 is displayed below.

TODO

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).

User Experience

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

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).

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

Documentation

Release Notes