It boils down to this error message, as far as I understand the topic: kernel: ecryptfs: Unknown symbol key_type_encrypted (err -2) With the help of the Arch linux forum users (see thread here https://bbs.archlinux.org/viewtopic.php?pid=1846577), we found out that ecryptfs works fine with newer kernel versions for people without a TPM and for those with TPM with TxT enabled in the BIOS; but for me the TxT option is disabled in the BIOS so this isn't a solution. (As ecryptfs works fine with kernel 5.0.8)
What happens when you run 'modprobe encrypted_keys'? Is the module able to successfully load or does it fail with an error? It looks like the Arch Linux kernel's config was updated around the same time that Arch Linux users started hitting this problem: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux&id=e88b311da8d89d177ce9f1d608774ca22cff8fc9 I was unable to reproduce this bug in a VM even after disabling the Integrity Subsystem. I'll have to do some additional testing on physical hardware.
(In reply to Tyler Hicks from comment #1) > What happens when you run 'modprobe encrypted_keys'? Is the module able to > successfully load or does it fail with an error? > > It looks like the Arch Linux kernel's config was updated around the same > time that Arch Linux users started hitting this problem: > > > https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/ > linux&id=e88b311da8d89d177ce9f1d608774ca22cff8fc9 > > I was unable to reproduce this bug in a VM even after disabling the > Integrity Subsystem. I'll have to do some additional testing on physical > hardware. Loading that command with kernel 5.1.12 gives modprobe: ERROR: could not insert 'encrypted_keys': Bad address I have narrowed it down to be between 5.0.9 and 5.1
encrypted_keys.ko depends upon trusted.ko 240730437deb213a58915830884e1a99045624dc broke loading trusted.ko without a TPM c78719203fc629421a0d91d3d22240c36ae0119c fixed loading trusted.ko without a TPM however if the TPM is in the disabled state it is present but none functional which causes loading of trusted.ko to fail
Created attachment 283519 [details] Any errors in initialization of the TPM cause the TPM to not be used instead of raising an error
(In reply to loqs from comment #4) > Created attachment 283519 [details] > Any errors in initialization of the TPM cause the TPM to not be used instead > of raising an error I don't think this is quite the right fix. I think we should only "ignore" unacceptable return values from tpm_default_chip() and tpm_get_random() instead of all the possible errors in init_trusted(). There's a commit in the linux-tpmdd.git tree that revert commit 0b6cf6b97b7ef1fa3c7fefab0cac897a1c4a3400: http://git.infradead.org/users/jjs/linux-tpmdd.git/commit/7126aff3b5d50b96d2eaef9fb9a43c0ef58df6a2 That commit should also fix this bug because init_trusted() would no longer call tpm_get_random(). There's a request that the revert not be merged so we'll need a different fix if that happens: https://lore.kernel.org/linux-integrity/20190704195857.GB6105@elm/T/#m3f63200ac1ca5e44698387d8c6fb408bf476a716
FWIW, I'm still unable to reproduce this bug on my HP Elite x2 1012 G1 even though the BIOS lets me configure the TPM device as being "available" but simultaneously disabled by unchecking the "TPM State" check box. In that state, the call to tpm_default_chip() returns NULL and ecryptfs.ko successfully loads thanks to the short-circuit added in commit c78719203fc629421a0d91d3d22240c36ae0119c. The bug description states that disabling TXT support is what triggers the bug for them but this laptop doesn't have TXT support so I can't toggle the configuration.
A proposed fix for this bug is available here: https://lore.kernel.org/linux-integrity/20190802150733.1972-1-roberto.sassu@huawei.com/ Testing feedback from anyone affected by this bug would be much appreciated!
(In reply to Tyler Hicks from comment #7) > A proposed fix for this bug is available here: > > https://lore.kernel.org/linux-integrity/20190802150733.1972-1-roberto. > sassu@huawei.com/ > > Testing feedback from anyone affected by this bug would be much appreciated! I've build the kernel with said patch applied and everything works as expected (encryptfs loads and works)
Hi Daniel - Thanks for testing v2. We really appreciate it. Roberto has iterated on the fix once more and we kindly ask that you test v3 of the fix: https://lore.kernel.org/linux-integrity/20190805164427.17408-1-roberto.sassu@huawei.com/
v3 of the fix works fine for me too. ecryptfs loads as expected and works. (tested with 5.2.5 with the patch)
A fix for this bug has landed: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2d6c25215ab26bb009de3575faab7b685f138e92 It'll be in 5.3-rc5. Thanks again for all the testing help.