nvme-host: disk corruptions when issuing IDENTIFY commands via ioctl()

[Keith Busch]

On Wed, Mar 09, 2022 at 07:26:30AM +0100, Christoph Hellwig wrote:
> On Tue, Mar 08, 2022 at 05:45:20PM +0100, Maurizio Lombardi wrote:
> > We suspect that the root cause is that the nvme-host driver doesn't
> > enforce the 4096 byte limit for the IDENTIFY commands as the
> > nvme-target does (see the nvmet_execute_identify() -->
> > nvmet_check_transfer_len(req, NVME_IDENTIFY_DATA_SIZE) code).
> > So if we pass a 8192-byte buffer not aligned to the page size, it will
> > need 3 pages on archs where page size is 4k and the nvme spec says
> > that the data buffer may not cross more than one page boundary.
> > 
> > Does it make sense to you? What's your opinion on this?
> 
> Combination of a broken application (does what the spec explicitly
> tells it not do) and broken hardware (does the most stupid thing when
> fed invalid input), not much the driver can do here.

There's nothing the hardware can do either to know it was given invalid
input here if PRP2 is page aligned. There's no way it can tell the
difference between a PRP List vs PRP destination.

> But we really should talk to the nvme working group to ECN the text
> for the single PRP requirement to spell out the consequence in more
> detail, and maybe also mandate how it is handled for the next spec
> version.

It's not a "single PRP requirement". The spec just says the "data
structure is 4096 bytes". This can validly span 2 PRPs if the first one
has a non-zero offset.

The spec created the "NDT" command field to help detect mismatched
host/device PRP expectations. Unfortunately it only applies to
vendor-specific commands, and no one implemented it anyway.