31–40 of 40 posts
Earlier quoted context omitted.
> 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.
BSON, despite its name, is really just a format for MongoDB rather than a binary alternative for JSON.
Earlier quoted context omitted.
BSON, despite its name, is really just a format for MongoDB rather than a binary alternative for JSON.
Why can't it be both?
It's kind of shitty that it was called BSON, because it falls so far short of the generality that JSON has.
Earlier quoted context omitted.
> 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.
> 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.
(If you want to have a bad day, you can send a patch to Linus to put a JSON parser in the kernel.)
Earlier quoted context omitted.
Is there a good writeup on why this is such a horrific vulnerability? I see a lot of doom and gloom about this without a lot of explanations.
Plausible deniability. For example, from the trimmed sector you can inference that the disk is being used.
I mean, I guess is depends on what burden of proof is needed in the case, certainly if it were balance of probability I'd be surprised if having the disk in a computer looking like it has been written to is sufficient to not make it plausible to deny.
Earlier quoted context omitted.
> 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 th…
JSON 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.
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.
> Write programs to handle text streams, because that is a universal interface.
A lot of the data formats I've written recently have used JSON. Partly because of that aforementioned principal, but mostly because it's just easier and there are very little downsides. Almost every language has support for it so it's fairly universal, it's self documenting, it's easy to debug, easy to manipulate by hand, and easy to maintain.
Put more simply: I've implemented several data formats using custom binary and several data formats using JSON. JSON was easier and faster every single time.
My recommendation for data formats: just use JSON; unless you have a really good reason not to.
And I do mean really good reason. For example, many might think concerns about data size would be a reason not to use JSON. But go ahead and run some JSON through a compression algorithm some time. You'll be amazed. Compressed JSON is very competitive versus a custom binary format.
I'm surprised to see so many comments here throwing up on the use of JSON. Have we really forgotten the Unix philosophy? > Write programs to handle text streams, because that is a universal interface. A lot of the data formats I've written recently have used JSON. Partly because of that aforementioned principal, but mostly because it's just easier and there are very little downsides. Almost every language has support…
You may not realize it, but you've presented a false dichotomy here.
The alternate to JSON isn't "custom binary", it's standardized binary encodings that allow the same flexibility (or additional flexibility) compared to JSON. Some examples include cbor & msgpack.
>> Write programs to handle text streams, because that is a universal interface.
cryptsetup manipulates block devices. I don't think that line can or should really be applied to something that is fairly similar to a filesystem's on-disk format.
Earlier quoted context omitted.
> Alowing Trim passthrough on SSDs without impacting vulnerability. Unfortunately I don’t think that’s possible. If I scan your encrypted disk and see that 10% of blocks are zeroed out, I can assume that your disk is 90% full. So information has been leaked, which is arguably a vulnerability.
I think TRIM is dangerous not because of information leaks, but because of the risk of IV/nonce reuse when SSD data blocks are unmapped but not cleared. This would pose a risk if someone dumps the raw content of the NAND chips and find two or more data blocks encrypted with the same IV/nonce.
Earlier quoted context omitted.
I think TRIM is dangerous not because of information leaks, but because of the risk of IV/nonce reuse when SSD data blocks are unmapped but not cleared. This would pose a risk if someone dumps the raw content of the NAND chips and find two or more data blocks encrypted with the same IV/nonce.
Why does trim make a difference though? You're not going to scan the whole disk on each write for duplicates, so you need to guarantee statistically-unique nonces either way, or make sure reuse doesn't matter. Trim doesn't make this any worse/better.