Open MykeHalk opened 1 month ago
@SergiiDmytruk, do you by chance have any input on this?
Don't know why msi_ms7e06_v0.9.2-rc1
was removed, might have happened by accident. There is no real difference between RC0 and RC1 (RC0 is needed for tests to have something to update to RC1), so don't bother checking both.
Obvious reason could be the change for dTPM, but fTPM is recognized by Windows/Linux when ME is enabled in my tests performed just now (can't test with dTPM). So this looks weird.
That's, quite odd, Ill try to recompile firmware again to see if that may be the problem and test again, but from my testing both fTPM and dTPM are not being recognized.
I was only able to get it working by downgrading back down to v0.9.1
compiled from branch dasharo-4.21
@SergiiDmytruk, so it seems that after rebuilding and flashing the firmware, fTPM does work. but as soon as you enable the HAP bit just once, all TPM becomes unusable.
Once HAP is enabled once, even if you disable it again, fTPM no longer works. It seems this issue is causing dTPM to not work as well.
You can test this by, enable the HAP bit - booting into OS - shutting down - disabling the HAP bit - booting into OS - and fTPM will not be active even though HAP bit is not set.
This wasn't an issue in the previous revision, I'm wondering what is causing this?
@SergiiDmytruk, so it seems that after rebuilding and flashing the firmware, fTPM does work. but as soon as you enable the HAP bit just once, all TPM becomes unusable.
Once HAP is enabled once, even if you disable it again, fTPM no longer works. It seems this issue is causing dTPM to not work as well.
fTPM requires ME. If you enable HAP you're disabling the ME. So what you're describing is working as intended, and it should also work the same way on previous versions.
dTPM should work with ME disabled (Actually on previous versions with HAP enabled it defaulted to use dTPM if available). Do you have a dTPM installed?
@zirblazer Let me help you understand. I'm aware that fTPM requires ME. The Issue is that as soon as HAP bit is set, no matter if you disable the HAP bit again and re-enable IME, fTPM will no longer work anymore.
dTPM seems to be suffering from this issue as well due to something causing all TPM devices to no longer function once the HAP bit has been set. No matter what combination of disabling or re-enabling, all TPM devices are no longer are detected in OS.
dTPM is not detected with HAP bit set.
For the record, HAP bit set = ME disabled.
Yes I have a dTPM module, I have 2, I have tried both to rule out a faulty module.
Previous v0.9.1 UEFI/EDK2 release didn't default to dTPM when HAP was enabled, only v0.9.1 heads release had that feature. I had to build v0.9.1 UEFI from dasharo-4.21
branch to have that function. I then opened a issue to mention having it added to the upcoming release v0.9.2, but it does not seem to be functional right now so I opened this issue after testing.
Downgrading to v0.9.1
from branch dasharo-4.21
fixes the issue but I feel that this should be addressed for upcoming release.
Downgrading to v0.9.1 from branch dasharo-4.21 fixes the issue but I feel that this should be addressed for upcoming release.
This seems to ask for bisection because it sounds like regression.
as soon as you enable the HAP bit just once, all TPM becomes unusable.
When I tested TPM initially wasn't present because ME was disabled, so I had to enable it. Repeated the test now with toggling ME and TPM is still detected. Probably needs more testing, but can you also say how you flash? Random stuff like this reminds me of a confused ME. Have you tried unplugging your PC from the wall for couple minutes to make sure it ME does a boot cycle?
@SergiiDmytruk, I flash using flashrom, programmer is connected via JTPM1 header. I did switch the power supply off for a few minutes and then tried to boot again with no change but ill try again and wait longer to see if maybe that will fix it. Do you have a copy of the rom you are using? Could you upload it for me to test?
EDIT: Are you using a DDR4 or DDR5 board? I'm testing on a DDR5 board.
And to clarify just in case, TPM is still visible in firmware menu, but not detected in OS.
When I tested TPM initially wasn't present because ME was disabled, so I had to enable it. Repeated the test now with toggling ME and TPM is still detected.
I re-flashed the firmware and I was able to replicate your test. I left the dTPM removed and I was able to toggle HAP bit and fTPM did not break. When toggling ME though I had to power cycle the board (3) three times before fTPM was detected again. I think due to me not power cycling the board enough before re-disabling ME or re-flashing to continue testing, I mistaken fTPM for breaking when HAP bit was set. Without the dTPM installed I was able to visually see in the firmware menu that the fTPM was not initialized, so I decided to power cycle and after 3 power cycles it showed up in in the firmware menu, as well as the OS.
As for dTPM. It is still not being detected in OS. It showed up in the firmware menu without needing to power cycle but I did it anyways about 5 times before booting into the OS and it still was not detected. I attempted to restart a few times as well but still no luck.
I was wrong about fTPM, and this seems to be strictly a dTPM Issue.
@SergiiDmytruk, Please merge this commit https://github.com/Dasharo/coreboot/commit/b86b33dd56a16082ba63c1a8b5ddcd45ff5386d4 into v0.9.2-rc0 -
I have tested and it fixes the issue.
Oh, damn. After looking at Heads version I thought that config values were just hard-coded there without any code changes, completely forgetting that I saw those code changes months ago. Should have asked @miczyg1 to take a look at what I did.
@MykeHalk, thanks a lot! Not working dTPM probably wouldn't be caught by automated tests.
Forgot to mention here that this got dropped in rc2 (yes, in part because I messed it up in rc1).
@SergiiDmytruk I'm confused, will this still be fixed/added in the next release candidate or the main release?
@SergiiDmytruk I'm confused, will this still be fixed/added in the next release candidate or the main release?
Any follow-up RCs or v1.1.4 & v0.9.2 releases won't have dTPM support.
The whole TPM unification was meant for these particular MSI boards. It took us weeks/months to develop and upstream it. I can not say I am happy with this turn of events.
v1.1.4-rc3 results with ME HAP-disabled:
with ME enabled:
Is it as expected @miczyg1 ?
Is it as expected @miczyg1 ?
Yes, take a look at HID, when ME is disabled it is IFX (Infineon), while ME enabled it is INTC (Intel Corporation).
But the real test is if OS can talk to both TPMs properly, i.e. coreboot exposes a proper TPM2 ACPI table. If you can read PCRs from both TPMs, then all good.
Component
Dasharo firmware
Device
MSI Pro Z790-P
Dasharo version
v0.9.2-rc0 / v0.9.2-rc1 latest with 0x12B microcode
Dasharo Tools Suite version
No response
Test case ID
No response
Brief summary
Installed latest tag v0.9.2-rc0 with 0x12B microcode, as well as now removed v0.9.2-rc1 tag, dTPM is recognized in firmware, but not recognized in OS
How reproducible
100%
How to reproduce
Install dTPM onto JTPM1 header. Disable ME/ set HAP bit. Attempt to Install Windows 11 on firmware v0.9.2-rc0/rc1, It wont allow due to TPM requirement. You can bypass requirements using Rufus bootable drive creator or install using fTPM. But in OS, Windows "Security Processor" window does not detect TPM. HWinfo also does not detect any TPM.
Expected behavior
dTPM should be recognized when booting OS
Actual behavior
dTPM is not recognized
Screenshots
Additional context
EDIT: Attempted on Windows 10 as well with same results.
Previous known working branch/tag is
dasharo-4.21
Solutions you've tried
No response