Re: [dm-crypt] The future of disk encryption with LUKS2

[Sven Eschenberg <sven@whgl.uni-frankfurt.de>]

Am 10.02.2016 um 16:39 schrieb Milan Broz:
>
> On 02/10/2016 04:09 PM, Sven Eschenberg wrote:
>> Actually PARTUUID should have read PARTTYPE-GUID - So there's no reason
>> why moving it to a different partition should not work, updating the
>> PARTTYPE is a trivial step and part of a proper moving operation anyway.
>
> PARTTYPE GUID does not work properly for determining device type and never will.

That's most unfortunate and just shows my point of view, misengineered 
from the very beginning. (Not the GPT, the upper layers I mean)
>
> Hint: check what systemd does with it. There is a "home" GUID. What it says
> about device type?
> https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html
>
> And that's just one example because the reality is not what you would like to see...
>
> For checking device type we have to use blkid (IOW the real device scan).
>
> I know it is not nice academic design but it is reality and, surprise, it works.

"This generator will only look for root partitions on the same physical 
disk the EFI System Partition (ESP) is located on."

So it does not work if the root fs is on an external array, I presume? 
Which in turn means: it is broken and does not work.

BTW, if there's a RAID signature at the end of the device, the kernel 
complains about a displaced GPT. So, what does systemd make out of this?

Let's keep the example: While the presence of the displaced secondary 
GPT header does indeed indicate the proper layering, replace is with MBR 
and the fun really starts.

Still believe 'it works in reality'?
>
>> Just imagine the network's linklayer had no idea which upper layer to
>> call, because there's no information on that. TCP/IP again does not have
>> that type of information.
>>
>> So either the layering order is fixed and determined, or you actually
>> will need intra-layer relationships for proper operation. As an
>> alternative, leave it to the user's knowledge and handling. But then we
>> don't need partition tables, LUKS-headers or anything else either,
>> afterall you can tell each layer the geometry and parameters manually
>> and use dmsetup for all your tasks.
>
> It is not just black and white.
> (Could we avoid these logical fallacies here please?)
>
> Milan

Regards

-Sven