From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Shipei Qu <qu@darknavy.com>, 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
Subject: Re: [PATCH v2] scsi: 3w-sas: validate request_id reported by controller
Date: Tue, 16 Dec 2025 08:03:31 +0100 [thread overview]
Message-ID: <0edfb805ffbaa352a1f78c9533501a1f7805f902.camel@HansenPartnership.com> (raw)
In-Reply-To: <20251216064313.69144-1-qu@darknavy.com>
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
next prev parent reply other threads:[~2025-12-16 7:03 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
2025-12-16 7:03 ` James Bottomley [this message]
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=0edfb805ffbaa352a1f78c9533501a1f7805f902.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.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=qu@darknavy.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®