block dangerous passthrough operation

Keith Busch kbusch at kernel.org
Wed Nov 16 08:12:08 PST 2022


On Wed, Nov 16, 2022 at 02:01:00PM +0100, Christoph Hellwig wrote:
> Hi all,
> 
> I recently had to debug some testing code that tried to send fabrics
> commands and caused a major havoc.  This series adds checks for various
> very low-level passthrough commands that have no business sent by anyone
> but the driver itself.  The list might now be complete, so discussion
> is welcome.

People do use the fabrics command for 'get property' to check on their
device, which is a harmless command that you've blocked.

There are still other harmful things a user could do, like Doorbell
Buffer Config or Set Feature Host Memory Buffer that could really screw
things up for the driver. But I think this sets a bad precedence that
the driver is going to protect an admin user from doing stupid things.
As more destructive opcodes and features are added in the future, we'd
be taking on a maintenance burden to analyze all these. Meanwhile, older
drivers won't provide that protection, so the user is expected to simply
not do such actions, so why can't they just do that now?

There's nothing preventing a vendor specific command from being just as
destructive either, but you can't realistically fence those off either.
I've always said the driver should not police this user interface as
that inevitably gets in the way of its flexibility.



More information about the Linux-nvme mailing list