[dm-crypt] The future of disk encryption with LUKS2
sven at whgl.uni-frankfurt.de
Mon Feb 8 20:08:24 CET 2016
Am 08.02.2016 um 19:49 schrieb Arno Wagner:
> On Mon, Feb 08, 2016 at 18:26:49 CET, Sven Eschenberg wrote:
>> Indeed usually a disk should be able to finish the sector write with
>> remaining power. Actually most modern disks do have voltage shifters
>> and most parts operate on lower voltage.
> At least for the R/W logic. The heads do not need to be
> moved during a started write and the platters will keep
> spinning far longer than needed.
>> Thus a drop on the
>> changer's input does not immediately lead to a drop on the output of
>> the voltage shifter. If's theres enough power left for the physical
>> layer scrambler and the head to write, then everything should be
> As this depends on the buffer-capacitors, you can design how
> long they keep the lower voltage (typically 3.3V or 2.5V) up
> after the input has gone below, say 4.5V. With a low-drop
> 3.3V regulator you get about 1V of drop, before 3.3V drops.
> That is plenty.
> Maybe I will have a look into an older 2.5" hdd and check
> when it stops spinngin and what voltage the R/W amplifier is
>> I was rather wondering if there's definite sources on that?
> There is not even a definite source on what error-correcting
> codes are used today or what the actual rate of non-correctable
> errors is. Disk manufacturers like to keep the user in the
> dark about potential problems...
So true, let me rephrase, can we trust on manufacturers handling these
cases the way we assume they do? Or do we need to assume the worst case
we can even imagine?
> I used to look at technical manuals of disks, but in the last
> 10 years or so they were impossible to get, at least from public
>> BTW. The burst errors I mentioned did not happen on a power loss,
>> but rather during operation. Reading twice, one time with burst
>> errors, one time without. I checked the RAM for ages - no failures.
>> That was really weird.
> Indeed. Maybe you did run into a firmware error or some
> PC-side controller problem that was not properly caught
> in the driver. Maybe also a DMA error or the like that
> failed to move all the data into RAM. I found that
> checking alignment on such errors often gives good
The errors seemed sector aligned, if I remember correctly, that's why I
thought the cause is probably the disk (or it's firmware). I remember,
it only happened when a lot of data was moved. I tried various things
like putting load on the chipset, the CPU, just to see if I can trigger
the problem and reproduce it. Then again, could still have been a
problem in the PCIe root hub or whatsoever *shrugs*. Too many variables
to know for sure.
More information about the dm-crypt