On Wed, Jun 11, 2025 at 09:15:05AM -0700, Bart Van Assche wrote: > On 6/10/25 9:21 PM, Eric Biggers wrote: > > blk-crypto-fallback runs at the top layer, so yes it's different from native > > inline encryption support where the encryption is done at the bottom. (But the > > results are the same from the filesystem's perspective, since native support > > only gets passed through and used when it would give the expected result.) > > Although I'm not sure Keith realizes this, his patch may move encryption > from the top of the block driver stack (a device mapper driver) to the > bottom (something else than a device mapper driver). This may happen > because device mapper drivers do not split bios unless this is > essential, e.g. because the LBA range of a bio spans more than one entry > in the mapping table. > > Is my understanding correct that this is acceptable because the > encryption IV is based on the file offset provided by the filesystem and > not on the LBA where the data is written? The IV is provided in the bio_crypt_context. The encryption can be done at a lower layer, like how hardware inline encryption works, if the layers above are compatible with it. (E.g., they must not change the data.) Ultimately, the data that's actually written to disk needs to be identical to the data that would have been written if the user encrypted the data themselves and submitted a pre-encrypted bio. > > > Just keep in mind that blk-crypto-fallback is meant to work on any block device > > (even ones that don't have a crypto profile, as the profile is just for the > > native support). So we do need to make sure it always gets invoked when needed. > > I propose that we require that bio-based drivers must call > bio_split_to_limits() to support inline encryption. Otherwise the > approach of Keith's patch can't work. Does this seem reasonable to you? > > As far as I can tell upstream bio-based drivers already call > bio_split_to_limits(). Well, again it needs to work on any block device. If the encryption might just not be done and plaintext ends up on-disk, then blk-crypto-fallback would be unsafe to use. It would be preferable to have blk-crypto-fallback continue to be handled in the block layer so that drivers don't need to worry about it. - Eric
