Extended attributes

Posted Jan 4, 2019 14:20 UTC (Fri) by dskoll (subscriber, #1630)
In reply to: Extended attributes by quotemstr
Parent article: A setback for fs-verity

I like this idea, but on the other hand, you now used up two file descriptors each time you open a file, and something has to manage the hidden descriptor. You could also run into weird issues if the second open fails, but then I guess you'd just fail everything.

Extended attributes

Posted Jan 4, 2019 19:02 UTC (Fri) by quotemstr (subscriber, #45331) [Link] (3 responses)

Not two file descriptors --- from userspace's POV, there's just one file and its descriptor. That VFS internally would maintain an internal pointer to a different struct file is just an implementation detail. And yes, VFS could just fail the open if the authentication blob file couldn't be opened.

Extended attributes

Posted Jan 4, 2019 20:26 UTC (Fri) by dskoll (subscriber, #1630) [Link] (2 responses)

You could generalize this idea to allow multiple data forks. The fs-verity Merkle tree would be a special data fork that could be set once only and then never changed. I think this is a much nicer approach than shoving the verification data at the end of the file.

Extended attributes

Posted Jan 4, 2019 20:34 UTC (Fri) by quotemstr (subscriber, #45331) [Link] (1 responses)

generalization is the enemy of LKML patch acceptance though. :-) I think starting simple might be a good approach. I'll send an LKML email.

Extended attributes

Posted Jan 4, 2019 20:40 UTC (Fri) by dskoll (subscriber, #1630) [Link]

Haha. :) I'm not a kernel developer and have only recently started a job that requires looking deeply into the kernel, so I'm a newbie at this.