[Security] Anti-evil-maid didn't notice Xen update ?
151 views
Skip to first unread message
Swâmi Petaramesh
Nov 30, 2016, 2:09:46 AM11/30/16
to qubes-users
Hello,
I use Qubes 3.2 (recent, default installation) with anti-evil-maid on HP
ProBook 6470b.
Anti-evil-maid is installed to HD /boot per instructions, TPM is
protected by a password, and I use a "secret" image instead of text.
So far everything seemed to work.
However this morning I had a Xen upgrade in dom0, and, as documented, I
was expecting it to break my AEM secret image display at next reboot.
So after upgrading Xen in dom0 I rebooted the system and... nothing
special hapenned. AEM displayed my "secret" image as usual, without any
unusual behaviour or warning whatsoever.
So I wonder : Is AEM actually working on my system ?
Any clue appreciated.
TIA.
Kind regards.
--
Swâmi Petaramesh <sw...@petaramesh.org> PGP 9076E32E
I use Qubes 3.2 (recent, default installation) with anti-evil-maid on HP
ProBook 6470b.
Anti-evil-maid is installed to HD /boot per instructions, TPM is
protected by a password, and I use a "secret" image instead of text.
So far everything seemed to work.
However this morning I had a Xen upgrade in dom0, and, as documented, I
was expecting it to break my AEM secret image display at next reboot.
So after upgrading Xen in dom0 I rebooted the system and... nothing
special hapenned. AEM displayed my "secret" image as usual, without any
unusual behaviour or warning whatsoever.
So I wonder : Is AEM actually working on my system ?
Any clue appreciated.
TIA.
Kind regards.
--
Swâmi Petaramesh <sw...@petaramesh.org> PGP 9076E32E
Jean-Philippe Ouellet
Nov 30, 2016, 3:41:09 AM11/30/16
to Swâmi Petaramesh, qubes-users
Check if the latest xen version installed is actually the xen version running.
I had an issue where the update did not modify the appropriate EFI
variables and I was still running the old version after the update.
This issue has been addressed, but perhaps not completely.
You can check the versions with the following:
# for version running:
[user@dom0 ~]$ xl dmesg | head -1
Xen 4.6.3-22.fc23
# for version installed:
[user@dom0 ~]$ rpm -q xen-hypervisor
xen-hypervisor-4.6.3-22.fc23.x86_64
On Wed, Nov 30, 2016 at 2:09 AM, Swâmi Petaramesh <sw...@petaramesh.org> wrote:
> So I wonder : Is AEM actually working on my system ?
That is definitely something that should be tested while setting up
and not something that should only come into question at a time like
this. Make backups, flip some bits, and see what happens? ;)
I had an issue where the update did not modify the appropriate EFI
variables and I was still running the old version after the update.
This issue has been addressed, but perhaps not completely.
You can check the versions with the following:
# for version running:
[user@dom0 ~]$ xl dmesg | head -1
Xen 4.6.3-22.fc23
# for version installed:
[user@dom0 ~]$ rpm -q xen-hypervisor
xen-hypervisor-4.6.3-22.fc23.x86_64
On Wed, Nov 30, 2016 at 2:09 AM, Swâmi Petaramesh <sw...@petaramesh.org> wrote:
> So I wonder : Is AEM actually working on my system ?
and not something that should only come into question at a time like
this. Make backups, flip some bits, and see what happens? ;)
Swâmi Petaramesh
Nov 30, 2016, 4:52:50 AM11/30/16
to Jean-Philippe Ouellet, qubes-users
Hi,
On 11/30/2016 09:40 AM, Jean-Philippe Ouellet wrote:
> Check if the latest xen version installed is actually the xen version running.
[root@dom0 ~]$ xl dmesg | head -1
Xen 4.6.3-24.fc23
[root@dom0 ~]$ rpm -q xen-hypervisor
xen-hypervisor-4.6.3-24.fc23.x86_64
[root@dom0 ~]$ rpm -qi xen-hypervisor
...
Install date: mer. 30 nov 2016 07:46:15 CET
...So it's the latest Xen, updated this morning, and AEM doesn't seem to
care.
> I had an issue where the update did not modify the appropriate EFI
> variables and I was still running the old version after the update.
> This issue has been addressed, but perhaps not completely.
I'm BIOS legacy boot mode, as AEM documentation advises that booting in
EFI mode is not supported...
>> So I wonder : Is AEM actually working on my system ?
> That is definitely something that should be tested while setting up
> and not something that should only come into question at a time like
> this. Make backups, flip some bits, and see what happens? ;)
Uh, Haven't had the time : I installed Qubes on this system one week
ago, and AEM 2 days ago... ;-)
Thanks for your help !
Kind regards.
On 11/30/2016 09:40 AM, Jean-Philippe Ouellet wrote:
> Check if the latest xen version installed is actually the xen version running.
Xen 4.6.3-24.fc23
[root@dom0 ~]$ rpm -q xen-hypervisor
xen-hypervisor-4.6.3-24.fc23.x86_64
[root@dom0 ~]$ rpm -qi xen-hypervisor
...
Install date: mer. 30 nov 2016 07:46:15 CET
...So it's the latest Xen, updated this morning, and AEM doesn't seem to
care.
> I had an issue where the update did not modify the appropriate EFI
> variables and I was still running the old version after the update.
> This issue has been addressed, but perhaps not completely.
EFI mode is not supported...
>> So I wonder : Is AEM actually working on my system ?
> That is definitely something that should be tested while setting up
> and not something that should only come into question at a time like
> this. Make backups, flip some bits, and see what happens? ;)
ago, and AEM 2 days ago... ;-)
Thanks for your help !
Kind regards.
Chris Laprise
Nov 30, 2016, 6:24:49 AM11/30/16
to Swâmi Petaramesh, qubes-users
Can you restore your system to the point it was just before the Xen
update? This would allow you to reproduce the behavior.
Chris
Rusty Bird
Nov 30, 2016, 9:18:33 AM11/30/16
to Swâmi Petaramesh, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Swâmi Petaramesh:
Is the SINIT module working? Run the "find" command from step 2b of
/usr/share/doc/anti-evil-maid/README, but look at the lines for PCRs
17, 18, and 19 instead: They should have very random-looking values.
Is AEM sealing to the right registers? If you run the command
"source /etc/anti-evil-maid.conf; echo $SEAL" in dom0, it should print
"--pcr 13 --pcr 17 --pcr 18 --pcr 19".
Did the unsealed image somehow end up in the wrong place? The file
/usr/share/plymouth/themes/qubes-dark/antievilmaid_secret.png should
*not* exist in dom0.
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJYPt9+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf0fUP/2gkPIN1SLnXan651FCAwffs
wrIGKBLB+gJbEinU4RdwHcKYO1bprMrPLCHsI7MjoAU0/MVQ4p2aV6Uay76NX9ZY
ggktq4paOwXW0xq8IbXJH5YFw5y/FTeS8SAFn8c7KqbBiNMMXPLNiKUwiGoQ6Tws
MhVwC62R70qnjNIQBVdlfu3H+CqIIOU5qpl0v/bc1Iyc6oYre54fcN6bBSDgbRFk
tMWrrC+ljQrXI+n8g3y5oQdUpX2Lmt9C/v3x3ld8mVLwIDrtR3mnz9l2CR6tZsRQ
8anTNaaQ1rdx+FPECCOOXL/yF7qLLRqkMEURb0APYpYHjsEbcXyc9BpNLNRs1aJm
Thf4AokTVC6rX2fPYf8q78SUmvs8G9mEYbnPm5XyKYmvoVbkTVdEStz2uy+PFJWa
gsI2O5UFUjQA0xbWg8aYgVmx30LzSbnS92WOadV/dT+jvbjeZOZ29wn+qyCQUUm0
9UXWW86EAEUQJj0zWhJrjyrZY+H7dGBqy/az7gCR6BTyI7ryIa4C6dzTmg8Vohyb
chlR5DTq0Pb83EZ9jEzYbgNbrN6f3mO5EwYLoYHDfJaIfpn5N5VpMDYInhEBBeRQ
7TZpMrPEOu8RM3yQLTiuS3gaEgx1ml9Pu8qQcd7aubP2OTB2RKLhm2BL1oYMrn6E
VH4tOReX0O97HjpJWvE5
=JmZ6
-----END PGP SIGNATURE-----
Hash: SHA512
Swâmi Petaramesh:
> So after upgrading Xen in dom0 I rebooted the system and... nothing
> special hapenned. AEM displayed my "secret" image as usual, without any
> unusual behaviour or warning whatsoever.
Some things you can check:
> special hapenned. AEM displayed my "secret" image as usual, without any
> unusual behaviour or warning whatsoever.
Is the SINIT module working? Run the "find" command from step 2b of
/usr/share/doc/anti-evil-maid/README, but look at the lines for PCRs
17, 18, and 19 instead: They should have very random-looking values.
Is AEM sealing to the right registers? If you run the command
"source /etc/anti-evil-maid.conf; echo $SEAL" in dom0, it should print
"--pcr 13 --pcr 17 --pcr 18 --pcr 19".
Did the unsealed image somehow end up in the wrong place? The file
/usr/share/plymouth/themes/qubes-dark/antievilmaid_secret.png should
*not* exist in dom0.
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJYPt9+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf0fUP/2gkPIN1SLnXan651FCAwffs
wrIGKBLB+gJbEinU4RdwHcKYO1bprMrPLCHsI7MjoAU0/MVQ4p2aV6Uay76NX9ZY
ggktq4paOwXW0xq8IbXJH5YFw5y/FTeS8SAFn8c7KqbBiNMMXPLNiKUwiGoQ6Tws
MhVwC62R70qnjNIQBVdlfu3H+CqIIOU5qpl0v/bc1Iyc6oYre54fcN6bBSDgbRFk
tMWrrC+ljQrXI+n8g3y5oQdUpX2Lmt9C/v3x3ld8mVLwIDrtR3mnz9l2CR6tZsRQ
8anTNaaQ1rdx+FPECCOOXL/yF7qLLRqkMEURb0APYpYHjsEbcXyc9BpNLNRs1aJm
Thf4AokTVC6rX2fPYf8q78SUmvs8G9mEYbnPm5XyKYmvoVbkTVdEStz2uy+PFJWa
gsI2O5UFUjQA0xbWg8aYgVmx30LzSbnS92WOadV/dT+jvbjeZOZ29wn+qyCQUUm0
9UXWW86EAEUQJj0zWhJrjyrZY+H7dGBqy/az7gCR6BTyI7ryIa4C6dzTmg8Vohyb
chlR5DTq0Pb83EZ9jEzYbgNbrN6f3mO5EwYLoYHDfJaIfpn5N5VpMDYInhEBBeRQ
7TZpMrPEOu8RM3yQLTiuS3gaEgx1ml9Pu8qQcd7aubP2OTB2RKLhm2BL1oYMrn6E
VH4tOReX0O97HjpJWvE5
=JmZ6
-----END PGP SIGNATURE-----
David Hobach
Nov 30, 2016, 1:36:47 PM11/30/16
to Swâmi Petaramesh, qubes-users
On 11/30/2016 08:09 AM, Swâmi Petaramesh wrote:
> Hello,
>
> I use Qubes 3.2 (recent, default installation) with anti-evil-maid on HP
> ProBook 6470b.
>
> Anti-evil-maid is installed to HD /boot per instructions, TPM is
> protected by a password, and I use a "secret" image instead of text.
>
> So far everything seemed to work.
>
> However this morning I had a Xen upgrade in dom0, and, as documented, I
> was expecting it to break my AEM secret image display at next reboot.
>
> So after upgrading Xen in dom0 I rebooted the system and... nothing
> special hapenned. AEM displayed my "secret" image as usual, without any
> unusual behaviour or warning whatsoever.
>
> So I wonder : Is AEM actually working on my system ?
Apparently not.
> Hello,
>
> I use Qubes 3.2 (recent, default installation) with anti-evil-maid on HP
> ProBook 6470b.
>
> Anti-evil-maid is installed to HD /boot per instructions, TPM is
> protected by a password, and I use a "secret" image instead of text.
>
> So far everything seemed to work.
>
> However this morning I had a Xen upgrade in dom0, and, as documented, I
> was expecting it to break my AEM secret image display at next reboot.
>
> So after upgrading Xen in dom0 I rebooted the system and... nothing
> special hapenned. AEM displayed my "secret" image as usual, without any
> unusual behaviour or warning whatsoever.
>
> So I wonder : Is AEM actually working on my system ?
I made the same experience in the past and couldn't identify the root
cause neither (I tested most of the stuff mentioned before).
My old thread:
https://groups.google.com/forum/?_escaped_fragment_=topic/qubes-users/xNIiSyJQD0E#!topic/qubes-users/xNIiSyJQD0E
https://sourceforge.net/p/trousers/mailman/message/34257631/
I'm also not sure about whether or not to trust the Chinese no-name
manufacturer... Maybe the TPM just reports everything as valid? At least
sounds like a simple implementation that doesn't get noticed 99% of the
time.
But if you find anything I'd be interested.
In total I'd though say that physical security is a _much better_
counter-measure than TPM usage for AEM scenarios (as long as you're
using Qubes and not some monolithic OS). So what about a locked case for
your laptop, maybe even with some noisy alarm if not opened correctly? ;-)
Or just always carry it with you...
Also helps against hardware attacks. Okay they can still knock you out,
but if it has gone that far, you'll have some different problems anyway.
Swâmi Petaramesh
Dec 1, 2016, 10:34:16 AM12/1/16
to qubes-users, rust...@openmailbox.org
Hi Rusty Bird, and thanks for your help,
Please see below.
>
> Is the SINIT module working? Run the "find" command from step 2b of
> /usr/share/doc/anti-evil-maid/README, but look at the lines for PCRs
> 17, 18, and 19 instead: They should have very random-looking values.
Uh... Lines 17-19 are all FF
On my system :
PCR-00 to 07 look random
PCR-08 to 12 are all 00
PCR-13 looks random
PCR-14 to 16 are all 00
PCR-17 to 22 are all FF
PCR-23 are all 00
So the problem seems to be there... But I don't know what to do with
this (I know almost nothing about TPM...)
> Is AEM sealing to the right registers? If you run the command
> "source /etc/anti-evil-maid.conf; echo $SEAL" in dom0, it should print
> "--pcr 13 --pcr 17 --pcr 18 --pcr 19".
This is OK.
> Did the unsealed image somehow end up in the wrong place? The file
> /usr/share/plymouth/themes/qubes-dark/antievilmaid_secret.png should
> *not* exist in dom0.
This is OK as well.
Thanks again for your help.
ॐ
Please see below.
>
> Is the SINIT module working? Run the "find" command from step 2b of
> /usr/share/doc/anti-evil-maid/README, but look at the lines for PCRs
> 17, 18, and 19 instead: They should have very random-looking values.
On my system :
PCR-00 to 07 look random
PCR-08 to 12 are all 00
PCR-13 looks random
PCR-14 to 16 are all 00
PCR-17 to 22 are all FF
PCR-23 are all 00
So the problem seems to be there... But I don't know what to do with
this (I know almost nothing about TPM...)
> Is AEM sealing to the right registers? If you run the command
> "source /etc/anti-evil-maid.conf; echo $SEAL" in dom0, it should print
> "--pcr 13 --pcr 17 --pcr 18 --pcr 19".
> Did the unsealed image somehow end up in the wrong place? The file
> /usr/share/plymouth/themes/qubes-dark/antievilmaid_secret.png should
> *not* exist in dom0.
Thanks again for your help.
ॐ
Rusty Bird
Dec 1, 2016, 2:22:26 PM12/1/16
to Swâmi Petaramesh, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Swâmi Petaramesh:
Hash: SHA512
Swâmi Petaramesh:
> Hi Rusty Bird, and thanks for your help,
>
>
> > Is the SINIT module working? Run the "find" command from step 2b of
> > /usr/share/doc/anti-evil-maid/README, but look at the lines for PCRs
> > 17, 18, and 19 instead: They should have very random-looking values.
>
> Uh... Lines 17-19 are all FF
Well, the good news is we've definitely narrowed down the problem. :)
> > /usr/share/doc/anti-evil-maid/README, but look at the lines for PCRs
> > 17, 18, and 19 instead: They should have very random-looking values.
>
> Uh... Lines 17-19 are all FF
Are you sure you've successfully copied the *right* SINIT blob for your
system to /boot? (Intel's download page is... not great.)
Does "ls /boot/*SINIT*.BIN" - note the uppercase for both the name and
the extension) show exactly one file?
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJYQHjGXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfqDkP/ivq6Kwwug1Eo+Isr9nnoYDz
Yj530MuWQcsUqZ5L6Dgi62G22v/zlppuVHWG7QNVh+WC4HjGMAzHcqy1Wj16Wb75
QIgKkMTbNiLK/KBpKHLXBThbAd/yjawzOQZNLZLfyFpAby/po7x+EBOW/JkWbCVS
7NBat08DJ8MfRF2e+VWsTSRptSkrKpIX2RikVH4jPSFGjTWDpZMEcekVOK4HL1x0
RkSKqG5LZxIcxtfQ8nTfeV+n/UEDERudQgde66gtQNPEv0N93oxGjxsAudo+X3rA
CLzNw+ewFGxMTeETuRIy6r5AV4XHukNaSBCujizHUSQAIKDx41Ndong+wvKDxbGx
77jbnKoXCtBkHijylnvFlI5udI6xA1vfFLJxMWoXkV7zU5K1AyZkKaukPuZYcBVC
HK6mYZSZ3p5csrChh7O1oVB6J2g0Q+LmoKRPxeahvi6N8NxI0BIbjC4iE6ECS2oP
K0HmlFlP9rWwT5aCz8Wu0BHr5v8cQuP7QZEBu5GHwTvjwvmAUxVBB4fRAITBcfZe
3MndhZ6QTCgGKgbA7/19fswh5FBt/Pgf/P8oWQm/CqQTqbyi7awOrBIUbEX+7E2l
sIna69VuaNtadE1Mz3MOU7GpqOocQu4pyfvMRW6G7nSlbzM5qdUE3voXWn1TSKeC
SNL0Sfas1yJuuyYC7wYu
=VRW4
-----END PGP SIGNATURE-----
Swâmi Petaramesh
Dec 4, 2016, 5:47:37 AM12/4/16
to qubes-users, rust...@openmailbox.org
Hi Rusty, Hi all,
Le 01/12/2016 à 20:23, Rusty Bird a écrit :
>> Uh... Lines 17-19 are all FF
> Well, the good news is we've definitely narrowed down the problem. :)
>
> Are you sure you've successfully copied the *right* SINIT blob for your
> system to /boot? (Intel's download page is... not great.)
Stupid me. I had first thought that if I could see the PCR-* lines and
initialize TPM, it meant that my kernel managed the TPM by itself and
didn't need this file... So I had't installed it at all.
I now have downloaded 3rd_gen_i5_i7_SINIT_67.BIN from Intel, installed
it per instructions, completely redone everything (including resetting
the TPM chip in BIOS, uninstalling and reinstallind the AEM RPM...
But still, lines 17-19 remain all FF :-(
> Does "ls /boot/*SINIT*.BIN" - note the uppercase for both the name and
> the extension) show exactly one file?
Yes, it does.
Le 01/12/2016 à 20:23, Rusty Bird a écrit :
>> Uh... Lines 17-19 are all FF
> Well, the good news is we've definitely narrowed down the problem. :)
>
> Are you sure you've successfully copied the *right* SINIT blob for your
> system to /boot? (Intel's download page is... not great.)
initialize TPM, it meant that my kernel managed the TPM by itself and
didn't need this file... So I had't installed it at all.
I now have downloaded 3rd_gen_i5_i7_SINIT_67.BIN from Intel, installed
it per instructions, completely redone everything (including resetting
the TPM chip in BIOS, uninstalling and reinstallind the AEM RPM...
But still, lines 17-19 remain all FF :-(
> Does "ls /boot/*SINIT*.BIN" - note the uppercase for both the name and
> the extension) show exactly one file?
Rusty Bird
Dec 4, 2016, 9:55:25 AM12/4/16
to Swâmi Petaramesh, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Swâmi Petaramesh:
Hash: SHA512
Swâmi Petaramesh:
> I now have downloaded 3rd_gen_i5_i7_SINIT_67.BIN from Intel, installed
> it per instructions, completely redone everything (including resetting
> the TPM chip in BIOS, uninstalling and reinstallind the AEM RPM...
>
> But still, lines 17-19 remain all FF :-(
Maybe your system still doesn't boot into AEM mode for some reason.
> it per instructions, completely redone everything (including resetting
> the TPM chip in BIOS, uninstalling and reinstallind the AEM RPM...
>
> But still, lines 17-19 remain all FF :-(
Does /proc/cmdline in dom0 contain "rd.antievilmaid" at the end? If not:
In the GRUB boot menu, do you choose the entry "AEM Qubes, with Xen
hypervisor"? If there is no such entry, you may have to rerun the
"anti-evil-maid-install" command.
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJYRC4zXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfFM8P/Ayi5lu5Vj/mn8IyAJTjj9QC
o5GKkjKRH+3uF0p6INj7imFUH6B7lU0GAs5b//E/9lImvYZ6BhLgCU1MNElvohWO
uvJ1imhUBDziRsyzcCxFuzaMDwcdzVJ/u+JgKwkkn4v81rTriulr547kfHxan0Vt
dZYX6cdr8psJfuWpfFhUGgWBMMYHbw9rTFsBMglNdA/Qpknv0qFQt3ss8oaWjlA5
VU0yZYKCp0oVgrSZA2SUoo7QA6mCZ18lQFTQFEel+Kj81uZLi74rgn98ZGRtCEsy
DlBi3QsIk1pXJiwRmzBrN/FOCDdcYmqz3GOHyP1jPII5f/YHpaS2VsxyEq4LnctV
VTPMvKxs/yNfIDs4QaBMVJIs36ns/mZPvYjrJ/Br6L0lsRDPpEvNtYoz6Nveg3ea
gYsMm2Jhj5O8XlynAm1KKV+uLI/uIawgNzFvjLoIWPRQTpcTQDjmll8T0mBHKPcG
CVYiirNvHLeBhQF32CFLNXQQmvNYs377f8k/m1x8rtuv+af5EVFdoE0eY/HaF9uj
5+PFE4ruBpgB5rocl3pY35NHjn6W2ciOBYXjjvfE06WiB+0ALHz4m+XcJ0j9m7Xy
qrtVH1BGcr/tz15VOOGJc9ZfEqK5W8mQMLXNQfSmA89adEfjSwR8r8ecRCUfeJwg
RL3FpCGFtnu8RLFz/ha+
=ldBa
-----END PGP SIGNATURE-----
Swâmi Petaramesh
Dec 4, 2016, 10:05:44 AM12/4/16
to qubes-users, rust...@openmailbox.org
Hi again,
On 12/04/2016 03:54 PM, Rusty Bird wrote:
>
> Maybe your system still doesn't boot into AEM mode for some reason.
>
> Does /proc/cmdline in dom0 contain "rd.antievilmaid" at the end? If not:
Yes, it does.
I also get correctly prompted for the TPM key, AND I can also see my
secret image displayed while I am prompted for the HD password.
So I for sure boot in AEM mode, and it "looks like" it's working, but if
I upgrade the kernel (there was a kernel upgrade today), AEM doesn't
notice and still happily displays my secret image :-(
Thanks again for your help.
Kind regards.
On 12/04/2016 03:54 PM, Rusty Bird wrote:
>
> Maybe your system still doesn't boot into AEM mode for some reason.
>
> Does /proc/cmdline in dom0 contain "rd.antievilmaid" at the end? If not:
> In the GRUB boot menu, do you choose the entry "AEM Qubes, with Xen
> hypervisor"? If there is no such entry, you may have to rerun the
> "anti-evil-maid-install" command.
It also does.
> hypervisor"? If there is no such entry, you may have to rerun the
> "anti-evil-maid-install" command.
I also get correctly prompted for the TPM key, AND I can also see my
secret image displayed while I am prompted for the HD password.
So I for sure boot in AEM mode, and it "looks like" it's working, but if
I upgrade the kernel (there was a kernel upgrade today), AEM doesn't
notice and still happily displays my secret image :-(
Thanks again for your help.
Rusty Bird
Dec 4, 2016, 10:10:28 AM12/4/16
to Swâmi Petaramesh, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Rusty Bird:
Hash: SHA512
> Does /proc/cmdline in dom0 contain "rd.antievilmaid" at the end? If not:
>
> In the GRUB boot menu, do you choose the entry "AEM Qubes, with Xen
> hypervisor"? If there is no such entry, you may have to rerun the
> "anti-evil-maid-install" command.
Otherwise, the only thing I can think of would be to try tboot 1.9.4:
>
> In the GRUB boot menu, do you choose the entry "AEM Qubes, with Xen
> hypervisor"? If there is no such entry, you may have to rerun the
> "anti-evil-maid-install" command.
https://github.com/QubesOS/qubes-issues/issues/2155#issuecomment-263139022
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJYRDHAXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfFFUP/3Yv0GYD++Fq0UFaEHEttvBP
u7vxv70SpoMPo5SnxN2PLFJCVvbM4/XO+ALmdW8KtgjFUiJ1xr7dTY81Kcbaj0mj
3zPjve/AiUhTP4ye0KqpJnqxDACJPe6EkMlCAY9xESdtIxcK6P6lKaTHKr0XfBLV
3vddZ3a7SqyWOOE8NUqzjwan8uc+cAQ13+aS2jZa1Rp8AB7/GJ7hRu2thPGtF6y3
Z04w9MWAPuqNUV98mPEAK/oxSE1N8gHQsTA/0vUJMVm5j+84iRbvmJI6VsQOLtUq
2eZgcrq+3qxYv2JU6K33eu6XcVoLVp9sNUduzkik+GCZO9EVL2dwKsXCil4MaXOy
H4KERaMiDvuOUecvLUtPdTH/ZlEYmEqBqamOn4/r3XOZxjHhqF9bLZyJT6+M2pgz
Iz+qzFf/8RDxStEXCcWP/0RE3EutS1p3PpqzavAWNzN9PxRctlFlcUwqZJE66MrN
84eB355zvEQEjiB+1YIAIknDMp/I4NG0kWneyj/NEd5Pk+RBJl4CaQy0MfGNyLKl
MiTEAR/DEDILJgPb4pC/ArlCBEhzn0h7iqITQnxv5YwRr/27A3QC3RQ1BRBjgV0q
80Elskoe16nkd08ZCBC1k5a0BxE9UJd5pculKH05alGjl6U2W+uhq2I+mimhRSF8
vwWQ9nQf67H6H05dcaau
=XbOw
-----END PGP SIGNATURE-----
Marek Marczykowski-Górecki
Jan 12, 2017, 7:42:51 AM1/12/17
to qubes-users, rust...@openmailbox.org, Matt McCutchen, Swâmi Petaramesh
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Thu, Dec 01, 2016 at 04:32:50PM +0100, Swâmi Petaramesh wrote:
> Hi Rusty Bird, and thanks for your help,
>
> Please see below.
>
> >
> > Is the SINIT module working? Run the "find" command from step 2b of
> > /usr/share/doc/anti-evil-maid/README, but look at the lines for PCRs
> > 17, 18, and 19 instead: They should have very random-looking values.
>
> Uh... Lines 17-19 are all FF
>
> On my system :
>
> PCR-00 to 07 look random
> PCR-08 to 12 are all 00
> PCR-13 looks random
> PCR-14 to 16 are all 00
> PCR-17 to 22 are all FF
> PCR-23 are all 00
>
> So the problem seems to be there... But I don't know what to do with
> this (I know almost nothing about TPM...)
Rusty, Matt rightly just pointed out to Qubes Security Team that the
current behaviour of AEM could be misleading. AEM should refuse to work
if TXT isn't really working - otherwise it's easy to not notice it and
have false sense of security.
- --
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
iQEcBAEBCAAGBQJYd3nBAAoJENuP0xzK19csxfYH/AngaxY7yDmLXBc8sZufHjg4
lv3nM1otgcQmYxzvIyWDut0qbpLLhmqnQ4StntS/ajesdzFZnKghS0LyJmNjAG/9
hiyfNGYMEml738SCaNujCq2c75ZLi3SFELtPqk4TT4pSJ4rGXX39d2rcnQxs4pGy
xYpkUcWSnLQKQXnkWKphkzAx4IpsaVwtgntVpLYDJ2J0owp4BbtoyBFfDztvEICU
Hp0+r5wUtP8XuuQ6SB3+OqvOeymsgp6SRQln8LsLChQApxk1wC7XiNx3k6rN/nYa
wbo2kI0Plir7SSnYXCNmwyR3S3O45AVxQSMphDHUUw6bC0o+xk3Z6+K6WaAGObk=
=NzFB
-----END PGP SIGNATURE-----
Hash: SHA256
On Thu, Dec 01, 2016 at 04:32:50PM +0100, Swâmi Petaramesh wrote:
> Hi Rusty Bird, and thanks for your help,
>
> Please see below.
>
> >
> > Is the SINIT module working? Run the "find" command from step 2b of
> > /usr/share/doc/anti-evil-maid/README, but look at the lines for PCRs
> > 17, 18, and 19 instead: They should have very random-looking values.
>
> Uh... Lines 17-19 are all FF
>
> On my system :
>
> PCR-00 to 07 look random
> PCR-08 to 12 are all 00
> PCR-13 looks random
> PCR-14 to 16 are all 00
> PCR-17 to 22 are all FF
> PCR-23 are all 00
>
> So the problem seems to be there... But I don't know what to do with
> this (I know almost nothing about TPM...)
current behaviour of AEM could be misleading. AEM should refuse to work
if TXT isn't really working - otherwise it's easy to not notice it and
have false sense of security.
- --
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
iQEcBAEBCAAGBQJYd3nBAAoJENuP0xzK19csxfYH/AngaxY7yDmLXBc8sZufHjg4
lv3nM1otgcQmYxzvIyWDut0qbpLLhmqnQ4StntS/ajesdzFZnKghS0LyJmNjAG/9
hiyfNGYMEml738SCaNujCq2c75ZLi3SFELtPqk4TT4pSJ4rGXX39d2rcnQxs4pGy
xYpkUcWSnLQKQXnkWKphkzAx4IpsaVwtgntVpLYDJ2J0owp4BbtoyBFfDztvEICU
Hp0+r5wUtP8XuuQ6SB3+OqvOeymsgp6SRQln8LsLChQApxk1wC7XiNx3k6rN/nYa
wbo2kI0Plir7SSnYXCNmwyR3S3O45AVxQSMphDHUUw6bC0o+xk3Z6+K6WaAGObk=
=NzFB
-----END PGP SIGNATURE-----
Matt McCutchen
Jan 12, 2017, 9:51:50 AM1/12/17
to Marek Marczykowski-Górecki, qubes-users, rust...@openmailbox.org, Swâmi Petaramesh
On Thu, 2017-01-12 at 13:42 +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Dec 01, 2016 at 04:32:50PM +0100, Swâmi Petaramesh wrote:
> > Hi Rusty Bird, and thanks for your help,
> >
> > Please see below.
> >
> > >
> > > Is the SINIT module working? Run the "find" command from step 2b of
> > > /usr/share/doc/anti-evil-maid/README, but look at the lines for PCRs
> > > 17, 18, and 19 instead: They should have very random-looking values.
> >
> > Uh... Lines 17-19 are all FF
> >
> > On my system :
> >
> > > > PCR-00 to 07 look random
> > > > PCR-08 to 12 are all 00
> > > > PCR-13 looks random
> > > > PCR-14 to 16 are all 00
> > > > PCR-17 to 22 are all FF
> > > > PCR-23 are all 00
> >
> > So the problem seems to be there... But I don't know what to do with
> > this (I know almost nothing about TPM...)
>
> Rusty, Matt rightly just pointed out to Qubes Security Team that the
> current behaviour of AEM could be misleading. AEM should refuse to work
> if TXT isn't really working - otherwise it's easy to not notice it and
> have false sense of security.
Thanks marmarek for pointing me to the existing thread. My search was
> On Thu, Dec 01, 2016 at 04:32:50PM +0100, Swâmi Petaramesh wrote:
> > Hi Rusty Bird, and thanks for your help,
> >
> > Please see below.
> >
> > >
> > > Is the SINIT module working? Run the "find" command from step 2b of
> > > /usr/share/doc/anti-evil-maid/README, but look at the lines for PCRs
> > > 17, 18, and 19 instead: They should have very random-looking values.
> >
> > Uh... Lines 17-19 are all FF
> >
> > On my system :
> >
> > > > PCR-00 to 07 look random
> > > > PCR-08 to 12 are all 00
> > > > PCR-13 looks random
> > > > PCR-14 to 16 are all 00
> > > > PCR-17 to 22 are all FF
> > > > PCR-23 are all 00
> >
> > So the problem seems to be there... But I don't know what to do with
> > this (I know almost nothing about TPM...)
>
> Rusty, Matt rightly just pointed out to Qubes Security Team that the
> current behaviour of AEM could be misleading. AEM should refuse to work
> if TXT isn't really working - otherwise it's easy to not notice it and
> have false sense of security.
not good enough. :(
I filed https://github.com/QubesOS/qubes-issues/issues/2569 to help
make sure we don't forget about this.
Matt
Swâmi Petaramesh
Jan 12, 2017, 10:07:43 AM1/12/17
to Matt McCutchen, Marek Marczykowski-Górecki, qubes-users, rust...@openmailbox.org
Thanks for coming back on this.
I have personally uninstalled AEM from both of my HP systems as I
realized it wasn't actually working AND anyway gave me this false sense
of security - plus the fact that installing an SSD cache on one of the
machines broke it completely dead (AEM exiting to initramfs, complaining
that it found the root fs "unexpectedly unencrypted").
For the record, it is broken on :
- HP EliteBook 820 G1 (Intel 4th gen Core i5)
- HP Probook 6470B 5 (Intel 3rd gen Core i5)
...Both using the correct SINIT module as far as I can tell.
...Both showing the symptoms described above (PCR-17 to 22 staying
desperately FF)
Also, I understood (at least I think I understood...) from tboot
documentation (which I believe AEM uses) that it works only for systems
that have iommu, which is the case for my HP EliteBook 820 but
apparently not for my Probook 6470B (too bad I bought this machine with
the idea of using it in the future with Qubes 4.0, but it seems it won't
be compatible).
Currently AEM doesn't complain if iommu is unavailable. tboot README
advises to boot Xen with "iommu=required", but AEM seems not to set this
up this way...
Best regards.
Matt McCutchen
Jan 12, 2017, 10:38:23 AM1/12/17
to Swâmi Petaramesh, Marek Marczykowski-Górecki, qubes-users, rust...@openmailbox.org
To the original point of this thread (figuring out /why/ the measured
boot isn't working):
The way I found to do this is to configure tboot to log to the screen
by setting (for example) "logging=vga vga_delay=10" on the "multiboot
/tboot.gz" line in grub.cfg. The Qubes default setting is
"logging=memory,serial", but I don't have a serial console on hand and
I couldn't find an obvious way to retrieve the "logging=memory" data
from within Qubes. (The "txt-stat" tool doesn't show anything;
possibly it would work if I were booting Linux without Xen.)
The relevant part of the log for my Lenovo ThinkPad L430:
...
TBOOT: IA32_FEATURE_CONTROL_MSR: 00000005
TBOOT: CPU is SMX_capable
TBOOT: ERR: SENTER disabled by feature control MSR (5)
TBOOT: SMX not supported.
...
Matt
boot isn't working):
The way I found to do this is to configure tboot to log to the screen
by setting (for example) "logging=vga vga_delay=10" on the "multiboot
/tboot.gz" line in grub.cfg. The Qubes default setting is
"logging=memory,serial", but I don't have a serial console on hand and
I couldn't find an obvious way to retrieve the "logging=memory" data
from within Qubes. (The "txt-stat" tool doesn't show anything;
possibly it would work if I were booting Linux without Xen.)
The relevant part of the log for my Lenovo ThinkPad L430:
...
TBOOT: IA32_FEATURE_CONTROL_MSR: 00000005
TBOOT: CPU is SMX_capable
TBOOT: ERR: SENTER disabled by feature control MSR (5)
TBOOT: SMX not supported.
...
Matt
Rusty Bird
Jan 12, 2017, 1:02:19 PM1/12/17
to Marek Marczykowski-Górecki, qubes-users, Matt McCutchen, Swâmi Petaramesh
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Marek Marczykowski-Górecki:
https://github.com/QubesOS/qubes-issues/issues/2569#issuecomment-272235227
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJYd8SQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfU80P/i2VfKaxLVONuk+Btmfc3WfN
f+SrUZIPPzclrPpCb3k0SiEnYbkJBI+9Ece+jWRpyUJNVFVayy0RJ3lW+JS9FNOk
dorBfJvJ4IoE7CYulsW/2qvPbmHf6FqzSoAyZ29KKWa1X1lR26kUMA/3ZmTJTdRy
c3qWXjnbIhfXoutqfSs2Nb1sEI8M46hsTUR8ESiIjVYnjBdRmO6jogiGBiy7zQ4w
pmH3djALJVrj4lpAOm5AEgkHmkoYcxlVOkTJKEqCIm7kdLuQiiLshJWU5HkjVFOV
cY6sUgyjJAqnvuGNbVrpKaP96RpE1yKtd00777DnbkWsTYlDjtSEiwC3KhEzN/So
Ga82zeHHicC1j76v0UbOlaFtdIo3rZk1mvzhoL3mVT3oWZkN+IbznwtFNnwbqJip
798+Ki+283ZxFz99Cj9y7nq/qTGGgP2qZ8imTBtt9LaOipgkgqdCzom85VqHFYTA
2ZivgY3fFLoJEys7nie5XPZcMWQ1pD5f6qp81aVNpU6L0X2iFTuCOS9DH76jd0BJ
HOq4lSfQfbZHco9/U87REipB5EWmoi5UN+NPqkemSyTkDXum4OMa7bEPvzwQbyUm
xyCzIO6/u3GT3mwJQ/kNa/+/ya1+CJlG8obd239AEk/6jIdkCwbAJ7HeEaw0KqGq
MlnIDTcfDmiL94iZRsIN
=SA4W
-----END PGP SIGNATURE-----
Hash: SHA512
Marek Marczykowski-Górecki:
> Rusty, Matt rightly just pointed out to Qubes Security Team that the
> current behaviour of AEM could be misleading. AEM should refuse to work
> if TXT isn't really working - otherwise it's easy to not notice it and
> have false sense of security.
Thanks for CCing, I agree:
> current behaviour of AEM could be misleading. AEM should refuse to work
> if TXT isn't really working - otherwise it's easy to not notice it and
> have false sense of security.
https://github.com/QubesOS/qubes-issues/issues/2569#issuecomment-272235227
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJYd8SQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfU80P/i2VfKaxLVONuk+Btmfc3WfN
f+SrUZIPPzclrPpCb3k0SiEnYbkJBI+9Ece+jWRpyUJNVFVayy0RJ3lW+JS9FNOk
dorBfJvJ4IoE7CYulsW/2qvPbmHf6FqzSoAyZ29KKWa1X1lR26kUMA/3ZmTJTdRy
c3qWXjnbIhfXoutqfSs2Nb1sEI8M46hsTUR8ESiIjVYnjBdRmO6jogiGBiy7zQ4w
pmH3djALJVrj4lpAOm5AEgkHmkoYcxlVOkTJKEqCIm7kdLuQiiLshJWU5HkjVFOV
cY6sUgyjJAqnvuGNbVrpKaP96RpE1yKtd00777DnbkWsTYlDjtSEiwC3KhEzN/So
Ga82zeHHicC1j76v0UbOlaFtdIo3rZk1mvzhoL3mVT3oWZkN+IbznwtFNnwbqJip
798+Ki+283ZxFz99Cj9y7nq/qTGGgP2qZ8imTBtt9LaOipgkgqdCzom85VqHFYTA
2ZivgY3fFLoJEys7nie5XPZcMWQ1pD5f6qp81aVNpU6L0X2iFTuCOS9DH76jd0BJ
HOq4lSfQfbZHco9/U87REipB5EWmoi5UN+NPqkemSyTkDXum4OMa7bEPvzwQbyUm
xyCzIO6/u3GT3mwJQ/kNa/+/ya1+CJlG8obd239AEk/6jIdkCwbAJ7HeEaw0KqGq
MlnIDTcfDmiL94iZRsIN
=SA4W
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages