Based on what I have read here, I came to the understanding that after upgrading the dom0 kernel I'd get an AEM error when I reboot the machine, since the kernel is different from the last boot.
Yesterday, I installed a new dom0 update which included an updated kernel package. I was expecting to see an AEM error when I rebooted, but that never happened.
This suggests to me that my AEM configuration is incorrect. Is there a way I can test whether it works or not? Perhaps my manipulating something in the boot process that would trigger an AEM failure?
The funny thing is that I did see my secret message. That's why I thought it was so weird.
That's why I asked for a way to force a failure so that I can double check this.
> Try checking the tboot log (from dom0) for any obvious error messages:
> sudo txt-stat
Thanks. I did this, but I'm not sure how to interpret the information. It does say "TXT measures launch: FALSE". Does that mean that TXT is not available?
Here's the output of the command:
Intel(r) TXT Configuration Registers:
STS: 0x00000082
senter_done: FALSE
sexit_done: TRUE
mem_config_lock: FALSE
private_open: TRUE
locality_1_open: FALSE
locality_2_open: FALSE
ESTS: 0x00
txt_reset: FALSE
E2STS: 0x0000000000000004
secrets: FALSE
ERRORCODE: 0x00000000
DIDVID: 0x00000001b0068086
vendor_id: 0x8086
device_id: 0xb006
revision_id: 0x1
FSBIF: 0xffffffffffffffff
QPIIF: 0x000000009d003000
SINIT.BASE: 0x00000000
SINIT.SIZE: 0B (0x0)
HEAP.BASE: 0x00000000
HEAP.SIZE: 0B (0x0)
DPR: 0x0000000000000000
lock: FALSE
top: 0x00000000
size: 0MB (0B)
PUBLIC.KEY:
2d 67 dd d7 5e f9 33 92 66 a5 6f 27 18 95 55 ae
77 a2 b0 de 77 42 22 e5 de 24 8d be b8 e3 3d d7
***********************************************************
TXT measured launch: FALSE
secrets flag set: FALSE
***********************************************************
unable to find TBOOT log
This looks to me like tboot either wasn't loaded at all or memory
logging is disabled.
Check the tboot cmdline used -- search for the following in
/boot/grub2/grub.cfg:
multiboot /tboot.gz placeholder logging=memory,serial
If memory logging is enabled, try adding vga there too (plus a delay
to be able to read the output):
multiboot /tboot.gz placeholder logging=memory,serial,vga vga_delay=10
You'll have 10 seconds per screenfull of tboot log messages, may as
well take photos. :)
> That's a non-fatal error, I have that in my log too.
>
> What's more interesting is the last photo, in particular the line:
>
> ERR: SENTER disabled by feature control MSR (5)
>
> I _think_ this means that your motherboard/BIOS does not support Intel
> TXT as it seems to be deliberately disabled in the CPU's
> Model-Specific Register (MSR).
>
> Maybe try searching for the TXT-enabling option in BIOS again (it may
> be hidden until you turn on something else, eg. Intel VT-d/IOMMU like
> on my Lenovo laptop). Check whether there's a BIOS update available, too
Thank you! You were right of course. There was a disabled option referring to "trusted execution" that was turned off. Enabling that gave me much more than 3 pages of debug output.
Unfortunately, the machine reboots shortly after the "SENTER", causing the machine go into an infinite bootloop.
Note that it never even gets to the point where it asks for the TPM password.
Would screenshots of all the pages of debug be useful?
Thanks and regards,
Elias
This sounds like the exact same issue I've encountered -- and managed> Thank you! You were right of course. There was a disabled option
> referring to "trusted execution" that was turned off. Enabling that
> gave me much more than 3 pages of debug output.
>
> Unfortunately, the machine reboots shortly after the "SENTER",
> causing the machine go into an infinite bootloop.
>
> Note that it never even gets to the point where it asks for the TPM
> password.
>
> Would screenshots of all the pages of debug be useful?
>
> Thanks and regards, Elias
>
to fix by adding "min_ram=0x2000000" to the tboot cmdline arguments
(see tboot readme [1] for details).
Now that I tried removing min_ram from my setup it still works, so
perhaps the fix for this was something different... Can't recall what
though. :-\
Ah well, guess we'll have to go back to taking pictures of the screen.
Oh yes, now I remember! This was definitely a Linux kernel issue for
me, it just didn't setup VGA console logging yet so it seems like a
tboot hang. See the mail I just sent about updating dom0 kernel.
> On 07/20/2017 02:08 PM, Patrik Hagara wrote:
> > As for the Linux kernel, you want to use the earlyprintk param,
> > either "earlyprintk=vga,keep" or "earlyprintk=xen,keep" should
> > work. Again, the full (and fairly long) list of supported
> > parameters is available at this link [2].
> >
> > The Linux early printk logging should yield some useful info, I
> > hope.
>
> Also, removing the "quiet" option might be necessary. Try adding
> "nowatchdog panic=0" if the system reboots too quickly after logging
> the errors.
Unfortunately, after doing all of this (and trying a few different variations), I still have the behaviour that the machine reboots immediately after SENTER.
From this I draw the conclusion that the kernel isn't even started.
What happens (or is supposed to happen) between SENTER and the kernel being loaded?
Regards,
Elias