[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f71b5c39-5499-4ae8-99e2-fb679f0b6a11@gmail.com>
Date: Mon, 16 Oct 2023 18:01:44 +0200
From: Milan Broz <gmazyland@...il.com>
To: Christoph Hellwig <hch@....de>
Cc: Damien Le Moal <dlemoal@...nel.org>, linux-scsi@...r.kernel.org,
jejb@...ux.ibm.com, martin.petersen@...cle.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] scsi: use ATA-12 pass-thru for OPAL as fallback
On 10/16/23 15:27, Christoph Hellwig wrote:
> On Mon, Oct 16, 2023 at 02:46:03PM +0200, Milan Broz wrote:
>> The problem is that we (for simplicity) decided to use kernel SED-ioctl interface that
>> internally wraps OPAL command to SCSI SECURITY command only. It means, that all devices
>
> No, it doesn't. It uses the properly specified protocol for each
> layer. That is NVMe uses NVMe Security Send/Receive, SCSI uses the
> SCSI protocol, and libata translats for ATA devices.
>
>> that can use ATA-12 just cannot work with this kernel interface (unlike userspace which
>> can decide which wrapper to use).
>
> It supports all devices that actually speak ATA perfectly fine, take
> a look at ata_scsi_security_inout_xlat.
Yes, I have several of them in my test machine. The comment was about (S)ATA connected
through USB bridge only.
>>
>> And IMO it is not correct - if it was designed only for some servers with directly connected
>> devices, then it is really not generic OPAL support. It should work for any hw that supports it.
>
> Let's get off your crack pipe before we continue. It is designed and
> implemented to support the security protocols exactly as spec'ed.
>
> You seem to have found devices that claim to be SCSI, but actually
> require ATA passthrough for security. That's no secret cabal to lock
> out non-server hardware but just proper protocol design.
*grin* I just bought several NVMe to USB adapters that presents NVMe device as SCSI, this
is pretty common.
(And Thunderbolt adapters - that present NMVe as real NVMe is another story too.
But once configured, it is doing it correctly.)
But yes, you are right - except the USB hw is here (in huge quantities) and I want to use it.
It is quite possible that there is not way to do it clearly - fine, that's why I sent the patch
for review.
>
>> For USB, it actually works quite nice with the patch (ignoring usual bugs in firmware).
>
> So move it into usb if you can convince the usb maintainers that they
> are fine with it.
Yep, fair enough. My initial motivation was just understand WTF is going there.
Put the support on a proper layer is step #2.
>>> Note that nowhere in your patch do you test if you are talking to an ATA device.
>>
>> Yes, I know. I expected the command to be rejected if not supported.
>
> Good luck. Cheap storage hardware trips up on unknown commands all the
> time.
... And my tests for TCG OPAL commands shows that it can be even worse on this layer :-)
(To be fair, recent NVMe devices looks much better. Anyway, yes, I know what you mean.)
>
>> IMO it is quite similar to discard/TRIM support...
>
> Where we also don't support weird ATA commands directly from sd
> for good reason.
ok, I am actually quite happy that I get some response to this patch.
Supporting it is a mess, but I still believe we can do it (if fw is not completely bogus).
Thanks,
Milan
Powered by blists - more mailing lists