[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20251216064313.69144-1-qu@darknavy.com>
Date: Tue, 16 Dec 2025 14:43:13 +0800
From: Shipei Qu <qu@...knavy.com>
To: 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,
qu@...knavy.com
Subject: Re: [PATCH v2] scsi: 3w-sas: validate request_id reported by controller
Hi James,
> Realistically the same rationale goes for us as well. Absent the
> observation in the field of a problem device, we usually trust the
> hardware, so unless you can find an actual device that exhibits the
> problem this isn't really a fix for anything.
>
> If the security@ list is happy that the existing trust model for
> Thunderbolt/PCIe would prevent the attachment of malicious devices,
> then I think we're also happy to take their word for it. Even if
> thunderbolt were a security problem, the fix would likely be in the
> trust model not in all possible drivers.
Thanks for the feedback. We understand and respect the current trust
model (drivers assume trusted hardware), so no objections if you prefer
not to take the patch under that model.
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.
Thanks,
Shipei
Powered by blists - more mailing lists