linux-kernel - Re: [PATCH 1/1] scsi: ufs: core: Fix error handler encryption support

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: <54d824db-ec39-447c-8eab-6c2ce4ca87a6@acm.org>
Date: Mon, 15 Dec 2025 08:47:03 -0800
From: Bart Van Assche <bvanassche@....org>
To: Christoph Hellwig <hch@...radead.org>
Cc: Po-Wen Kao <powenkao@...gle.com>,
 "James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
 "Martin K. Petersen" <martin.petersen@...cle.com>,
 "open list:UNIVERSAL FLASH STORAGE HOST CONTROLLER DRIVER"
 <linux-scsi@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] scsi: ufs: core: Fix error handler encryption support

On 12/14/25 9:58 PM, Christoph Hellwig wrote:
> On Wed, Dec 10, 2025 at 09:44:52AM -0800, Bart Van Assche wrote:
>> On 12/9/25 10:48 PM, Christoph Hellwig wrote:
>>> As mentioned last round, why are you even calling into the crypto
>>> code here?  Calling that for a request without a crypt context,
>>> which includes all of them that do not transfer any data makes no
>>> sense to start with.
>>
>> ufshcd_prepare_lrbp_crypto() only has one caller. Moving the new test
>> from inside ufshcd_prepare_lrbp_crypto() into its caller should be easy.
> 
> I don't think callers vs calle is the important part here.  It is to
> check if any actual data is tranferred instead of special casing EH
> commands.

Hi Christoph,

Do you agree with the following?

(a) There is code in the SCSI error handler that submits SCSI commands
     with a data buffer. Hence, disabling encryption if and only if the
     data buffer length is zero can't fix the reported problem. From
     scsi_eh_prep_cmnd() in drivers/scsi/scsi_error.c:

		scmd->sdb.length = min_t(unsigned, SCSI_SENSE_BUFFERSIZE,
					 sense_bytes);
		sg_init_one(&ses->sense_sgl, scmd->sense_buffer,
			    scmd->sdb.length);
		scmd->sdb.table.sgl = &ses->sense_sgl;

(b) In general in the Linux kernel it is strongly preferred to fix the
     root cause of a bug rather than to implement a workaround. This is
     preferred because it makes kernel code easier to maintain and
     reduces the chance that new bugs are introduced.

(c) Disabling encryption in the UFS driver if a command has been
     submitted by the SCSI error handler is a workaround. Patch [1] fixes
     the root cause of the problem, namely the SCSI error handler not
     setting the encryption fields in struct request correctly. We prefer
     [1] because UFS devices that support one million IOPS are expected
     to arrive soon (early 2026). Hence the importance of keeping the hot
     path in the UFS driver fast.

Thanks,

Bart.

[1] [PATCH v2 1/1] scsi: core: Fix error handler encryption support
  
(https://lore.kernel.org/linux-scsi/20251203073310.2248956-1-powenkao@google.com/)