linux-kernel - Re: [PATCH v2] scsi: 3w-sas: validate request

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] [day] [month] [year] [list]

Message-ID: <0edfb805ffbaa352a1f78c9533501a1f7805f902.camel@HansenPartnership.com>
Date: Tue, 16 Dec 2025 08:03:31 +0100
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Shipei Qu <qu@...knavy.com>, jejb@...ux.ibm.com
Cc: martin.petersen@...cle.com, aradford@...il.com,
 linux-scsi@...r.kernel.org,  linux-kernel@...r.kernel.org, vr@...knavy.com
Subject: Re: [PATCH v2] scsi: 3w-sas: validate request_id reported by
 controller

On Tue, 2025-12-16 at 14:43 +0800, Shipei Qu wrote:
[...]
> For context: some confidential-computing / virtualized deployments
> include a hostile or compromised VMM or passthrough device in the
> threat model, so bounds checks can reduce crash surface when the
> device isn't fully trusted. But if that's outside upstream scope
> here, we're fine either way. Thanks for the clarification.


We already had a massive fight over hardening device drivers for
confidential computing:

https://lore.kernel.org/all/20230327141816.2648615-1-carlos.bilbao@amd.com/

The summary is that if you can't trust the hardware or its emulation,
policing it is too huge a burden to place on ordinary drivers.  So
while there's no objection to specifically hardened drivers for
confidential computing, generally we don't add hardening to real
hardware drivers because it tanks performance.

Regards,

James