Re: [Qemu-devel] Emulation of TCG OPAL self-encrypting drive

[David Kozub]

On Wed, 16 Jan 2019, John Snow wrote:

> I can answer some questions about the ATA layer, but I'm not well read
> on OPAL or the interrelationship between the two.
>
> We don't have an ATA-style passthrough in QEMU right now and nobody has
> ever asked! Would you mind elaborating for me what kind of setup you're
> looking to accomplish and maybe I can give you some better hints?
>
> --js

Hi John,

I'm thinking about adding OPAL support into grub. And I thought being able 
to do the development with qemu would make the development much easier.

While I read the OPAL spec, I can't say I understand it. But as far as I 
know, the relationship between OPAL and ATA is not too complicated. The 
OPAL spec itself is written in interface-agnostic way. It just defines 
there should be two interface commands ("Trusted Commands"), described as 
"IF-SEND" and "IF-RECV". (See [1], 1.4.1 Global Terminology and 2.3.1 Host 
<-> TPer Communication Infrastructure) and the OPAL spec essentially 
defines the paylods for these.

The actual definition of what "Trused Commands" are for ATA comes from 
"TCG Storage Interface Interactions Specification (SIIS)"[3], specifically 
"4.2 Mapping of IF-SEND and IF-RECV". (Well, it's not that simple, as 
there are other things like error handling.)

Of course, OPAL affects other commands, like reads and writes, based on 
the OPAL state (see [1], 5.7 Locking Template).

Furthermore, there is the "shadow MBR" feature, which, when enabled (and 
not marked as done), makes the disk present a different content at the 
beginning. (This is typically used to store a program that can be booted, 
asks for password, unlocks the disk, sets the "mbr done" flag to hide the 
shadow MBR and reboots to the real OS. - see e.g. 5.7.2.5.3 Done in [1].)

Here are the specs relevant for OPAL v2:
[1] 
https://trustedcomputinggroup.org/wp-content/uploads/TCG_Storage_Architecture_Core_Spec_v2.01_r1.00.pdf
[2] 
https://trustedcomputinggroup.org/wp-content/uploads/TCG_Storage-Opal_SSC_v2.01_rev1.00.pdf
[3] 
https://trustedcomputinggroup.org/wp-content/uploads/TCG_SWG_SIIS_v1.08_r1.00.pdf

Implementing the spec (for what an "OPAL" disk need to support, I think 
[2] is the important document) seems like a big task.

So I'm thinking ATA passthrough might be a more attainable goal. This way 
I could use a real OPAL drive w/o needing a spare controller for PCI 
passthrough. And with some more fiddling, I could even connect this to 
userspace (I was thinking of ATA over Ethernet). This could be useful for 
other development/fiddling scenarios too.

But I don't know much about ATA. Would it be sufficient to just do an 
SG_IO IOCTL on the target block device for each ide_exec_cmd? How do 
things like NCQ fit into this?

Best regards,
David