Bug 203953 - Ecryptfs doesn't load with kernel > 5.0.8 with TPM
Summary: Ecryptfs doesn't load with kernel > 5.0.8 with TPM
Status: RESOLVED CODE_FIX
Alias: None
Product: File System
Classification: Unclassified
Component: ecryptfs (show other bugs)
Hardware: x86-64 Linux
: P1 high
Assignee: fs_ecryptfs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-22 11:01 UTC by Daniel
Modified: 2020-06-10 08:35 UTC (History)
2 users (show)

See Also:
Kernel Version: 5.1
Tree: Mainline
Regression: No


Attachments
Any errors in initialization of the TPM cause the TPM to not be used instead of raising an error (364 bytes, patch)
2019-07-02 11:19 UTC, loqs
Details | Diff

Description Daniel 2019-06-22 11:01:52 UTC
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)
Comment 1 Tyler Hicks 2019-06-23 06:25:28 UTC
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.
Comment 2 Daniel 2019-06-23 12:01:20 UTC
(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
Comment 3 loqs 2019-07-02 11:17:01 UTC
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
Comment 4 loqs 2019-07-02 11:19:40 UTC
Created attachment 283519 [details]
Any errors in initialization of the TPM cause the TPM to not be used instead of raising an error
Comment 5 Tyler Hicks 2019-07-04 20:09:01 UTC
(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
Comment 6 Tyler Hicks 2019-07-04 20:15:37 UTC
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.
Comment 7 Tyler Hicks 2019-08-02 15:35:01 UTC
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!
Comment 8 Daniel 2019-08-04 21:55:16 UTC
(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)
Comment 9 Tyler Hicks 2019-08-05 16:53:27 UTC
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/
Comment 10 Daniel 2019-08-05 17:13:04 UTC
v3 of the fix works fine for me too. ecryptfs loads as expected and works.

(tested with 5.2.5 with the patch)
Comment 11 Tyler Hicks 2019-08-13 19:44:47 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.