How can I test that my AEM configuration is correct?

111 views
Skip to first unread message

lok...@gmail.com

unread,
Jun 29, 2017, 6:47:50 AM6/29/17
to qubes-users
I enabled AEM some time ago, and so far it's worked the way I'd expect it to.

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?

Chris Laprise

unread,
Jun 29, 2017, 9:56:30 AM6/29/17
to lok...@gmail.com, qubes-users
Its a little unsettling, but AEM doesn't display an error message when
this happens. There is simply a lack of your verification phrase and (be
careful) an opportunity to unlock your HD which leads to re-sealing with
the new config.

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

lok...@gmail.com

unread,
Jun 29, 2017, 10:25:45 AM6/29/17
to qubes-users
Thanks for the reply.

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.

Rusty Bird

unread,
Jun 29, 2017, 11:30:44 AM6/29/17
to lok...@gmail.com, qubes-users, Marek Marczykowski-Górecki
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

lok...@gmail.com:
> 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.

I'm guessing you've installed anti-evil-maid v3.0.4? You could retry
with v3.0.5 from the dom0 current-testing repository, which runs a
sanity check on your PCR values. See the README in case this check
fails.

CCing Marek - should v3.0.5 be migrated to current?

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZVR0eXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfyf4P/RTVJv4W7ygfjdimQVEvk5T6
BKO115f/WbdPCOE46odIT6W199gPg6Op66HKm5lZb+yfx9qGFZH72yntQHfLp+OF
tk9GSU6SoicyPTZ26cImvF1k9cku++QNrNqABUjXelzMypa6RT8jfqIby973YMm7
xKRYgLqVNSWqN9t881F/1ZeHPJy57EtijAqBpA9ZEou4LS7P1+vcuvDelP0XnlsU
Fp4X/I/tkupU0KXZF2F0XUUL+PFLc/IidVjgfkpiafkXDCeTdU7trg+jFGnnvlw7
I9iKxVXEaei7hTi7pwLPnr4Q86thTNsq6X1CHxl/ty1J/0TPcFv4K92uBCQQA7rq
DbUQq1EdFjiD+JLNDP6eLVEVaQPYXaZWRBMS7laUUzG0FXIssFAf/TqnQzA4B3hn
3KoB8Q+373A0OZYL4ki6LdY17prk5P4+5cw09x7qfH/qrldA1iCpVWDsQUV4HpAs
yA/+wVFDZ3eilAqACYrbM9BUa3IfdOBBvdR83ovdFBwSWqNvTTz45aghXxInTAz9
I+6ljQczoW83vl7WWh6Jp+InNpC3g2rAxx02cKMBQhYWJ70WFW0ayLE3jHV3wTCh
rBXiXszC6cjsuAMm2pEAIC6hsYPK9w16EXLtW9Vzz+80K7hZEKflmSugWNg2blzr
mf3jQXmaMD8LI/DtHPds
=4fb8
-----END PGP SIGNATURE-----

Marek Marczykowski-Górecki

unread,
Jun 29, 2017, 4:17:08 PM6/29/17
to lok...@gmail.com, qubes-users, Rusty Bird
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Jun 29, 2017 at 03:30:38PM +0000, Rusty Bird wrote:
> lok...@gmail.com:
> > 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.
>
> I'm guessing you've installed anti-evil-maid v3.0.4? You could retry
> with v3.0.5 from the dom0 current-testing repository, which runs a
> sanity check on your PCR values. See the README in case this check
> fails.
>
> CCing Marek - should v3.0.5 be migrated to current?

Oh, it isn't listed in updates-status[1], so I completely forgot.
Probably it was uploaded to testing before introducing that system. Of
course it should be migrated to current, will do.

[1] https://github.com/QubesOS/updates-status/issues

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJZVWA9AAoJENuP0xzK19csm2kH/1K1MaoE9o+X44HrOZdJuiIQ
dLqv2dK2Bjm1TtaIEaJP+gQ6BUK14xlshFoyVodf3U40BpPXwcRo93MO4+MacJMP
9VOWnOYHRY1nk96Odk0qtGAUe+2N5P/mg3FwSUHXVoCtIHGFMOEx0pvOSMz7SYXn
rRGv6p2dE8MSiym1A1gGXg18oewij1j0xuo41WvA1gjhPgKd3B/AR34XNjIRKzLj
640PLuO7QYBzsejdJxHbZrmadvtpAEvWlz1JEI9biXosW2ToOA/6QRfjYco2T493
wqmm0e7NygMsGtio/mJGgdT1x1a1aHtwi+JR8PSOSxC67/C66MSpBxibhUodJeQ=
=cgrc
-----END PGP SIGNATURE-----

lok...@gmail.com

unread,
Jul 14, 2017, 3:46:00 AM7/14/17
to qubes-users, lok...@gmail.com, rust...@openmailbox.org
On Friday, 30 June 2017 04:17:08 UTC+8, Marek Marczykowski-Górecki wrote:

> Oh, it isn't listed in updates-status[1], so I completely forgot.
> Probably it was uploaded to testing before introducing that system. Of
> course it should be migrated to current, will do.

I updated to the latest AEM, but after I did that, nothing worked anymore. I outlined it in this post, but no one replied to it. Is there anything I can do to collect more information?

https://groups.google.com/forum/#!topic/qubes-users/JMipWyv2heU

Regards,
Elias

Patrik Hagara

unread,
Jul 14, 2017, 4:16:21 AM7/14/17
to lok...@gmail.com, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

This error means that your AEM setup never worked, even before
updating. The AEM boot would always succeed no matter what, even if a
hundred evil maids tampered with it.

Did you follow the AEM installation instruction to the letter? Do you
have Intel TXT enabled in BIOS? Did you download the right SINIT
module and add it to the GRUB config as a module loaded last? Does
GRUB load the SINIT module successfully?

If it still doesn't work, try fully resetting the TPM (usually only
possible from the BIOS) and setting it up again.

See the relevant GitHub issue [1] for details.


Cheers,
Patrik


[1] https://github.com/QubesOS/qubes-issues/issues/2569
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZaH3KAAoJEFwecd8DH5rl2QIP/0dUdW+8Ld74b5McCW5g7HVu
YMTJFORcRRr6/8yyS1h+yplwB4osnI16PhsTNYSJTjMmy/pkKNIm9e9PWE0oOSp7
aVpFKnNVuuupvDFuehJMjtw5fsPkckTbBFBfVIld48Ei/r/C0cTCtU3KTma0BNRN
BJsfN6DuB9bfctbqrywox4l1TyOGlcp0ToVvDB5VQ6zc0gt1qfLfHSd79Il2CrpH
+NqHPbOmLNNAzAEd7iLuoR80mD4AE3tDJBu1RFrIgBHt1Jgu1lxcKjjC2fHHP9Sh
hKZ/TwvbXphGEndLh6vYzuCLCdhvxj/pn2pxJBPWelWiZ3H9PRdmnJ50iNUob/+m
ioS0/NA3hzm0tlTfXpk5AiE964EzbeHokOjJgm6vwgiwELqOviiRwPy8FetjXqMR
Iea39hgKGBAKahbKDEBTkWYW15RjKmG0McjszR7C8e80KVAuaXQyczUU86xyzH8D
jY9mQiM1aliNsRwCKAsq7bHBnozcewYX2WdPqkr9eqd75Gj3Jfnu1Kwi4RSvrbdA
H/Kbx1WxK0deAVT5pxfF1VQTT3h1efZqKZn+BElf2F3f9dk7mp2FOwpe4Sfb+HhT
UpSDV4DE//eCCLYVy5um7iVqKg4n0km0kRIf+/2CVJsQd/P839KDmdsxVf8KjAab
JJXtks6Wai807VtbGHcV
=Bvxj
-----END PGP SIGNATURE-----
0x031F9AE5.asc
0x031F9AE5.asc.sig

lok...@gmail.com

unread,
Jul 20, 2017, 1:32:13 AM7/20/17
to qubes-users, lok...@gmail.com
On Friday, 14 July 2017 16:16:21 UTC+8, Patrik Hagara wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 07/14/2017 09:45 AM, lok...@gmail.com wrote:
> > On Friday, 30 June 2017 04:17:08 UTC+8, Marek Marczykowski-Górecki
> > wrote:
> >
> >> Oh, it isn't listed in updates-status[1], so I completely forgot.
> >> Probably it was uploaded to testing before introducing that
> >> system. Of course it should be migrated to current, will do.
> >
> > I updated to the latest AEM, but after I did that, nothing worked
> > anymore. I outlined it in this post, but no one replied to it. Is
> > there anything I can do to collect more information?
> >
> > https://groups.google.com/forum/#!topic/qubes-users/JMipWyv2heU
> >
> > Regards, Elias
> >
>
> This error means that your AEM setup never worked, even before
> updating. The AEM boot would always succeed no matter what, even if a
> hundred evil maids tampered with it.
>
> Did you follow the AEM installation instruction to the letter? Do you
> have Intel TXT enabled in BIOS? Did you download the right SINIT
> module and add it to the GRUB config as a module loaded last? Does
> GRUB load the SINIT module successfully?
>
> If it still doesn't work, try fully resetting the TPM (usually only
> possible from the BIOS) and setting it up again.

Thank you. This explains some of the things I have seen.

Unfortunately I have reset the TPM (multiple times, throughout my testing) and I keep getting the same error.

I have also double-checked the SINIT module, and it's the correct one.

As for Intel TXT, I can't find any option in the BIOS settings to control this specifically.

Regards,
Elias

Patrik Hagara

unread,
Jul 20, 2017, 3:18:26 AM7/20/17
to lok...@gmail.com, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Try checking the tboot log (from dom0) for any obvious error messages:
sudo txt-stat


Cheers,
Patrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZcFk4AAoJEFwecd8DH5rl6xEQAIh0giBQUHatOGRkw8Q0mkdh
QVseDFR7sacWB15Zb9cYqnwg4grSpO/dazVh8ZH6xYaZFS3EZrBWwFwQ4hItWqzh
/TQ02i8IGLoa2LyVrNhYefXprPtzwBt9zz7KPpxqyzyol9i1E672GgJlq/P3FCjv
5asn0k//5WeNsgY6PRV7BMXaXVnLWWFeucEi4FE7uOcmyKHBpViIGrL3CM69Sqll
xNm/Rpy/n20gxNyQF2BbYaj+elV9LU4gw/8hH36TRtSaMpxNMOX/hZcHz5W+FKec
/DZxeLEJq+CSPLsGckLhV6rn1SzH3Y9eCc67VNP+wbjgjDdWeFiufmTT4nNzJnsF
ruMP4nvdJQ0g4APBQYk3GkpSOfgLqUlRC2WFdq8/acO2ht0vcEWFsNGq54XeZoxe
MQjRhXXQskpTApmcBOEUWzbNA2c3kLd7pYO+0J3/CLvmytnN+TKIbcq+iBO+Co2a
kgSgViJUQevzL+IAQ7qh12xFuGcth/Dfkj/BU4PQa0itwF9muOqeabcxW0eMyvU0
jrkr27lnppbVkm+V48jDYio1tOYykLAoIyd1XnzeLXdSWzPPhGtSUH54CDxJrsXk
jD91eYd11B64AkZi4d4iN1AlwriQjPGiXaSh+cvKtTmIs/d6PH0APA1bLl1tbtzJ
PWAqakWrXj/0wHI4Mk7g
=ZGT9
-----END PGP SIGNATURE-----
0x031F9AE5.asc
0x031F9AE5.asc.sig

lok...@gmail.com

unread,
Jul 20, 2017, 3:42:06 AM7/20/17
to qubes-users, lok...@gmail.com
On Thursday, 20 July 2017 15:18:26 UTC+8, Patrik Hagara wrote:

> 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

Patrik Hagara

unread,
Jul 20, 2017, 3:58:36 AM7/20/17
to lok...@gmail.com, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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. :)


Cheers,
Patrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZcGKQAAoJEFwecd8DH5rlzoIQAKVWGdgh0jy+eR6Lx292zmlb
ZDFtbeQaothuOLw4O0ZhJojGObmQLBaXjH7L8tveTiBaa1P5GH49W9Vll4eVyeyo
fQ9RicCUexvMBTxvZ/bpdGG+SJYirK6Ky2qVv4m/7aipMAf9aCbg4wZ25PBlMePn
Brjg8vzFXoW+0n00EpDQ1EHdq8sUe2bfVNGQallnbgPwVm6SPQ2BWY3+LdXeMjKT
Ra6cyt/iQHne0Iy6y0BCWhjSfk74KJ4Uy8Gs8CTvSUC3rIHAdBFoL30kZ5VMcRBe
4r7dFs1+a1DuzjMXySBxsbR1G6VgjVqikxYTvM+M6MuBWrr97wFHTOLEf0xQIcuV
T0wSHoMjpqnd0OJUBWVe2bAFpvBRRRTeetc1P+J40QKQ73COBqpUF+Pohamw8ox8
bxzb68FdcfengVuskft843MCHgNMe4LCUCRK+yv0X586sSXSs+69yCe/JSWbtCmJ
aU87+qvNeV4jZugWrZQ2THX+QOIyRJu0acUzJY2hGFMRBmAgY2NqD6x3MNq/Tpgx
jk3+K8LoA/KGm2aBAnP5rqjLDsYHeVlTlX7fcWry9s1rfv+5jI6J2+yG0YxWNWPo
m3BlOhK3rnoEqUf6/ERedtwkc3UxPtOszlvwhjxiUSTc0jo6ZU2EP9+phoTRpNcb
/+cqdp81EapfFWbp9qnb
=c6f7
-----END PGP SIGNATURE-----
0x031F9AE5.asc
0x031F9AE5.asc.sig

Elias Mårtenson

unread,
Jul 20, 2017, 4:09:54 AM7/20/17
to Patrik Hagara, qubes-users
On 20 July 2017 at 15:58, Patrik Hagara <patri...@gmail.com> wrote:
 
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. :)

Thanks. I got three screenfuls of information. I've shared the pictures here: https://photos.app.goo.gl/xNaxca5fxviwmfw12

The error "failed to get public data of 0x40000001 in TPM NV" seems interesting, but I have no idea how to deal with it.

Regards,
Elias

Patrik Hagara

unread,
Jul 20, 2017, 4:22:22 AM7/20/17
to Elias Mårtenson, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/20/2017 10:09 AM, Elias Mårtenson wrote:
> On 20 July 2017 at 15:58, Patrik Hagara <patri...@gmail.com
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
.


Cheers,
Patrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZcGgzAAoJEFwecd8DH5rldX4P/3oMCuGLbS2tgSqu5VGerZ9w
o4G8vBqKqANF9jusTEFdT/8dOLrrwOwsJDpFUWyBQS92PYgCl5nQzCcyi5X6u+Ek
bJsoGDRk574/B3j0yeuJVzAzCqD96Tse/3/XUGu6Jz996lSW+++77sTGLPZGR9yC
q3xmRtWy+DSV+3HbK75aVe+vzpNmmH4kMDtOJGcAm8LBEMmjNF/LNVVfs/VnS16q
wW2GN51EANmtbStpGzZ9wklfkWDUTF3Nzrk2h37n12MiD0esVtuIjIUEOc04eFLL
UoSGygv5hYWzLIretjmBXMZINic4od/+xiHxNku01CbPVkvr4nRl/xwH4UnAQncn
HqQtiXRkKhCXxYJnyinDJV7Lqaiskppg4W0YdPUrRgjO5vlBL1wGET7DOytJYsmc
YxNvAz4Yz3Cbp2atnFI4LkoGNnGUwymWNSBPNh4izSckO3jRw0ebfoObRXfC+p1g
1FiZtCQgsftV3oKz7FVReAUbOkqDqFtbGUNh/Uqo3kQZhq/VSkYbVOglz72h7NWq
mSkNSY4VXAPJEPj0+cI4K6mTtHiWPEQYFq6BOLU6znX/W4X9qruUemRD7UYx9DPY
HYP4O4rd9A/dHj4m+p048WjrH6e1yg6OoLPh7oduUlXb0CU9yE/KYPvoOVj6lJp6
1xuEE7bRyPdUEZ70dZXB
=Nyes
-----END PGP SIGNATURE-----
0x031F9AE5.asc
0x031F9AE5.asc.sig

lok...@gmail.com

unread,
Jul 20, 2017, 4:46:01 AM7/20/17
to qubes-users, lok...@gmail.com
On Thursday, 20 July 2017 16:22:22 UTC+8, Patrik Hagara wrote:

> 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

Patrik Hagara

unread,
Jul 20, 2017, 4:51:24 AM7/20/17
to lok...@gmail.com, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

This sounds like the exact same issue I've encountered -- and managed
to fix by adding "min_ram=0x2000000" to the tboot cmdline arguments
(see tboot readme [1] for details).


Cheers,
Patrik


[1] https://sourceforge.net/p/tboot/code/ci/default/tree/README
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZcG8CAAoJEFwecd8DH5rlHKoP/3sSvU39IJCrCzCj0H4KBaXW
tFsAzDvjsMD537AtVXUUVrEKoWiIHpBc4fU050Liwjb+ryRX52kS9x+lV8HrpBZ4
/y4eU/Yyc8D3rO4OSw1hPx/8tO7VlnP+kG/Vz//4lC1ZTYy0wokV0eZPjakQ3USk
u4RM1rkTnhwjKyzr95BbAIyOrFkMhLI6eftR4NYmx7c7sexEhOTFYXb4CKw9xNYZ
FfGKG46BUjPEThnijAPg4CEf8OpGXeL2kOq2k7GWsyB4e2Si9uBE8mzt6FT8VLJe
I5RRkVLpRt00/QM6zupfmxjowjW2zEWyWgh19QrHvbLrB/hh9UdJOogvYIiBU3Aa
Q41t4BWA6xDrgi4FYqs+fnG7Yn4N1ovBQikZbo2LWrhkPIlWp4JB3jn4h6rqe8Lr
3ZZ8W61eRkgzPd3hFblECBqe8V6M08HoIBpyDXasMWpglQXjAPrfrzzC4uuyUPzT
7ARTGqkfArSL0zHpQZzTXrTOamHL1RQ0nV7j53ki06RAepuVEsI/G4Z0y9XPTE7e
JwNU3FzGZ+iPpF/qQlOBurFiDn5yGsO5QI4GM7pcOqHBpJBCcpghlF4/1H7RiNde
/JbacGckdV6bQ9Z9f6tUDH+7hBghj94hgv3nxJrzyIE5NV4JLlk/mfEzKgZwHjSt
Y/Q06Ky+WqfAvwQC5THY
=RvYs
-----END PGP SIGNATURE-----
0x031F9AE5.asc
0x031F9AE5.asc.sig

Elias Mårtenson

unread,
Jul 20, 2017, 5:21:40 AM7/20/17
to Patrik Hagara, qubes-users
On 20 July 2017 at 16:51, Patrik Hagara <patri...@gmail.com> wrote:
 
> 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
to fix by adding "min_ram=0x2000000" to the tboot cmdline arguments
(see tboot readme [1] for details).

Thank you for your suggestion. I tried this (and also read the README file you helpfully linked to).

Unfortunately it did not change the behaviour, and the machine still reboots at some point after SENTER.

Regards,
Elias 

Patrik Hagara

unread,
Jul 20, 2017, 5:31:19 AM7/20/17
to Elias Mårtenson, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/20/2017 11:21 AM, Elias Mårtenson wrote:
> On 20 July 2017 at 16:51, Patrik Hagara <patri...@gmail.com
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.


Cheers,
Patrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZcHhcAAoJEFwecd8DH5rls4IQAJ5+6NVAGHShUWGT6w0AtIuW
RhGbvbU0E3rYpTP6XjIlKLVCT7/Kwl5T7tLx4xbzvU5h667oGuDncFpHiXmXioSp
WqycV7pBcuZPszOOUYKtcnlI8DO9KctelzdnIXarkFs03aAkA7cpuK8/awHziz+Y
yZLBxRhYnC7dCUrcy0JOCCOQO+vLmFWUXVHSbHR71OYHSruapfi9VXoua/j7mtJd
QOd9+30ilPqV5JoNswGtdIfbRIN0CTXFynQ4hGHTOJ0IDRYWI8dKBePhTRZ1v9VK
JnbEdULCNHPAt/kWaShs2UOFGhrR6MAe5W4NNzFMuJGfoDsMIbw7INQw3FkH3q+S
k7tZS9keiTA4jFctT7kJFfoZ0vdYYpvjUJ2P7V8QI8bjm1Q10RH5ZMkTFAffaIvA
pH3coVwk6qcJ1GO5MabZKrOmOJfdxgU4bm803zk3OSkIgJJmf1aUoVeAyXtaclzb
J/UIlOQRaJ1S3JVzOTdSFr0J0RPzW7MZolIthqDGYRfmjlKX65TBCm7VrrH/P9tU
nNENBs68rgCqz19Gd4lxXC9zDp0dlrh46b+VOEZH692uwwJG0Lq3sGwX+C7odx/7
sZBx6BAoMi0xwQVc54WSvTiu5+9PxBjykeIcwUSC3RTQDTpF0p6S8ptIqEv0uIhB
fC1/Z5V/StonWAcfBHDn
=6Vps
-----END PGP SIGNATURE-----
0x031F9AE5.asc
0x031F9AE5.asc.sig

Elias Mårtenson

unread,
Jul 20, 2017, 5:44:22 AM7/20/17
to Patrik Hagara, qubes-users
On 20 July 2017 at 17:31, Patrik Hagara <patri...@gmail.com> wrote:

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.

Thank you so much for spending time on this.

I took another set of pictures: https://photos.app.goo.gl/IZFNokdsfClsWwNz2

Regards,
Elias 

Patrik Hagara

unread,
Jul 20, 2017, 5:45:54 AM7/20/17
to Elias Mårtenson, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Also, do you have testing repositories enabled in dom0? According to
this [1] Qubes issue, a newer Linux kernel version might work (and it
might be the reason why me removing mem_min didn't bring back the
SENTER boot loop).

sudo qubes-dom0-update --enablerepo=qubes-dom0-testing

If that doesn't work, you can try manually upgrading tboot itself
(since Fedora has an ancient version packaged; instructions in the
issue comments). I'm still using the Fedora-packaged version though.


Cheers,
Patrik


[1] https://github.com/QubesOS/qubes-issues/issues/2155
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZcHvKAAoJEFwecd8DH5rl9pYQAJT+xLXnNQDFS/Cnp8ddHxXp
yLUCAj9+zzIOb5Mc/v5lIoZckFQ+3gZR6ousR9BqsxauRmo3hVuJ8cOFBCGJSQ48
IECBJgTAnaqfl0oR7yTcKkGXRUAtecP3O4ETEhCNvQdEc6LM3Y6KaSh2XnHm3TiC
hGaQJuveAKvKxT+N8xbhqJm9rciEq3sx7ZRLKzKt7ohBUEO8owDE+Xd84NbnGTxf
ZoWg1MpiAa/NzlUMB9KlkMQMEfJ4gDS3k8GT5A0YgtZFjlYs5zf9i/pUsSVzTEVk
GOexrx8JFEbI1fgZ6JjdXkDwWXoyuvEYC718ztZrC4goZH2GD7TnF92s0chmLCip
/MSRi/8n4gmx9hSM6FelcVEHorGC3A3DU+4RCfqbIsrdtGQ+JRUcyB961urzR75m
Oerip/SLYU5rgOmUJg8SKvDlPHKTaDhC3JlXPohE+ijjYuTD5W12jUHvsY5w5CpR
OGQ4zBLMpGH3ZJlqZYmfxGvkWTWjZ2PDhQRmLyaSy6WWzW/0luRr7hPkjQJVb1k4
+2D5uWrCmhwZb2ykIgxymqycCSI7p/YB4PUojhYuD7dvCAMaOwglKYLio/lGcHBf
nsMaRejHPkVy/cDF8UWbVEayM5EjdWc3b2dqmlqJShQM9qTakU76++UChFJUYVmI
57YuL8TBjwF9kRvvACS+
=gp2+
-----END PGP SIGNATURE-----
0x031F9AE5.asc
0x031F9AE5.asc.sig

Patrik Hagara

unread,
Jul 20, 2017, 5:49:28 AM7/20/17
to Elias Mårtenson, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/20/2017 11:44 AM, Elias Mårtenson wrote:
> On 20 July 2017 at 17:31, Patrik Hagara <patri...@gmail.com
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.

Cheers,
Patrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZcHygAAoJEFwecd8DH5rlirUP/2+eFuyiht/4fET2fnR1ejbt
t6UJaGtk5emy2YwD9J3MklOfyGv1lKVWwfjzslaYir3KgHuCzDWo4Pu9b0bwlo2u
6nVzE1Q2LbdhOcVeD5zFWvpcLyWCE23ttVYkCgGIEXnYgDMzCJ+8q9eKTLmyzg6k
KvYGIRRm/OTG1T+Z8plRx5ikL4Jk4XPwv9b2SUapIamu7Ng9JgAQ95o07BOOMhp0
TIegp4zgf0Y01wDeIRUPmXOnKcQzVM2eCI07IZVhrRyfFNNl26SqyD4hXVzb7eCD
5oJs9H65B6mg4GxcKnDDNFFxkLNbFmreQrYdrL8YQS7wyvOmtQAX6Ofx4w7HX47j
B2PMGx9Jp7Ue1mQ3hGexUduN6Iv9+vLqgOkejMb7p3HE7b/nb3Sr3SPyhUtY2V7q
/tuebVFsmQlQmnXBQG5SIs8iR/RDFaxhwyIasUUimS6ZyQ8RidefctAl7FMTHfED
+eTzKyrRvqzC7sZRAUdQC6nl3mOoktLwIs7AGactN09ilLfNxp5b6rmJjoZR2eso
AvmSl8p4t2cZ9dYVeLPlQT35jkcHJvM3dxER6kKcScNyOWxAUMCYC5+eEg/bngeC
mDpMl79JLZdmWQ6PZAtUsZK87VeNZszvfbXVif0EaVuPz2diJOH4KzY008yY0bnH
P7/q6BLR9vtdSl5oWdfa
=PzaP
-----END PGP SIGNATURE-----
0x031F9AE5.asc
0x031F9AE5.asc.sig

Elias Mårtenson

unread,
Jul 20, 2017, 7:13:48 AM7/20/17
to Patrik Hagara, qubes-users
On 20 July 2017 at 17:49, Patrik Hagara <patri...@gmail.com> wrote:
 
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.

I now have Kernel 4.9.35, which is a great thing (I can now disable tap to click, finally) .

However, I still get stuck in a bootloop when I try to start AEM. Is there a way I can tell if it even starts running the kernel or if it crashes before it's loaded?

Patrik Hagara

unread,
Jul 20, 2017, 8:08:35 AM7/20/17
to Elias Mårtenson, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/20/2017 01:13 PM, Elias Mårtenson wrote:
> On 20 July 2017 at 17:49, Patrik Hagara <patri...@gmail.com
Yes, for Xen you can replace the "console=none" parameter in grub.cfg
with "console=vga" (and perhaps also add "sync_console=true"). Another
parameter worth mentioning is "tboot=<address>" -- this should be
automatically added by tboot though. For a complete list of supported
parameters, take a look here [1].

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.


Cheers,
Patrik


[1] https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html
[2]
https://www.kernel.org/doc/html/v4.10/admin-guide/kernel-parameters.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZcJ05AAoJEFwecd8DH5rl8IYQAJ6xojzkXON9FUtEwVSTZbDB
lVKsUeYHulCGVDmKaKdcdv8FPsJuUTb4pK00yNfrgR+siDg1ViPnw20v8bRVBoC2
7zWlt6molSH5tV9DoEW9kFBdy//Ow+8N3izVnnxkjVu7oS7ISWBZayZ5q72SffL1
Mxvwh1aNOz5Samy3ERvtlH60QCGy6fIynKRDRx5n6MoskpISKQ0jQBDF8U2TLMk4
9VpmW+gSkgvkKuWtHMJuz7jjOoWfV2K5I66z/OmPP1QYueOkM1fH21cRF0zuxFRV
DBr0fMMG/2pWeZEZAWhc/gZTq4x/Pclzs3F1L+iFhAId1ywJG4O4NLa4E056VtvU
tw9B/lTRjEH8o6I4QH23VaDXxLlDoenuhSAY6NWGoZawLetj+RDweE6VbxkpYKUj
rrqAgkae9w5K6XmJgAvpsH6HFrCLUkQ0uDOd1eBWl4I9yG0m5ROpMDxXiSzzS8+u
l/vLXesXY3i2ckvsro+gvG1tr2cOzFObYMKe9HK96apgGvUKlMB2QITbP3X3Kn7X
TLObGjkUUbSHA6qJE/Z/3sQcMp8+mKtkzg0IzRGM/4IP3EOt4MjkTFKSqM4E1+29
BXa1dS+eF+lNksOII7MtO0bnM0kfaza/TWhv00KNKaKrQrawaqsBlqbnrglakrcI
abiXdQkB08ZezKUwXbHn
=vkq8
-----END PGP SIGNATURE-----
0x031F9AE5.asc
0x031F9AE5.asc.sig

Patrik Hagara

unread,
Jul 20, 2017, 8:29:11 AM7/20/17
to Elias Mårtenson, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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.


Cheers,
Patrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZcKIGAAoJEFwecd8DH5rlcLsP/jLQ9qSXxKnOI1ve6WBUcYKY
OspRC9eDuqAOkO0R7nqK33yd1RJpnJevTwtBrL8hnKO2JcC925NVjYdD/zhtavPo
rydDvgXjVVE4nWeWH6aJaiJVOnNOicUiVnfIbQE0jeUCN6HCyb0RPUPVQZ4CrHf4
KfsyWcNFQ0r4RA2M27U7ACwzYInzZVBIuLgO+OG2OltjCHCc+ljjptDiZ1aNE3RX
JWF21H0k/GwjsHYmLJo7/Ee3kiMdyok4fy7gzzXljpCrjHG6NUBWgZC8VgfosSk+
3wTdxq/TdfGIk9X2Ulo192Cszd1JMIbkloUXIqyJaISH4zh/ot1Nasqnf+eLMc6Z
EuSnKCOV2raGR9UMziK1dL8kc7zfl+fMXTLgwkaZAcKtAu3ME0QDvo2dqswGlhn+
hlZCYfKztABhFM8gDtd1cTf3XD1eg8lJKmeFdGZ0odCfnw+V3cQzJFGAzkcY/Ey6
ialJnQvOrQiKCdqZv1reNRgytvqqJ4RUfQRveMCu25glJw9IJybmtXqoI/gaUE29
Bq3la4/TUVqtyS8bU5CgDMpfyQ7q54MuiT+sUtA9RtoX2VF7c1JKWh0JshRIJQyS
Vx99f2RVGmA8rqQ50wUP4r2niB2EPZx/sf3ck76v2+pdUdPeW/vTOxrEkPJhCELL
8nVnOPGA35SncpjEMdVg
=crRr
-----END PGP SIGNATURE-----
0x031F9AE5.asc
0x031F9AE5.asc.sig

lok...@gmail.com

unread,
Jul 20, 2017, 11:00:26 PM7/20/17
to qubes-users, lok...@gmail.com
On Thursday, 20 July 2017 20:29:11 UTC+8, Patrik Hagara wrote:

> 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

Patrik Hagara

unread,
Jul 21, 2017, 6:46:26 AM7/21/17
to lok...@gmail.com, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Xen should get loaded right after SENTER which then starts dom0 VM
with the Linux kernel + initramfs.

If there's no Xen logging at all... I'd try performing a TPM reset via
BIOS (there should be a TPM reset flag you can turn on and it will get
cleared during a few reboots after saving and exiting BIOS), then
shutting down the laptop, taking out battery and disconnecting AC,
waiting 30 seconds then putting battery back in, connecting AC power
and booting into BIOS again. Then reset the BIOS itself, performing
the same battery/power/waiting dance. After that enable the needed
options like Intel VT-d and TXT (as those will most likely get
disabled after BIOS reset), disabling EFI boot, then make sure to
completely turn off the laptop for at least 30 seconds again. Lastly,
take ownership of the TPM.

If it still doesn't work after this, I'm pretty much out of ideas...


Cheers,
Patrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZcdtpAAoJEFwecd8DH5rlRr8P/0sjU3r+2Ru917ZT4G/tF1vP
5uZIb2D0hrzA8+MnE+CvBt7WoXlCLsFyvExVhOGhMNq0Zvu5A9ZvqLr/HbGOaHt2
d+gfESk4EiRYAWHMo1AgC190dr1Qv1xuCK11cFLQ6Grx2rMfjxp/bUUq8TKP9c3Z
Ddq7ITK43nC3Yge7RAwkww6a0djXaVhRAK+4iw0eke4GYxysNxVKiXj+mn5uFEfd
qcdfe9BrlXxkXBlLtv98Erk46zV4pJHhfYSqHqhTO5n32KgqcJcqNfbQn4lTyXfc
a93bZX4MCcprY/3PwsgKeKtaUBU2bfAnGk16FSLXVeijdRSARiUaF270N8a2sWjh
Avk7n4DG6Tlm27nZysPXq/auaX1xp4FI91u6NgStxvVRUXcyXCyJgdK+Do2B2D7o
7W1nR+uNmzVX7pRzFTTZToJ0Wbhz79qZg3TSRq+TR6dOJ+9FcjD8SyPirw6ng7Z4
aro6DotdI139haRTFGk4xB6WKptyvJE+g58hUCPeelXo+u+zdDYigl5MaI1pgoio
Vx1cGswLu1pdnCyCBXJkOrUNJSDS0lN4H+cGMpxuBhvaQcu4UTixT2jiMVQWT7lm
xXxWk+LL7MR6BiT4cLGwOI2PlZrVsNc53HlkcII7mrfhf19wpwgNMJGMDO2um+aa
OlSw6o9R3YiRY9sbGc7X
=/+53
-----END PGP SIGNATURE-----
0x031F9AE5.asc
0x031F9AE5.asc.sig
Reply all
Reply to author
Forward
0 new messages