[Cryptography] LUKS on ATA versus on SSD

[John Levine]

It appears that Jon Callas <jon at callas.org> said:
>Think of it slightly differently -- you're right but over-complexifying it. In the Bad Old Days, there was Physical IO. For a disk
>(and they were all rotating rust), physical IO was a three-dimensional coordinate of [track, sector, platter] and even a geometric
>concept of "cylinder" which is important for performance. Physical IO would make your tear your hair out, and was also heavily
>restricted --- in VMS, for example, there was a privilege for doing physical IO that was as dangerous as being 
>+ in kernel mode. ...

Oh, it was way messier than that. On IBM 360 mainframes, the physical structure
of the disk was visible to application programs. Each disk had a fixed number of
cylinders and tracks. (A cylinder was the set of corresponding tracks on each
surface, since switching from one track to another within a cylinder was
electronic, while moving from one cylinder to another meant physically moving
the disk heads.) A file, which they called a dataset, was allocated a set of
cylinders if it was big, or tracks if it was small. Each track was formatted
with records which could be of arbitrary size, set up when a dataset was
created. 

The disks were run via channels, specialized computers that managed I/O. A
channel program would have a command to seek the heads to the desired cylinder
and select the track, then a loop looking for the desired record (they were
numbered on each track), then read or write the record. Application programs
provided their own channel programs, which they told the operating system to
run, after it used channel features that limited the user program to the
assigned cylinder or track. Usually the channel programs were written by I/O
libraries, called access methods, but it was not uncommon for applications like
databases to write their own to get high performance or use quirks of the disk
hardware. 

One or two tracks per cylinder were kept as spares. If a track was found to be
defective when the disk was formatted, one of the spares was assigned as an
alternate and the bad track had a special record written to point to the
alternate. If a track subsequently went bad, utility programs could try and
recover what records it could from the bad track and move them to a newly
assigned alternate.

This is greatly oversimplified; I'm leaving out the hardware key feature that
supported ISAM, the earliest key->data storage, and other details.

>From this you can see that while data was usually written to the place you
expected, it might instead be on an alternate track, or even might later be
moved to an alternate track. If a track was defective that meant that part of it
was bad, but quite possibly most of it was still good and could be read. Modern
disks do way more of this, and hide it all in the controller so you have no idea
where on the physical disk any particular data is, and techniques like load
leveling mean there's even less reason to expect that if you rewrite block N,
that it will be in the same physical block as the previous version.

Hence if your security model requires that you be able to erase data you don't
want any more, you lose, but that's nothing new -- you would have had the same
problem on disks 60 years ago. The point of encrypted disk formats is that if
someone doesn't have the decryption key, it doesn't matter whether they can read
the physical disk. Even if they can they can't tell what it said.

R's,
John