Bug Reports: AEM in Qubes

2858 views
Skip to first unread message

David Hobach

unread,
Feb 24, 2014, 12:26:14 PM2/24/14
to qubes...@googlegroups.com
Dear developers,

Let me first explain my setup:
Dual boot (latest Qubes with all patches + Windows for gaming) desktop
machine --> AEM seemed a reasonable choice for me. As it is a desktop
machine, I didn't want to go for the USB stick solution, but rather use
another password to unseal the TPM. AEM was meant to be installed to the
/boot partition.

During the AEM installation I discovered the following two bugs:

1. The AEM installer doesn't support a direct installation to /boot as
needed for my setup (and as indicated by the README). After reading
through the installer script I noticed I didn't want to re-format my
/boot partition... I managed to get around this problem though.

2. The tpm_unsealdata during boot doesn't work if a password is
specified for TPM operations.
Reason: It doesn't have access to stdin to read the password as
a) The service is not configured to have access to stdin (explicitly set
to "null" in the config).
b) Reading from stdin during the boot process seems to be a lot
different than reading from it during normal OS runtime. stdin seems to
be managed by plymouth and/or systemd depending on whether plymouth is
used or not. Therefore commands reading from stdin during the boot
process are usually wrapped inside other functions to accomplish the
plymouth/systemd hassle. This is e.g. done that way for the cryptsetup
operations.

I fixed 2. a) + b) for my setup (I didn't test others). You can find the
patched files attached.

My kernel parameters fyi:
GRUB_CMDLINE_LINUX="rd.md=0 rd.dm=0
rd.luks.uuid=luks-184b810f-55df-4198-ae45-07843a9699b4 $([ -x
/usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param ||
vconsole.keymap=de rd.lvm.lv=qubes_dom0/root rd.antievilmaid.asksrkpass
rd.antievilmaid.dontforcestickremoval plymouth.enable=0"

Thanks for your good work at Qubes!

Kind Regards
David
anti-evil-maid.service
anti-evil-maid.sh

Marek Marczykowski-Górecki

unread,
Feb 28, 2014, 8:00:41 AM2/28/14
to David Hobach, qubes...@googlegroups.com
On 24.02.2014 18:26, David Hobach wrote:
> Dear developers,
>
> Let me first explain my setup:
> Dual boot (latest Qubes with all patches + Windows for gaming) desktop
> machine --> AEM seemed a reasonable choice for me. As it is a desktop
> machine, I didn't want to go for the USB stick solution, but rather use
> another password to unseal the TPM. AEM was meant to be installed to the
> /boot partition.
>
> During the AEM installation I discovered the following two bugs:
>
> 1. The AEM installer doesn't support a direct installation to /boot as
> needed for my setup (and as indicated by the README). After reading
> through the installer script I noticed I didn't want to re-format my
> /boot partition... I managed to get around this problem though.

The whole idea of AEM is that it isn't accessible to the (another) running
system, especially in dual-boot setup. Otherwise your other system can conduct
multistage EM attack.

> 2. The tpm_unsealdata during boot doesn't work if a password is
> specified for TPM operations.
> Reason: It doesn't have access to stdin to read the password as
> a) The service is not configured to have access to stdin (explicitly set
> to "null" in the config).
> b) Reading from stdin during the boot process seems to be a lot
> different than reading from it during normal OS runtime. stdin seems to
> be managed by plymouth and/or systemd depending on whether plymouth is
> used or not. Therefore commands reading from stdin during the boot
> process are usually wrapped inside other functions to accomplish the
> plymouth/systemd hassle. This is e.g. done that way for the cryptsetup
> operations.
>
> I fixed 2. a) + b) for my setup (I didn't test others). You can find the
> patched files attached.

Thanks, I'll look at it and most likely apply.

> My kernel parameters fyi:
> GRUB_CMDLINE_LINUX="rd.md=0 rd.dm=0
> rd.luks.uuid=luks-184b810f-55df-4198-ae45-07843a9699b4 $([ -x
> /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param ||
> vconsole.keymap=de rd.lvm.lv=qubes_dom0/root rd.antievilmaid.asksrkpass
> rd.antievilmaid.dontforcestickremoval plymouth.enable=0"
>
> Thanks for your good work at Qubes!
>
> Kind Regards
> David


--
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?

signature.asc

David Hobach

unread,
Feb 28, 2014, 12:40:00 PM2/28/14
to Marek Marczykowski-Górecki, qubes...@googlegroups.com
On 02/28/2014 02:00 PM, Marek Marczykowski-Górecki wrote:
> On 24.02.2014 18:26, David Hobach wrote:
>> Dear developers,
>>
>> Let me first explain my setup:
>> Dual boot (latest Qubes with all patches + Windows for gaming) desktop
>> machine --> AEM seemed a reasonable choice for me. As it is a desktop
>> machine, I didn't want to go for the USB stick solution, but rather use
>> another password to unseal the TPM. AEM was meant to be installed to the
>> /boot partition.
>>
>> During the AEM installation I discovered the following two bugs:
>>
>> 1. The AEM installer doesn't support a direct installation to /boot as
>> needed for my setup (and as indicated by the README). After reading
>> through the installer script I noticed I didn't want to re-format my
>> /boot partition... I managed to get around this problem though.
>
> The whole idea of AEM is that it isn't accessible to the (another) running
> system, especially in dual-boot setup. Otherwise your other system can conduct
> multistage EM attack.

Marek, can you please explain this a little bit more (i.e. multistage EM
attack)?

According to my understanding I'd notice changes to the BIOS and /boot
due to the AEM setup. Now if the attacker goes after the SRK password
with an EM attack, my secret phrase wouldn't display anymore. He'd get
the SRK password, but ideally I would throw away my mainboard afterwards
and certainly wouldn't enter my disk encryption password. In particular
he cannot seal the TPM again with my phrase as he doesn't know the phrase.
Of course, without SRK password he can simply unseal from within
Windows, change my boot process, seal again and launch an EM attack to
get the password for the encrypted Qubes drive.

In practice however I already noticed that changes to the grub.cfg
didn't make my secret phrase not being displayed for some reason...

Kind Regards
David

Marek Marczykowski-Górecki

unread,
Feb 28, 2014, 1:26:26 PM2/28/14
to David Hobach, qubes...@googlegroups.com
On 28.02.2014 18:40, David Hobach wrote:
> On 02/28/2014 02:00 PM, Marek Marczykowski-Górecki wrote:
>> On 24.02.2014 18:26, David Hobach wrote:
>>> Dear developers,
>>>
>>> Let me first explain my setup:
>>> Dual boot (latest Qubes with all patches + Windows for gaming) desktop
>>> machine --> AEM seemed a reasonable choice for me. As it is a desktop
>>> machine, I didn't want to go for the USB stick solution, but rather use
>>> another password to unseal the TPM. AEM was meant to be installed to the
>>> /boot partition.
>>>
>>> During the AEM installation I discovered the following two bugs:
>>>
>>> 1. The AEM installer doesn't support a direct installation to /boot as
>>> needed for my setup (and as indicated by the README). After reading
>>> through the installer script I noticed I didn't want to re-format my
>>> /boot partition... I managed to get around this problem though.
>>
>> The whole idea of AEM is that it isn't accessible to the (another) running
>> system, especially in dual-boot setup. Otherwise your other system can conduct
>> multistage EM attack.
>
> Marek, can you please explain this a little bit more (i.e. multistage EM attack)?
>
> According to my understanding I'd notice changes to the BIOS and /boot due to
> the AEM setup. Now if the attacker goes after the SRK password with an EM
> attack, my secret phrase wouldn't display anymore.

At this point the attacker can store SRK password somewhere, restore original
/boot state and show you some random innocent error, or simply reset/poweroff
machine with hope that you will not suspect anything. But ok, this is much
easier to spot.

> He'd get the SRK password,
> but ideally I would throw away my mainboard afterwards and certainly wouldn't
> enter my disk encryption password. In particular he cannot seal the TPM again
> with my phrase as he doesn't know the phrase.
> Of course, without SRK password he can simply unseal from within Windows,
> change my boot process, seal again and launch an EM attack to get the password
> for the encrypted Qubes drive.
>
> In practice however I already noticed that changes to the grub.cfg didn't make
> my secret phrase not being displayed for some reason...

I don't remember details, perhaps only kernel cmdline (along with kernel
binary and initrd) is used, not the whole grub.cfg?
signature.asc

David Hobach

unread,
Mar 1, 2014, 6:15:29 AM3/1/14
to Marek Marczykowski-Górecki, qubes...@googlegroups.com
Good point Marek, thanks!

So in the end it's technically possible to detect the changes, but the
human factor is likely to make everything fail again anyway with a
dual-boot setup.

For a single-boot setup in contrast it would be harder for the attacker
to be able to accomplish the unseal -> read phrase + change boot process
-> seal again process using the attack mentioned above as he cannot
execute code without being detected (boot process integrity is checked,
Qubes encrypted), i.e. the maid would have to physically exist (no
malware) and sneak in at least once more (1st time: install EM for SRK,
which in the end removes code from /boot + reboots; 2nd time: retrieve
SRK, unseal etc., install EM for encrypted HD; 3rd time: retrieve
encrypted HD password).

>> He'd get the SRK password,
>> but ideally I would throw away my mainboard afterwards and certainly wouldn't
>> enter my disk encryption password. In particular he cannot seal the TPM again
>> with my phrase as he doesn't know the phrase.
>> Of course, without SRK password he can simply unseal from within Windows,
>> change my boot process, seal again and launch an EM attack to get the password
>> for the encrypted Qubes drive.
>>
>> In practice however I already noticed that changes to the grub.cfg didn't make
>> my secret phrase not being displayed for some reason...
>
> I don't remember details, perhaps only kernel cmdline (along with kernel
> binary and initrd) is used, not the whole grub.cfg?

This makes me think a USB stick with read-only switch for /boot might
even be better for my setup.

Marek Marczykowski-Górecki

unread,
Mar 1, 2014, 9:26:57 AM3/1/14
to David Hobach, qubes...@googlegroups.com
And be sure that you're booting from the stick, not from its copy on HD...
This is why its recommended to connect AEM stick only for booting and remove
it as soon as possible.
signature.asc

cprise

unread,
Mar 10, 2014, 12:42:20 PM3/10/14
to Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com
I am also having a problem with AEM. I used a custom SRK password and
right at the point in the boot process where I'd expect a password
prompt, the boot sequence just halts (about 1/10 the way on the boot
progress bar).

When building the AEM boot partition, for each kernel in the boot
options it prints "F: Failed to install module fpu".

David Hobach

unread,
Mar 10, 2014, 1:04:39 PM3/10/14
to cprise, qubes...@googlegroups.com
> I am also having a problem with AEM. I used a custom SRK password and
> right at the point in the boot process where I'd expect a password
> prompt, the boot sequence just halts (about 1/10 the way on the boot
> progress bar).

Are you using plymouth?
It didn't work with plymouth for me neither (that's why I submitted the
patch). Check what it says on the console (F1 I think) and try pressing
return, Ctrl+C or whatever to check if booting continues then.

> When building the AEM boot partition, for each kernel in the boot
> options it prints "F: Failed to install module fpu".

That's nothing to be concerned about if I remember correctly.

cprise

unread,
Mar 10, 2014, 9:38:15 PM3/10/14
to David Hobach, qubes...@googlegroups.com, Marek Marczykowski

On 03/10/14 13:04, David Hobach wrote:
>> I am also having a problem with AEM. I used a custom SRK password and
>> right at the point in the boot process where I'd expect a password
>> prompt, the boot sequence just halts (about 1/10 the way on the boot
>> progress bar).
>
> Are you using plymouth?
> It didn't work with plymouth for me neither (that's why I submitted
> the patch). Check what it says on the console (F1 I think) and try
> pressing return, Ctrl+C or whatever to check if booting continues then.

Thanks David. I suppose I am using plymouth, as I haven't changed
anything about the startup process except install AEM. However, I've
tried another AEM install using 'tpm_takeownership -y -z' for the
default password and ran into the same problem: The boot process halts
early.

I'll try your patches and suggestions, though I'm not sure where your
kernel parameter for plymouth would go; the assignment in your initial
message doesn't look like a grub config to me.

cprise

unread,
Mar 10, 2014, 10:55:04 PM3/10/14
to David Hobach, qubes...@googlegroups.com, Marek Marczykowski
OK, I've got AEM boot sort-of working with David's patches and plymouth
disabled (I just added the assignment to the 'module' lines in
grub.conf). I also turned off 'quiet'.

Problem is that its still hanging, and I believe its the same spot as
before. Only now I know that the spot is right after the passphrase is
printed. So I have to press Ctrl-C to continue boot sequence and get to
the LUKS prompt...

How come?

IIRC, the Trackpoint device is initialized right around this spot as
well. I'm concerned I may be messing up my boot sequence by interrupting
a program with Ctrl-C.

David Hobach

unread,
Mar 11, 2014, 1:08:25 PM3/11/14
to cprise, qubes...@googlegroups.com

On 03/11/14 03:55, cprise wrote:
> OK, I've got AEM boot sort-of working with David's patches and plymouth
> disabled (I just added the assignment to the 'module' lines in
> grub.conf). I also turned off 'quiet'.
>
> Problem is that its still hanging, and I believe its the same spot as
> before. Only now I know that the spot is right after the passphrase is
> printed. So I have to press Ctrl-C to continue boot sequence and get to
> the LUKS prompt...
>
> How come?

Did you apply the dracut patches which I attached to the initial mail
and did you run dracut -f to update your initramfs afterwards?
Sounded like you just edited /etc/default/grub.

Are you talking about the TPM passphrase prompt or about the LUKS one?

> IIRC, the Trackpoint device is initialized right around this spot as
> well. I'm concerned I may be messing up my boot sequence by interrupting
> a program with Ctrl-C.

If it's the tpm unseal prompt, this won't harm anything. It'll not
authenticate your machine to you though (i.e. it makes AEM + TPM useless).

cprise

unread,
Mar 11, 2014, 3:03:13 PM3/11/14
to David Hobach, qubes...@googlegroups.com

On 03/11/14 13:08, David Hobach wrote:
>
> On 03/11/14 03:55, cprise wrote:
>> OK, I've got AEM boot sort-of working with David's patches and plymouth
>> disabled (I just added the assignment to the 'module' lines in
>> grub.conf). I also turned off 'quiet'.
>>
>> Problem is that its still hanging, and I believe its the same spot as
>> before. Only now I know that the spot is right after the passphrase is
>> printed. So I have to press Ctrl-C to continue boot sequence and get to
>> the LUKS prompt...
>>
>> How come?
>
> Did you apply the dracut patches which I attached to the initial mail
> and did you run dracut -f to update your initramfs afterwards?
> Sounded like you just edited /etc/default/grub.
I replaced /usr/lib/dracut/modules.d/90anti-evil-maid/anti-evil-maid.sh
and /usr/lib/systemd/system/anti-evil-maid.service before re-running the
antievilmaid-install program. I'll try running 'dracut -f', though I
thought antievilmaid-install would have taken care of that.
>
> Are you talking about the TPM passphrase prompt or about the LUKS one?
The TPM passphrase. It seems to be unsealing and printing fine, and it
states that its using the default SRK password.

>
>> IIRC, the Trackpoint device is initialized right around this spot as
>> well. I'm concerned I may be messing up my boot sequence by interrupting
>> a program with Ctrl-C.
>
> If it's the tpm unseal prompt, this won't harm anything. It'll not
> authenticate your machine to you though (i.e. it makes AEM + TPM
> useless).
>
I don't see any sign of a prompt. The stoppage comes after the TPM
passphrase is printed and before the LUKS prompt.

Olivier Médoc

unread,
Mar 12, 2014, 3:32:16 AM3/12/14
to qubes...@googlegroups.com
The AEM script also waits for you to remove the USB disk, but plymouth
is so buggy that apparently nobody knowns how to print a message on
plymouth GUI mode.

That's also one of the reason why it shouldn't work if installed on the hdd.

Remove your USB key to see if it continue on.

I'll perform some additional tests with AEM to see if it still works on
some conditions, but it is hard to see the things you changes in the AEM
scripts. I'll have to make a diff on the original files.

Olivier Médoc

unread,
Mar 12, 2014, 3:34:50 AM3/12/14
to qubes...@googlegroups.com
On 03/11/14 20:03, cprise wrote:
>
In fact if you installed it on disk instead on usb, you should also add
the following to your kernel command line:
rd.antievilmaid.dontforcestickremoval

cprise

unread,
Mar 12, 2014, 9:37:49 AM3/12/14
to Olivier Médoc, qubes...@googlegroups.com, David Hobach
I've been using a stick, although the unpatched version of AEM never
printed a message about removing the stick (however, most of that time I
was looking at the plymouth screen not the console). The AEM
instructions should mention the need to switch to the console screen and
to remove the stick.

Now I have AEM working, but only with kernel 3.11.10. I need 3.7.4 to
avoid sudden system resets; Qubes is unstable without it. But booting
with AEM and 3.7.4 together, the system is unable to start any VMs and
says there is not enough memory. The free command shows 3.8 instead of
the normal 7.8 GB of total RAM.

I did generate the AEM stick while running 3.11.10... maybe that is the
difference?

Marek Marczykowski-Górecki

unread,
Mar 12, 2014, 10:13:59 AM3/12/14
to Olivier Médoc, qubes...@googlegroups.com
Indeed there is a problem with plymouth theme, I'm currently working on it.

>
> That's also one of the reason why it shouldn't work if installed on the hdd.
>
> Remove your USB key to see if it continue on.
>
> I'll perform some additional tests with AEM to see if it still works on some
> conditions, but it is hard to see the things you changes in the AEM scripts.
> I'll have to make a diff on the original files.


signature.asc

cprise

unread,
Mar 12, 2014, 10:23:09 AM3/12/14
to Marek Marczykowski-Górecki, Olivier Médoc, qubes...@googlegroups.com
The AEM installer could automatically disable plymouth.

Olivier Médoc

unread,
Mar 12, 2014, 12:11:06 PM3/12/14
to qubes...@googlegroups.com
Good luck :). I found that Debugging plymouth problems is very time
consuming. Maybe there is an easy way to restart plymouth and run a
script after the host has started, but in my attempts, it was crashing
my host most of the time...

Marek Marczykowski-Górecki

unread,
Mar 12, 2014, 5:50:45 PM3/12/14
to Olivier Médoc, qubes...@googlegroups.com
Yes, it is possible to debug it without constantly restarting the system:
https://wiki.ubuntu.com/Plymouth
signature.asc

Marek Marczykowski-Górecki

unread,
Mar 13, 2014, 9:51:20 PM3/13/14
to David Hobach, qubes...@googlegroups.com
On 24.02.2014 18:26, David Hobach wrote:
I've applied the changes with some modification: send the secret to plymouth
to show it on the screen (regardless of current mode - text of graphical splash).

Also I've finally managed to fix plymouth theme to show the messages - there
was missing plugin for actual rendering messages. This increased initrd size
by 10MB (sic!), but IMHO not a big problem.
Soon new qubes-logos (containing the plymouth theme) will be available.
signature.asc

Olivier Médoc

unread,
Mar 14, 2014, 5:33:34 AM3/14/14
to qubes...@googlegroups.com
Nice ! I will try this as soon as the package is available.

Thanks a lot, I was waiting for such improvement (my debugging attempts
on the plymouth theme failed with headaches).

David Hobach

unread,
Mar 14, 2014, 12:03:35 PM3/14/14
to qubes...@googlegroups.com
On 03/14/14 02:51, Marek Marczykowski-Górecki wrote:
Thanks Marek!
I'll test it once I find some time.


cprise

unread,
Mar 21, 2014, 5:55:30 AM3/21/14
to Marek Marczykowski-Górecki, Olivier Médoc, qubes...@googlegroups.com
FYI, the latest current-testing version of AEM just sort of rolls over
and plays dead: Booting in AEM mode just results in progression directly
to the LUKS prompt, and there is no sign in the console of trying to
unseal the secret.

Marek Marczykowski-Górecki

unread,
Mar 21, 2014, 6:01:37 AM3/21/14
to cprise, Olivier Médoc, qubes...@googlegroups.com
On 21.03.2014 10:55, cprise wrote:
> FYI, the latest current-testing version of AEM just sort of rolls over and
> plays dead: Booting in AEM mode just results in progression directly to the
> LUKS prompt, and there is no sign in the console of trying to unseal the secret.

Are you sure you've choosed AEM grub entry? Note that entries order have
changed - now AEM is the first one.
signature.asc

cprise

unread,
Mar 21, 2014, 6:10:21 AM3/21/14
to Marek Marczykowski-Górecki, Olivier Médoc, qubes...@googlegroups.com

On 03/21/14 06:01, Marek Marczykowski-Górecki wrote:
> On 21.03.2014 10:55, cprise wrote:
>> FYI, the latest current-testing version of AEM just sort of rolls over and
>> plays dead: Booting in AEM mode just results in progression directly to the
>> LUKS prompt, and there is no sign in the console of trying to unseal the secret.
> Are you sure you've choosed AEM grub entry? Note that entries order have
> changed - now AEM is the first one.
>

Yes, positive. I noticed the change. I also checked the grub parameters
by pressing 'e', and the rd.antievilmaid was there along with the line
for the .BIN file.

Marek Marczykowski-Górecki

unread,
Mar 21, 2014, 8:33:06 AM3/21/14
to cprise, Olivier Médoc, qubes...@googlegroups.com
Did you updated also qubes-logos package? Also check if initramfs contains
actual AEM module (you can use lsinitrd for that).
signature.asc

cprise

unread,
Mar 21, 2014, 1:36:02 PM3/21/14
to Marek Marczykowski-Górecki, Olivier Médoc, qubes...@googlegroups.com

On 03/21/14 08:33, Marek Marczykowski-Górecki wrote:
On 21.03.2014 11:10, cprise wrote:
On 03/21/14 06:01, Marek Marczykowski-Górecki wrote:
On 21.03.2014 10:55, cprise wrote:
FYI, the latest current-testing version of AEM just sort of rolls over and
plays dead: Booting in AEM mode just results in progression directly to the
LUKS prompt, and there is no sign in the console of trying to unseal the
secret.
Are you sure you've choosed AEM grub entry? Note that entries order have
changed - now AEM is the first one.

Yes, positive. I noticed the change. I also checked the grub parameters by
pressing 'e', and the rd.antievilmaid was there along with the line for the
.BIN file.
Did you updated also qubes-logos package? Also check if initramfs contains
actual AEM module (you can use lsinitrd for that).


It says qubes-logos-1.1-1-noarch is the latest version, and there seem to be 1 dracut module and 2 files present:

# lsinitrd /mnt/aem/initramfs-3.11.10-1.pvops.qubes.x86_64.img |grep evil
anti-evil-maid
-rw-r--r--   1 root     root          397 Mar 17 19:15 etc/udev/rules.d/69-anti-evil-maid.rules
-rwxr-xr-x   1 root     root         3685 Mar 17 19:15 usr/sbin/anti-evil-maid


David Hobach

unread,
Mar 29, 2014, 2:39:09 PM3/29/14
to qubes...@googlegroups.com
>>> I fixed 2. a) + b) for my setup (I didn't test others). You can find the
>>> patched files attached.
>>
>> I've applied the changes with some modification: send the secret to
>> plymouth
>> to show it on the screen (regardless of current mode - text of
>> graphical splash).
>>
>> Also I've finally managed to fix plymouth theme to show the messages -
>> there
>> was missing plugin for actual rendering messages. This increased
>> initrd size
>> by 10MB (sic!), but IMHO not a big problem.
>> Soon new qubes-logos (containing the plymouth theme) will be available.
>
> Thanks Marek!
> I'll test it once I find some time.


I tested the current version available via dom0 upgrade, but
unfortunately it doesn't work for me so far.
I ran dracut -f and updated my grub2.

It neither works with nor without plymouth. In particular I don't see
any password prompt and no other sign of AEM being active neither.

If anyone has a clue on what it might be or how to debug this problem,
please contact me.

My journalctl -a is attached.

Kind Regards
David
journalctl.log

cprise

unread,
Mar 29, 2014, 4:28:52 PM3/29/14
to David Hobach, qubes...@googlegroups.com, Marek Marczykowski
I reported the same problem on March 21:

On 21.03.2014 10:55, cprise wrote:

> FYI, the latest current-testing version of AEM just sort of rolls over and
> plays dead: Booting in AEM mode just results in progression directly to the
> LUKS prompt, and there is no sign in the console of trying to unseal the
> secret.

I may look in the boot image to see if an execute bit is missing somewhere.

Marek Marczykowski-Górecki

unread,
Mar 29, 2014, 6:55:29 PM3/29/14
to David Hobach, qubes...@googlegroups.com, Joanna Rutkowska, cprise
Thanks for the log, I've found the problem (bad filename in module-setup.sh
script). New package available in unstable repo, you can install it with:
sudo qubes-dom0-update --enablerepo=qubes-dom0-r2b3-unstable
'anti-evil-maid-dracut'

@joanna Can you upload new AEM package also to current-testing repo?
signature.asc

cprise

unread,
Mar 30, 2014, 2:34:59 AM3/30/14
to Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com, Joanna Rutkowska
Thanks Marek, this does work.

There is another problem, however, with AEM: Booting with it causes
about half of my RAM to disappear according to /proc/meminfo. I get into
situations when I am not able to start an appvm even if the only other
things running are netvm, firewallvm and one appvm (using around 3G).
This happens with both 3.7.4 and 3.11.10 kernels.

Additionally, when I boot with AEM and kernel 3.7.4, VM Manager intially
says there isn't enough memory to start netvm or firewallvm... if I then
start a small un-networked appvm I can start the service vms afterward.

My total installed RAM is 8GB in 2 modules. Computer is Lenovo T430s.
Kernel parameters are the default set by the AEM installer.

David Hobach

unread,
Mar 30, 2014, 7:32:58 AM3/30/14
to qubes...@googlegroups.com
Yes, that puts AEM back to life. Thanks! :-)

However there's one bug left:
With plymouth disabled (i.e. plymouth.enable=0 in /etc/default/grub &
grub.cfg) those /bin/plymouth message calls in anti-evil-maid.sh won't
do anything at all, i.e. they won't show the secret passphrase for
example. Calls to info [message] in contrast work for me. Maybe there's
a function that works for both variants or maybe it's possible to write
such a function?

@cprise: I suppose you use plymouth?

> There is another problem, however, with AEM: Booting with it causes
> about half of my RAM to disappear according to /proc/meminfo. I get into
> situations when I am not able to start an appvm even if the only other
> things running are netvm, firewallvm and one appvm (using around 3G).
> This happens with both 3.7.4 and 3.11.10 kernels.
>
> Additionally, when I boot with AEM and kernel 3.7.4, VM Manager intially
> says there isn't enough memory to start netvm or firewallvm... if I then
> start a small un-networked appvm I can start the service vms afterward.
>
> My total installed RAM is 8GB in 2 modules. Computer is Lenovo T430s.
> Kernel parameters are the default set by the AEM installer.

@cprise: I cannot confirm that with 3.11.1-2 and 16 GB RAM. Sometimes
the memory balancer however seems to make stupid decisions (it just
allocated 4GB RAM for my e-mail domain?) or claims there's nothing left.
Most of the time I could fix that by setting fixed memory limits though
using the Qubes VM Manager. In particular that already happened before
using the new AEM fix.

cprise

unread,
Mar 30, 2014, 2:54:28 PM3/30/14
to David Hobach, qubes...@googlegroups.com, Marek Marczykowski
Yes.

>
>> There is another problem, however, with AEM: Booting with it causes
>> about half of my RAM to disappear according to /proc/meminfo. I get into
>> situations when I am not able to start an appvm even if the only other
>> things running are netvm, firewallvm and one appvm (using around 3G).
>> This happens with both 3.7.4 and 3.11.10 kernels.
>>
>> Additionally, when I boot with AEM and kernel 3.7.4, VM Manager intially
>> says there isn't enough memory to start netvm or firewallvm... if I then
>> start a small un-networked appvm I can start the service vms afterward.
>>
>> My total installed RAM is 8GB in 2 modules. Computer is Lenovo T430s.
>> Kernel parameters are the default set by the AEM installer.
>
> @cprise: I cannot confirm that with 3.11.1-2 and 16 GB RAM. Sometimes
> the memory balancer however seems to make stupid decisions (it just
> allocated 4GB RAM for my e-mail domain?) or claims there's nothing
> left. Most of the time I could fix that by setting fixed memory limits
> though using the Qubes VM Manager. In particular that already happened
> before using the new AEM fix.
>
Maybe if I disable plymouth my other 4GB will return? LOL.

In my case it does appear to be a bug in either tboot or rd.antievilmaid
(or just maybe a bug in the way plymouth reacts to them).

Marek Marczykowski-Górecki

unread,
Mar 30, 2014, 3:12:47 PM3/30/14
to cprise, David Hobach, qubes...@googlegroups.com
/proc/meminfo (in dom0) shows only dom0 memory. All detected memory can be
shown by 'xl info' (total_memory field).

> I get into situations when
> I am not able to start an appvm even if the only other things running are
> netvm, firewallvm and one appvm (using around 3G).

Qmemman distribute *all* the system memory to the running VMs (included in
memory balancing). By default firewallvm and netvm are excluded from it. So if
you have two domains participating in memory balancing (dom0 and the other
appvm) its pretty normal that the one appvm got 3G - about half of all the memory.

> This happens with both
> 3.7.4 and 3.11.10 kernels.
>
> Additionally, when I boot with AEM and kernel 3.7.4, VM Manager intially says
> there isn't enough memory to start netvm or firewallvm... if I then start a
> small un-networked appvm I can start the service vms afterward.

This is the only possible problem here. Is it reproducible, or happened just once?

> My total installed RAM is 8GB in 2 modules. Computer is Lenovo T430s. Kernel
> parameters are the default set by the AEM installer.
>


signature.asc

cprise

unread,
Mar 31, 2014, 12:11:59 AM3/31/14
to Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com
5092 for AEM boot
7884 for non-AEM boot

Both times booting from the USB stick.

>
>> I get into situations when
>> I am not able to start an appvm even if the only other things running are
>> netvm, firewallvm and one appvm (using around 3G).
> Qmemman distribute *all* the system memory to the running VMs (included in
> memory balancing). By default firewallvm and netvm are excluded from it. So if
> you have two domains participating in memory balancing (dom0 and the other
> appvm) its pretty normal that the one appvm got 3G - about half of all the memory.
>
>> This happens with both
>> 3.7.4 and 3.11.10 kernels.
>>
>> Additionally, when I boot with AEM and kernel 3.7.4, VM Manager intially says
>> there isn't enough memory to start netvm or firewallvm... if I then start a
>> small un-networked appvm I can start the service vms afterward.
> This is the only possible problem here. Is it reproducible, or happened just once?
Its 100% reproducible.

>> My total installed RAM is 8GB in 2 modules. Computer is Lenovo T430s. Kernel
>> parameters are the default set by the AEM installer.
>>

2 more AEM problems.....

1. The installer prompt asking for uppercase 'YES' to proceed will
proceed /anyway/ if you only press Enter. It does show an error in the
process:
line 57: [: !=: unary operator expected

2. The Grub menu for AEM advanced options will default to Xen 1.4.5
instead of 1.4.6 when selecting the top choice for the hypervisor. I
have to cursor down to specifically select Xen 1.4.6.



Joanna Rutkowska

unread,
Mar 31, 2014, 4:45:20 AM3/31/14
to cprise, Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com
On 03/30/14 08:34, cprise wrote:
>
If that's indeed what's happening the only component that might be
responsible for that would be tboot. I don't see this issue on my
system, but perhaps it's something system/processor dependent? I suggest
you consult this issue on tboot-devel mailing list.

joanna.

signature.asc

Joanna Rutkowska

unread,
Mar 31, 2014, 5:24:21 AM3/31/14
to Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com, cprise
Done.
j.

signature.asc

Olivier Médoc

unread,
Mar 31, 2014, 1:31:02 PM3/31/14
to qubes...@googlegroups.com
I also had this problem with kernel 3.7.4 in the past. I though it was
caused by a bug of this kernel version because it works correctly with
the 3.11 serie.

cprise

unread,
Mar 31, 2014, 3:19:46 PM3/31/14
to Olivier Médoc, qubes...@googlegroups.com, Joanna Rutkowska
Yes, the service vms start without error under 3.11.10 + tboot... but
total memory is still limited to 5092MB.

Also, per Joanna's suggestion, tboot does appear to be the cause of the
total memory problem. I created a copy of the grub entry I've been
booting from, but removed the rd.antievilmaid reference on the linux
module line: The problem persists.

Joanna Rutkowska

unread,
Mar 31, 2014, 7:13:34 PM3/31/14
to cprise, Olivier Médoc, qubes...@googlegroups.com
Can you try with everything the same (xen, kernel, initramfs) but
without tboot in the grub entry, just to make sure it really is the cause?

joanna.

signature.asc

cprise

unread,
Mar 31, 2014, 10:20:20 PM3/31/14
to Joanna Rutkowska, Olivier Médoc, qubes...@googlegroups.com
OK... I restored the rd.antievilmaid reference, deleted the 'multiboot
tboot' line, changed the line for xen from 'module' to 'multiboot'. The
remaining module lines were for vmlinuz, initramfs and the SINIT .BIN
file. Now xl info shows 7884MB total RAM.

I also repeated this with the 3.11.10 kernel and initramfs and got the
same result. The service vms could start without problems for both
kernel versions.

Marek Marczykowski-Górecki

unread,
Apr 1, 2014, 2:38:45 PM4/1/14
to David Hobach, qubes...@googlegroups.com
I haven't found such function, but indeed it is really simple. I'll implement
this, but there are some higher prioritized things first.

BTW Why do you want to disable plymouth, since AEM works with it? You can
always see detailed boot in plymouth by pressing ESC.
signature.asc

David Hobach

unread,
Apr 3, 2014, 12:44:35 PM4/3/14
to Marek Marczykowski-Górecki, qubes...@googlegroups.com
Thanks. I totally agree @prio.

> BTW Why do you want to disable plymouth, since AEM works with it? You can
> always see detailed boot in plymouth by pressing ESC.

Mostly for my convenience (I try to avoid pressing the same buttons day
to day).
Nevertheless it makes sense not to have plymouth as unnecessary
dependency of AEM from my point of view.

cprise

unread,
Apr 3, 2014, 11:33:43 PM4/3/14
to Joanna Rutkowska, Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com
FYI, I've posted the problem to their list and gotten a partial
work-around from Jimmy. He seems intrigued that Qubes is making use of
tboot.

Adding the parameter 'min_ram=0x2000000' after tboot.gz got the missing
memory to re-appear, but the 'insufficient memory' errors remain when
starting vms from VM Manager about 1/2 the time; doesn't seem to be any
problem with qvm-start, however. Also, when I do get the netvm running,
there is sometimes a problem with network traffic being blocked (I might
test this more to see how repeatable it is).


Axon

unread,
May 17, 2014, 7:34:32 PM5/17/14
to Joanna Rutkowska, Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com, Olivier Médoc
Some (hopefully constructive) feedback from a user's perspective after
working with AEM:

1. The requirement that the AEM USB stick be prepared in dom0 directly
contradicts the Qubes rule that USB devices should not be attached
directly to dom0. Correct me if I'm wrong, but it should be possible to
install AEM to a stick connected to an AppVM (USBVM). Presumably this
will be *required* once the USBVM is installed by default in Qubes.

2. The requirement that the Intel SINIT module be copied from an AppVM
to dom0 directly contradicts the Qubes rule that files should never be
copied from AppVMs to dom0 (as well as the more general security rule
that files should never be copied from less trusted to more trusted
security domains). I'm not sure if this one is avoidable (and I did read
the note about this in the doc), but please consider this in conjunction
with point 1 above. According to the AEM docs, the current procedure is
to copy the .BIN from the AppVM to dom0's /boot. Then the whole of /boot
is copied to the AEM stick. Can we instead copy /boot from dom0 to the
stick, then copy the .BIN from the AppVM directly to the stick? Really
anything is better than telling the user to download some weird binary
from the Internet and then copy it to dom0...

3. As noted by others, there does not appear to be an option in the AEM
installer to install to disk (rather than to a removable drive). The
installer states that the selected partition will be formatted before
/boot is copied to it, making it impossible (or just a really bad idea)
to select the /boot partition itself as the destination.

If installing to disk should not be an option, than that's fine, but in
that case the documentation and the installer itself should be clear
about this. (Currently, the docs and the installer both imply that
installing to disk is an option, and the source blog article[1] openly
discusses it as a viable option.)

4. Related to 3, the AEM installer won't accept RAID devices. It expects
input such as:

# /usr/lib/antievilmaid/antievilmaid_install /dev/sdc 1 /boot

which selects sdc1 as the destination.

If one attempts to choose a RAID device, such as /dev/md125, this fails,
because the second argument appears to be simply appended to the end of
the device name. So the installer complains that "md1251" (or more
generally "mdXY") is not a valid device, which of course it is not.


[1]http://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html

signature.asc

Joanna Rutkowska

unread,
May 19, 2014, 6:44:08 AM5/19/14
to Axon, Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com, Olivier Médoc
On 05/18/14 01:34, Axon wrote:
> Some (hopefully constructive) feedback from a user's perspective after
> working with AEM:
>
> 1. The requirement that the AEM USB stick be prepared in dom0 directly
> contradicts the Qubes rule that USB devices should not be attached
> directly to dom0. Correct me if I'm wrong, but it should be possible to
> install AEM to a stick connected to an AppVM (USBVM). Presumably this
> will be *required* once the USBVM is installed by default in Qubes.
>

It is possible to install everything in a USBVM except for doing the
final tpm_seal'ing. This is, naturally, because we don't virtualize TPM
to AppVMs currently.

But I think that doing this:
1) Create a fresh DispVM
2) Format your USB stick there and install AEM from this DispVM
3) Reboot the OS from the AEM stick, loging to Dom0, mount the stick
there and tpm_seal.

... should be reasonably secure, unless you don't trust this particular
stick *firmware* (as opposed to just its partition table, filesystem).
This is because it should get the trusted partition table, filesystem,
as long as you treat this DispVM as trusted (which you should, assuming
you trust the template).

Not 100% ideal, but "good enough" IMHO.

> 2. The requirement that the Intel SINIT module be copied from an AppVM
> to dom0 directly contradicts the Qubes rule that files should never be
> copied from AppVMs to dom0 (as well as the more general security rule
> that files should never be copied from less trusted to more trusted
> security domains). I'm not sure if this one is avoidable (and I did read
> the note about this in the doc), but please consider this in conjunction
> with point 1 above. According to the AEM docs, the current procedure is
> to copy the .BIN from the AppVM to dom0's /boot. Then the whole of /boot
> is copied to the AEM stick. Can we instead copy /boot from dom0 to the
> stick, then copy the .BIN from the AppVM directly to the stick? Really
> anything is better than telling the user to download some weird binary
> from the Internet and then copy it to dom0...
>

Yes, I think so, it should be no problem to copy SINITs as part of step
#1 outlined above. The SINIT files are loaded and executed by tboot
(processor's SENTER) only if they are properly signed by Intel (at least
this is what SDM days). So, this should not be a problem.

Of course we cannot just package SINITs together with AEM rpm(s) because
of licensing limitations.

> 3. As noted by others, there does not appear to be an option in the AEM
> installer to install to disk (rather than to a removable drive). The
> installer states that the selected partition will be formatted before
> /boot is copied to it, making it impossible (or just a really bad idea)
> to select the /boot partition itself as the destination.
>

IIRC this should work fine:

mv /boot /boot.orig

> If installing to disk should not be an option, than that's fine, but in
> that case the documentation and the installer itself should be clear
> about this. (Currently, the docs and the installer both imply that
> installing to disk is an option, and the source blog article[1] openly
> discusses it as a viable option.)
>
> 4. Related to 3, the AEM installer won't accept RAID devices. It expects
> input such as:
>
> # /usr/lib/antievilmaid/antievilmaid_install /dev/sdc 1 /boot
>
> which selects sdc1 as the destination.
>
> If one attempts to choose a RAID device, such as /dev/md125, this fails,
> because the second argument appears to be simply appended to the end of
> the device name. So the installer complains that "md1251" (or more
> generally "mdXY") is not a valid device, which of course it is not.
>
>

Pity. Hm, but that strange, because I remember my previous Vaio had such
device naming and yet I used AEM there without a problem...? Ah, perhaps
not, perhaps my BIOS was taking the /dev/mdXXX devices and was creating
a /dev/sda from them?

Anyway, do you have a patch to fix that?


> [1]http://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html
>


joanna.

signature.asc

Axon

unread,
May 19, 2014, 11:15:23 AM5/19/14
to Joanna Rutkowska, Marek Marczykowski-Górecki, David Hobach, qubes...@googlegroups.com, Olivier Médoc
Joanna Rutkowska:
> On 05/18/14 01:34, Axon wrote:
>> Some (hopefully constructive) feedback from a user's perspective after
>> working with AEM:
>>
>> 1. The requirement that the AEM USB stick be prepared in dom0 directly
>> contradicts the Qubes rule that USB devices should not be attached
>> directly to dom0. Correct me if I'm wrong, but it should be possible to
>> install AEM to a stick connected to an AppVM (USBVM). Presumably this
>> will be *required* once the USBVM is installed by default in Qubes.
>>
>
> It is possible to install everything in a USBVM except for doing the
> final tpm_seal'ing. This is, naturally, because we don't virtualize TPM
> to AppVMs currently.
>
> But I think that doing this:
> 1) Create a fresh DispVM
> 2) Format your USB stick there and install AEM from this DispVM
> 3) Reboot the OS from the AEM stick, loging to Dom0, mount the stick
> there and tpm_seal.
>

So, this would require temporarily stopping the USBVM and transferring
the USB controller back to dom0?

> ... should be reasonably secure, unless you don't trust this particular
> stick *firmware* (as opposed to just its partition table, filesystem).
> This is because it should get the trusted partition table, filesystem,
> as long as you treat this DispVM as trusted (which you should, assuming
> you trust the template).
>

Assuming you trust the template... and the USBVM? (I think we
established in a past thread[2] that the USBVM always has r/w access to
the stick, even when the stick is "attached" to the DispVM.)

> Not 100% ideal, but "good enough" IMHO.
>
>> 2. The requirement that the Intel SINIT module be copied from an AppVM
>> to dom0 directly contradicts the Qubes rule that files should never be
>> copied from AppVMs to dom0 (as well as the more general security rule
>> that files should never be copied from less trusted to more trusted
>> security domains). I'm not sure if this one is avoidable (and I did read
>> the note about this in the doc), but please consider this in conjunction
>> with point 1 above. According to the AEM docs, the current procedure is
>> to copy the .BIN from the AppVM to dom0's /boot. Then the whole of /boot
>> is copied to the AEM stick. Can we instead copy /boot from dom0 to the
>> stick, then copy the .BIN from the AppVM directly to the stick? Really
>> anything is better than telling the user to download some weird binary
>> from the Internet and then copy it to dom0...
>>
>
> Yes, I think so, it should be no problem to copy SINITs as part of step
> #1 outlined above.
>

Sorry, I'm not sure what your "yes" is referring to. Is it a yes to the
question of whether we can just copy the .BIN directly to the stick? I
must confess I'm also not sure which "step #1" you're referring to.
(Your step #1 above is just "Create a fresh DispVM," so I assume it must
be a different "step #1," but I don't see any others "above" where you
wrote that...).

> The SINIT files are loaded and executed by tboot
> (processor's SENTER) only if they are properly signed by Intel (at least
> this is what SDM days). So, this should not be a problem.

Hm, this sounds like you're saying that it should not be a problem to
copy the SINIT files to dom0 (since they're executed only if properly
signed), so maybe you weren't answering yes to my question after all...

> Of course we cannot just package SINITs together with AEM rpm(s) because
> of licensing limitations.
>
>> 3. As noted by others, there does not appear to be an option in the AEM
>> installer to install to disk (rather than to a removable drive). The
>> installer states that the selected partition will be formatted before
>> /boot is copied to it, making it impossible (or just a really bad idea)
>> to select the /boot partition itself as the destination.
>>
>
> IIRC this should work fine:
>
> mv /boot /boot.orig
>

Sorry, I'm not sure I understand. If I do that before selecting the
partition on which /boot resides, then how will the AEM installer copy
/boot to the stick?

>> If installing to disk should not be an option, than that's fine, but in
>> that case the documentation and the installer itself should be clear
>> about this. (Currently, the docs and the installer both imply that
>> installing to disk is an option, and the source blog article[1] openly
>> discusses it as a viable option.)
>>
>> 4. Related to 3, the AEM installer won't accept RAID devices. It expects
>> input such as:
>>
>> # /usr/lib/antievilmaid/antievilmaid_install /dev/sdc 1 /boot
>>
>> which selects sdc1 as the destination.
>>
>> If one attempts to choose a RAID device, such as /dev/md125, this fails,
>> because the second argument appears to be simply appended to the end of
>> the device name. So the installer complains that "md1251" (or more
>> generally "mdXY") is not a valid device, which of course it is not.
>>
>>
>
> Pity. Hm, but that strange, because I remember my previous Vaio had such
> device naming and yet I used AEM there without a problem...? Ah, perhaps
> not, perhaps my BIOS was taking the /dev/mdXXX devices and was creating
> a /dev/sda from them?
>

Actually, I don't know. I suppose you're right that the "mdXXX" naming
scheme isn't just for RAID devices; I only described it in terms of RAID
devices because that was my personal experience.

> Anyway, do you have a patch to fix that?
>

Sorry, I do not. I was just reporting my experience. On the bright side,
I would guess that very few, if any, prospective AEM users would want to
select a RAID device anyway, so it's probably not very important. (I
just try to report any information that I think might somehow be helpful.)

>
>> [1]http://theinvisiblethings.blogspot.com/2011/09/anti-evil-maid.html
[2]https://groups.google.com/d/topic/qubes-users/M8F8xDttOwA/discussion
>
>
> joanna.
>


signature.asc

cprise

unread,
May 19, 2014, 12:33:31 PM5/19/14
to qubes...@googlegroups.com, Axon, Marek Marczykowski-Górecki, David Hobach, Olivier Médoc

Yeah, I think telling the user in the AEM instructions to unzip the SINIT files in an appvm would keep it secure. Copying the SINIT BIN file into Dom0 shouldn't be a problem: Its not a Linux executable and the execute bit won't be set anyway, so no accidental execution in the dom0 shell. Otherwise, the signature has to be good to be executed at all.
 

Axon

unread,
May 20, 2014, 1:00:30 AM5/20/14
to cprise, qubes...@googlegroups.com, Marek Marczykowski-Górecki, David Hobach, Olivier Médoc
cprise:
Did you mean "dispvm" rather than "appvm" here? (If you did mean
"appvm," then I'm not sure I see why that would keep it secure...)

> Copying the SINIT BIN file into
> Dom0 shouldn't be a problem: Its not a Linux executable and the execute bit
> won't be set anyway, so no accidental execution in the dom0 shell.
> Otherwise, the signature has to be good to be executed at all.

Ah, I see. I suppose it's OK to make an exception in this one case to
the "don't copy files to dom0" rule. :)

Well, the important thing is that each individual Qubes user gets to
decide for him/herself whether they are willing to make this exception
in order to reap the benefits of AEM (the value of which will differ
among individual user circumstances).


signature.asc

cprise

unread,
May 20, 2014, 11:33:32 PM5/20/14
to Axon, qubes...@googlegroups.com, Marek Marczykowski-Górecki, David Hobach, Olivier Médoc
Its fine to copy files into dom0 in most cases where they have a trusted
signature (and, indeed, we are trusting Intel anyway). Package files get
copied into dom0 all the time, but that's OK because they're signed
packages. But in this case its the BIN file within the zip and not the
zip itself that is protected/signed.

As for unzipping, that implies the user is making the usual
Qubes-related decision about what is and isn't risky. Unzipping
downloaded files may be a bit risky, so choose an appvm ('untrusted' or
similar) or dispvm as seems appropriate.

Axon

unread,
May 21, 2014, 2:23:58 AM5/21/14
to cprise, qubes...@googlegroups.com, Marek Marczykowski-Górecki, David Hobach, Olivier Médoc
cprise:
This case actually seems quite different, though, because we have no way
to verify the signature ourselves (or to know whether the "SENTER
instruction of the processes" is correctly checking the signature).
We're also downloading the file by pointing our browsers to the HTTPS
Intel download page, so we're essentially trusting that we weren't the
victim of a MITM attack (e.g., forged cert). So, it's not the same as
trusting signed yum updates, and it's not the same as purchasing a
sealed, physical CPU from Intel (which we then have to trust), IMO.

So, maybe this case is a bit riskier, yes? But is the extra risk worth
it? For some people, it surely is. (For example, someone who travels a
lot and has to leave their laptop unattended in hotel rooms, where evil
maids might get to it.) For others, probably not. (For example, a Qubes
machine which always sits on a desk inside the locked house of someone
who lives alone.)
signature.asc

Daniel Lukes

unread,
May 21, 2014, 3:30:04 AM5/21/14
to Axon, cprise, qubes...@googlegroups.com, Marek Marczykowski-Górecki, David Hobach, Olivier Médoc

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We could perform a sha512sum of the respective SINITs we download, and
send them signed to this list.

If people are feeling generous, they could download many SINITs from the
SSL Intel page, and send the sums.
>
>
> So, maybe this case is a bit riskier, yes? But is the extra risk worth
> it? For some people, it surely is. (For example, someone who travels a
> lot and has to leave their laptop unattended in hotel rooms, where evil
> maids might get to it.) For others, probably not. (For example, a Qubes
> machine which always sits on a desk inside the locked house of someone
> who lives alone.)
>
>> As for unzipping, that implies the user is making the usual
>> Qubes-related decision about what is and isn't risky. Unzipping
>> downloaded files may be a bit risky, so choose an appvm ('untrusted' or
>> similar) or dispvm as seems appropriate.
>>
>

- --
Daniel Lukes (920)-901-9298 daniel...@yandex.ru
daniel...@openmailbox.org daniel...@opmbx.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTfFXoAAoJEBGF1xscz1OesPkP/39obr6YlZ7laaxqoaJVINhP
z6msOj3vK1EtceMtqAOr/bfKngZHA8NO0OY22CxpAaxTqifas8qKZc7ZRZUQ+aMn
UFBB8RhmDAyoqegN9i2Smu0zS//yuUSioUPArKOEhw2FPYJL6dElQYIZMtb0luAW
h6RYHJvIEfSlSLAvLVCzYsZT+IwOklY++6xbk/5Eq3K3q8w17qZ0vW0rfo35RTzv
ijYmbD0JK4LL4+hLKxGxZLHkwcrMfd07W99yIXnCzyfDch3WZIt449B84ajJZy6U
1d17ZvHoSZfKalQjoypwOiaCZNLa1u1SYlxmo5T2A7cNHc28kzT9cIeYWPaMk/P2
jrE/ReUWwQXYPeDt6JvScVljNNxE4czTqouz19+8KjBv+xDx4C6gua1nf2adMhEx
KjVytgYqWgq5BwWXFWc5lopZAnmSh/9pQ876k3VbR22U4iob7V8Xe4Vwj/OCQAPG
F3SBUZU+SxT/ULdYR1GMNwcgy0NEn3wU1wQRiPCi00MBRb1KhE4SRfUdi6wxFXP1
BJPSsRH4bj/v7mStKTa1qpY865ShFI6Ou4V81Ad5nS7OHeRJjnNt6I5U3meR+TwB
7UyRTw/b/B5s2XlfjewKR4iNhJD0QzYjAyRcrQPpIsbXSZP9ONXvTJSqTIbmJ8b4
/blA1LInUL5cH9m2F1ca
=DqAz
-----END PGP SIGNATURE-----

Daniel Lukes

unread,
May 21, 2014, 3:57:46 AM5/21/14
to qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



Axon:
We could perform a sha512sum of the respective SINITs we download, and
send them signed to this list.

If people are feeling generous, they could download many SINITs from the
SSL Intel page, and send the sums.

EDIT TO ADD: Meanwhile in conspiracy theories, TBird + Enigmail are
forcing SHA1 against my key prefs.
>
> So, maybe this case is a bit riskier, yes? But is the extra risk
> worth it? For some people, it surely is. (For example, someone who
> travels a lot and has to leave their laptop unattended in hotel
> rooms, where evil maids might get to it.) For others, probably
> not. (For example, a Qubes machine which always sits on a desk
> inside the locked house of someone who lives alone.)
>
>> As for unzipping, that implies the user is making the usual
>> Qubes-related decision about what is and isn't risky. Unzipping
>> downloaded files may be a bit risky, so choose an appvm
>> ('untrusted' or similar) or dispvm as seems appropriate.
>>
>

- --
Daniel Lukes (920)-901-9298 daniel...@yandex.ru
daniel...@openmailbox.org daniel...@opmbx.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTfFxwAAoJEBGF1xscz1OeGX4QALVEh9I8MCgtugeXQcrjTuwb
3SRvueb8yBIWBmp8HKRMPt3e/KfsxcqXkqw0L2yshC0WeZlu8JjR2A3lhNuNiHxq
pKYw9nwnnoeEk16BBIhgcXJOmy1QoVrk0c4+ECqDCWpa4+19gR6T7rlbBcQmD5to
tahDKBINwosXX0DAVGe+RVUELnBC3eJbFh7pPDwYxA0BJJj+BfCp5/NApWMqCYGm
/z25bQc17xcc/XZJXYfAkmnnBWpD+4FKyC/+bppxqFHU+dmCBW+W8elFtBPqi3Fh
6rZSTj3Kc5jkdOmd+pzWDHF3J6dCnP/RWIBCOpBR6Lo6EI3SjhEcqk12x1QvNQQi
ADsBgWkap0DUT3/j4WZJpxy5rvKG4vZN/zM9MEOL2USDXyqlo9V0XvQJI1shXDYZ
IrQhRMp4IT8K0IdA7i1p1G8OhUG5WqNLhP8kSVQMS34fg1Z2xl5kEX3CXRR8YoVo
AEfdIqRKJ9/CSCOEWBo1+3A50wIgjkTaWfXEA12+QkHulhm6/PuY4MQodvA9qfo7
NnOusAhhmrNCQK3z7pEiXhxrJ1k6Yq1+HxfaiF7U2Yjp8joyymU9CpRVM0OM43zO
G6eRuz0XYAIjTaAz9q4MVqeh5UtXyv9REup1WJxQ5suAQ29/X9eg9nUSgvQFvSES
YsgaTz/EOAk9aeEtIhRg
=9iyH
-----END PGP SIGNATURE-----

Axon

unread,
May 22, 2014, 4:47:34 PM5/22/14
to cprise, qubes...@googlegroups.com, Marek Marczykowski-Górecki, David Hobach, Olivier Médoc
Axon:
Some of you are thinking, "But what if someone sneaks into your house
(e.g., no-knock warrant) and performs an Evil Maid attack on you?"

If you have reason to believe that someone might sneak into your house
(and that you wouldn't notice afterward), then yes, that's a legitimate
concern for you. However, consider this: If someone can sneak into your
house, then they can also install a hidden pinhole camera somewhere
which records your keystrokes (or a hardware keylogger, or something
else which performs the same function of sniffing your typed passphrases).

"Fine," you say, "then I'll just use my AEM stick to supply a keyfile
for my LUKS encrypted system drive. This way, even if they somehow learn
my passphrase, they still won't be able to decrypt my system drive." The
only problem is that your *backup* doesn't require a keyfile (nor should
it, since a disaster which requires you to restore from the backup could
easily destroy all available copies of the keyfile). So, all the
attacker has to do is learn your backup passphrase and acquire a copy of
your encrypted backup file (which is probably pretty easy to do without
your notice if you're storing copies off-site, like you're supposed to).

Does anyone have a solution for this? :)
signature.asc

Axon

unread,
May 22, 2014, 5:14:45 PM5/22/14
to cprise, qubes...@googlegroups.com, Marek Marczykowski-Górecki, David Hobach, Olivier Médoc
Axon:
Sorry, I meant "sneak and peek warrant" here.
See: https://ssd.eff.org/your-computer/govt/sneak-and-peek
signature.asc

cprise

unread,
May 22, 2014, 9:24:52 PM5/22/14