5 ms·
Section regarding the format: LUKS2 format and features ~~~~~~~~~~~~~~~~~~~~~~~~~ The LUKS2 is an on-disk storage format designed to provide simple
by 2bluesc 9y ago
Section regarding the format:
LUKS2 format and features
~~~~~~~~~~~~~~~~~~~~~~~~~
The LUKS2 is an on-disk storage format designed to provide simple key
management, primarily intended for Full Disk Encryption based on dm-crypt.
The LUKS2 is inspired by LUKS1 format and in some specific situations (most
of the default configurations) can be converted in-place from LUKS1.
The LUKS2 format is designed to allow future updates of various
parts without the need to modify binary structures and internally
uses JSON text format for metadata. Compilation now requires the json-c library
that is used for JSON data processing.
On-disk format provides redundancy of metadata, detection
of metadata corruption and automatic repair from metadata copy.
NOTE: For security reasons, there is no redundancy in keyslots binary data
(encrypted keys) but the format allows adding such a feature in future.
NOTE: to operate correctly, LUKS2 requires locking of metadata.
Locking is performed by using flock() system call for images in file
and for block device by using a specific lock file in /run/lock/cryptsetup.
This directory must be created by distribution (do not rely on internal
fallback). For systemd-based distribution, you can simply install
scripts/cryptsetup.conf into tmpfiles.d directory.
For more details see LUKS2-format.txt and LUKS2-locking.txt in the docs
directory. (Please note this is just overview, there will be more formal
documentation later.)
- deleted 9y ago[deleted]
- codys 9y ago> JSON text format for metadata It seems like it could be better to use some easier to parse binary format that allows the same flexibility that json does, like cbor/msgpack/bson. Using JSON here is a very strange choice.
- cesarb 9y agoAt least it's not XML.
- loeg 9y ago> Using JSON here is a very strange choice. I agree! Perhaps the userspace administrative tool (which links json-c) parses it and converts it to something more like an ioctl struct for the kernel.
- majewsky 9y agoAFAIK the kernel only contains dm-crypt. The whole key handling takes place in userspace, in cryptsetup(1). (If you want to have a bad day, you can send a patch to Linus to put a JSON parser in the kernel.)
- Crontab 9y agoTo me, the worst part is that it introduces a library dependency, which itself can introduce security issues unless they intend to audit it. I don't under this choice at all.
- klodolph 9y agoBSON, despite its name, is really just a format for MongoDB rather than a binary alternative for JSON.
- deleted 9y ago[deleted]
- jwilk 9y agoWhy can't it be both?
- klodolph 9y agoI see no reason why it can't be both, it's just that BSON happens to be a poor format for general interchange, and if you went back and redesigned you could probably fix many of its flaws. I'm a little skeptical though, I would rather just throw it out. It's kind of shitty that it was called BSON, because it falls so far short of the generality that JSON has.
- wyager 9y ago> internally uses JSON text format for metadata. What the hell? Why would they do this? The only (tenuous) justification for using a parsed human-oriented text format in any protocol is so that humans can edit things by hand, but this will presumably not be the case for file metadata. I don’t want to read too much into this since there might be a sane explanation, but this seriously makes me question the design of this security-critical system.
- freedomben 9y agoJSON is a language agnostic format that is widely supported, so one could read/parse the metadata from virtually any language. This is much more flexible and powerful than a specific binary format. It may also make debugging a lot easier since it is human readable. I don't know if that's the reason they chose JSON, but that's what I would think about IIWM.
- wyager 9y ago> so one could read/parse the metadata from virtually any language. This isn’t a use case for file system metadata. It only makes sense internally anyway. People interact with filesystem metadata through standardized APIs, not metadata dumps. > It may also make debugging a lot easier since it is human readable. It’s also basically guaranteed to introduce a ton of bugs; parsing and generating JSON is orders of magnitude more complicated than generating and reading an unambiguous tagged binary format.
- loeg 9y agoJSON seems like a weird choice for a kernel-parsed data structure. Or perhaps it's just parsed in userspace and signaled to the kernel in a more direct format.
- nly 9y agoThis isn't without precedence. IIRC the LVM (Linux Volume Management) metadata is also mostly text format https://github.com/libyal/libvslvm/blob/master/documentation/Logical%20Volume%20Manager%20(LVM)%20format.asciidoc#55-metadata-sample https://github.com/libyal/libvslvm/blob/master/documentation...
- deleted 9y ago[deleted]
- jwilk 9y agoI'm pretty sure this JSON is not parsed by kernel.
- tinus_hn 9y agoThat doesn't really matter as the program parsing it is probably running with full privileges.