linux-kernel - [PATCH v3 0/1] scsi: ufs: Add crypto_keyslot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251128033709.1342579-1-zheng.gong@samsung.com>
Date: Fri, 28 Nov 2025 11:37:08 +0800
From: "zheng.gong" <zheng.gong@...sung.com>
To: linux-scsi@...r.kernel.org
Cc: avri.altman@....com, bvanassche@....org, quic_cang@...cinc.com,
	alim.akhtar@...sung.com, martin.petersen@...cle.com, ebiggers@...nel.org,
	linux-kernel@...r.kernel.org, "zheng.gong" <zheng.gong@...sung.com>
Subject: [PATCH v3 0/1] scsi: ufs: Add crypto_keyslot_remap variant op

Thank you very much for your feedback, Eric. I truly appreciate your review and the time you've taken to point out that a real user is required.
You're right. Adding a new variant op without a clear use case would not be acceptable. Let me clarify the context behind this patch.

This hook is not theoretical. It is designed to replace an existing out-of-tree variant op (`crypto_keyslot_cfg`) used in Samsung's ExynosAuto UFS driver for multi-VM inline encryption.
In production, each VM has its own keyslot range per hardware allocation, and the keyslot is remapped at request time:

    lrbp->crypto_key_slot += vm_id * UFS_KEYSLOTS;

This was already in use on automotive platforms.

But the reason this usage isn't visible in mainline is due to ExynosAuto's kernel architecture:

Starting from kernel 6.1, we adopt the dual-repository model (similar to Android Common Kernel):
- `kernel.git`: Mainline-based, minimal patches
- `exynosauto-modules.git`: Hosts platform-specific drivers (as .ko or built-in)

Our UFS driver, including FMP and IOV support, resides in `exynosauto-modules/drivers/ufs/*`. It couldnot be upstreamed due to:
- Hardware-specific SMC calls
- Security-specific key management
- Non-public register interfaces

Despite this, we aim to minimize out-of-tree divergence by upstreaming reusable hooks like this one.

Purpose of the Patch
This change:
- Replaces the private `crypto_keyslot_cfg` with a clean, upstreamable interface
- Eliminates the need for out-of-tree patching
- Reduces rebase effort across kernel versions
- Maintains backward compatibility (no impact if not implemented)

Design Principles
- Minimal: only adds one callback
- Reusable: fits existing `variant_ops` model
- Non-intrusive: no changes to core crypto logic
- Generic: can support virtualization, multi-domain, or security-isolated keyslots

While `ufs-exynosauto.c` is separate from mainline `ufs-exynos.c`, they share the same goal: enabling robust UFS support on Exynos platforms. This hook benefits not only us, but potentially other vendors with similar scenrios.
I'm fully open to feedback. If there are concerns about naming, placement, or future-proofing, i`m happy to adjust.

Thank you again for your guidance. I hope this explanation helps bridge the context gap while supporting real-world use cases.

Changes since v2:
  - Removed test module (ufshcd-crypto-test.c) per feedback
  - Clarified that this hook replaces an existing out-of-tree feature

zheng.gong (1):
  scsi: ufs: crypto: Add ufs_hba_variant_ops::crypto_keyslot_remap

 drivers/ufs/core/ufshcd-crypto.h | 10 ++++++++--
 drivers/ufs/core/ufshcd.c        |  9 +++++----
 include/ufs/ufshcd.h             |  6 ++++++
 3 files changed, 19 insertions(+), 6 deletions(-)

-- 
2.50.1