[lkml]   [2019]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/2] tpm: tpm_crb: enhance resource mapping mechanism for supporting AMD's fTPM
> On Tue, 2019-09-03 at 18:56 +0900, Seunghun Han wrote:
> > Thank you for your notification. I am sorry. I missed it and
> > misunderstood Jarkko's idea. So, I would like to invite Matthew
> > Garrett to this thread and attach my opinion on that. The problem is
> > that command and response buffers are in ACPI NVS area. ACPI NVS area
> > is saved and restored by drivers/acpi/nvs.c during hibernation, so
> > command and response buffers in ACPI NVS are also handled by nvs.c
> > file. However, TPM CRB driver uses the buffers to control a TPM
> > device, therefore, something may break.
> >
> > I agree on that point. To remove uncertainty and find the solution,
> > I read the threads we discussed and did research about two points, 1)
> > the race condition and 2) the unexpected behavior of the TPM device.
> >
> > 1) The race condition concern comes from unknowing buffer access order
> > while hibernation.
> > If nvs.c and TPM CRB driver access the buffers concurrently, the race
> > condition occurs. Then, we can't know the contents of the buffers
> > deterministically, and it may occur the failure of TPM device.
> > However, hibernation_snapshot() function calls dpm_suspend() and
> > suspend_nvs_save() in order when the system enters into hibernation.
> > It also calls suspend_nvs_restore() and dpm_resume() in order when the
> > system exits from hibernation. So, no race condition occurs while
> > hibernation, and we always guarantee the contents of buffers as we
> > expect.
> >
> > 2) The unexpected behavior of the TPM device.
> > If nvs.c saves and restores the contents of the TPM CRB buffers while
> > hibernation, it may occur the unexpected behavior of the TPM device
> > because the buffers are used to control the TPM device. When the
> > system entered into hibernation, suspend_nvs_save() saved the command
> > and response buffers, and they had the last command and response data.
> > After exiting from hibernation, suspend_nvs_restore() restored the
> > last command and response data into the buffers and nothing happened.
> > I realized that they were just buffers. If we want to send a command
> > to the TPM device, we have to set the CRB_START_INVOKE bit to a
> > control_start register of a control area. The control area was not in
> > the ACPI NVS area, so it was not affected by nvs.c file. We can
> > guarantee the behavior of the TPM device.
> >
> > Because of these two reasons, I agreed on Jarkko's idea in
> > . It seems that removing or
> > changing regions described in the ACPI table is not natural after
> > setup. In my view, saving and restoring buffers was OK like other NVS
> > areas were expected because the buffers were in ACPI NVS area.
> >
> > So, I made and sent this patch series. I would like to solve this
> > AMD's fTPM problem because I have been doing research on TPM and this
> > problem is critical for me (as you know fTPM doesn't work). If you
> > have any other concern or advice on the patch I made, please let me
> > know.
> Please take time to edit your responses. Nobody will read that properly
> because it is way too exhausting. A long prose only indicates unclear
> thoughts in the end. If you know what you are doing, you can put things
> into nutshell only in few senteces.
> /Jarkko

I'm sorry about that. I would like to invite Matthew Garrett and
discuss ACPI NVS and command/response buffer mapping again. So, I want
to summarize my test result and explain my opinion on that. I think
the data and result are important to make a decision clearly.
According to my test results, it seems that intersects between ACPI
NVS and command/response buffers will not make a problem.

Additionally, according to Dave's test results, this patch series can
cover not only an intersection with ACPI NVS area but also an
intersection with the reserved area. Here is the link, . Considering these results, my
patch series can solve AMD's fTPM problems.

what do you think about test results and this patch? In my view, if
the command/response buffers are in ACPI NVS area, saving and
restoring the buffers are ok and couldn't break anything.
I would like to get some feedback from you.


 \ /
  Last update: 2019-09-03 20:53    [W:0.050 / U:8.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site