Why ext4 encryption is disabled in our linux-libre-4.8 config

Why ext4 encryption is disabled in our linux-libre-4.8 config

[Mark H Weaver]

When updating our x86 kernel configs for linux-libre-4.8, I wanted to
enable CONFIG_EXT4_ENCRYPTION.  Unfortunately, enabling that option
seems to require CONFIG_CRYPTO_XTS=y instead of =m as in our existing
kernel configs.  I guess it's because CONFIG_EXT4_ENCRYPTION cannot be
modularized, which forces its dependencies to be built-in.  This in turn
causes 'base-initrd' to fail, due to the absense of xts.ko.

We could remove 'xts' from the list of hardcoded modules in our initrd,
but it seems to me this would be a fragile workaround, not a
satisfactory solution to the problem.

One possible solution would be to enhance 'flat-linux-module-directory'
to silently ignore missing modules when the needed functionality is
built-in to the kernel, as indicated by the presence of
"CONFIG_CRYPTO_XTS=y" in #$linux/.config.

One caveat with this approach is that I don't know how to map module
names to Kconfig flags.  Does anyone know how?  If needed, I suppose we
could lazily accumulate our own subset of this mapping, starting with
only the modules used by our initrd by default.  Alternatively, we could
change our lists of module names into lists of (module-name config-flag)
pairs.

   Thoughts?
      Mark

Re: Why ext4 encryption is disabled in our linux-libre-4.8 config

[Ludovic Courtès]

Hi Mark!

Mark H Weaver <mhw@netris.org> skribis:

> One possible solution would be to enhance 'flat-linux-module-directory'
> to silently ignore missing modules when the needed functionality is
> built-in to the kernel, as indicated by the presence of
> "CONFIG_CRYPTO_XTS=y" in #$linux/.config.

That sounds like a good idea.  David hit a similar problem with commit
50dbc03647170fded9e0bca0cc4b7e1614aa38db.

> One caveat with this approach is that I don't know how to map module
> names to Kconfig flags.  Does anyone know how?  If needed, I suppose we
> could lazily accumulate our own subset of this mapping, starting with
> only the modules used by our initrd by default.  Alternatively, we could
> change our lists of module names into lists of (module-name config-flag)
> pairs.

I suspect there’s no systematic way to map option names to module names.
We may have to maintain our own list of option/module pairs, but that
doesn’t sound unreasonable.

Cheers,
Ludo’.