[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Kozub
Subject: Re: [Qemu-devel] Emulation of TCG OPAL self-encrypting drive
Date: Fri, 18 Jan 2019 00:04:48 +0100 (CET)
User-agent: Alpine 2.21 (LRH 202 2017-01-01)

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?


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. Done in [1].)

Here are the specs relevant for OPAL v2:

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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]