From: Shipei Qu <qu@darknavy.com>
To: jejb@linux.ibm.com
Cc: martin.petersen@oracle.com, aradford@gmail.com,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
vr@darknavy.com, qu@darknavy.com
Subject: Re: [PATCH v2] scsi: 3w-sas: validate request_id reported by controller
Date: Tue, 16 Dec 2025 14:43:13 +0800 [thread overview]
Message-ID: <20251216064313.69144-1-qu@darknavy.com> (raw)
In-Reply-To: <27297f052a89a5e171bad743dd59f39a339ce126.camel@HansenPartnership.com>
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
next prev parent reply other threads:[~2025-12-16 6:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-16 6:01 Shipei Qu
2025-12-16 6:18 ` James Bottomley
2025-12-16 6:43 ` Shipei Qu [this message]
2025-12-16 7:03 ` James Bottomley
2025-12-20 14:00 ` kernel test robot
2025-12-20 14:34 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251216064313.69144-1-qu@darknavy.com \
--to=qu@darknavy.com \
--cc=aradford@gmail.com \
--cc=jejb@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=vr@darknavy.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®