|Bug Reports: AEM in Qubes||David Hobach||2/24/14 9:26 AM|
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
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
I fixed 2. a) + b) for my setup (I didn't test others). You can find the
patched files attached.
My kernel parameters fyi:
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
Thanks for your good work at Qubes!
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Marek Marczykowski-Górecki||2/28/14 5:00 AM|
On 24.02.2014 18:26, David Hobach wrote: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.
Thanks, I'll look at it and most likely apply.
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?
|Re: [qubes-devel] Bug Reports: AEM in Qubes||David Hobach||2/28/14 9:40 AM|
On 02/28/2014 02:00 PM, Marek Marczykowski-Górecki wrote:Marek, can you please explain this a little bit more (i.e. multistage EM
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...
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Marek Marczykowski-Górecki||2/28/14 10:26 AM|
On 28.02.2014 18:40, David Hobach wrote: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.
I don't remember details, perhaps only kernel cmdline (along with kernel
binary and initrd) is used, not the whole grub.cfg?
|Re: [qubes-devel] Bug Reports: AEM in Qubes||David Hobach||3/1/14 3:15 AM|
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
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).
This makes me think a USB stick with read-only switch for /boot might
even be better for my setup.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Marek Marczykowski-Górecki||3/1/14 6:26 AM|
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.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||cprise||3/10/14 9:42 AM|
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
When building the AEM boot partition, for each kernel in the boot
options it prints "F: Failed to install module fpu".
|Re: [qubes-devel] Bug Reports: AEM in Qubes||David Hobach||3/10/14 10:04 AM|
> I am also having a problem with AEM. I used a custom SRK password andAre 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.
That's nothing to be concerned about if I remember correctly.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||cprise||3/10/14 6:38 PM|
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
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.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||cprise||3/10/14 7:55 PM|
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...
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.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||David Hobach||3/11/14 10:08 AM|
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?
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).
|Re: [qubes-devel] Bug Reports: AEM in Qubes||cprise||3/11/14 12:03 PM|
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.
>The TPM passphrase. It seems to be unsealing and printing fine, and it
states that its using the default SRK password.
I don't see any sign of a prompt. The stoppage comes after the TPM
passphrase is printed and before the LUKS prompt.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Olivier Médoc||3/12/14 12:32 AM|
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.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Olivier Médoc||3/12/14 12:34 AM|
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:
|Re: [qubes-devel] Bug Reports: AEM in Qubes||cprise||3/12/14 6:37 AM|
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
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Marek Marczykowski-Górecki||3/12/14 7:13 AM|
Indeed there is a problem with plymouth theme, I'm currently working on it.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||cprise||3/12/14 7:23 AM|
The AEM installer could automatically disable plymouth.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Olivier Médoc||3/12/14 9:11 AM|
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...
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Marek Marczykowski-Górecki||3/12/14 2:50 PM|
Yes, it is possible to debug it without constantly restarting the system:
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Marek Marczykowski-Górecki||3/13/14 6:51 PM|
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.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Olivier Médoc||3/14/14 2:33 AM|
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).
|Re: [qubes-devel] Bug Reports: AEM in Qubes||David Hobach||3/14/14 9:03 AM|
On 03/14/14 02:51, Marek Marczykowski-Górecki wrote:Thanks Marek!
I'll test it once I find some time.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||cprise||3/21/14 2:55 AM|
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.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Marek Marczykowski-Górecki||3/21/14 3:01 AM|
On 21.03.2014 10:55, cprise wrote:Are you sure you've choosed AEM grub entry? Note that entries order have
changed - now AEM is the first one.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||cprise||3/21/14 3:10 AM|
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.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Marek Marczykowski-Górecki||3/21/14 5:33 AM|
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
>> 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).
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?
|Re: [qubes-devel] Bug Reports: AEM in Qubes||cprise||3/21/14 10:36 AM|
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
|Re: [qubes-devel] Bug Reports: AEM in Qubes||David Hobach||3/29/14 11:39 AM|
>>> 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
>> 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 -
>> 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.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||cprise||3/29/14 1:28 PM|
I reported the same problem on March 21:
I may look in the boot image to see if an execute bit is missing somewhere.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Marek Marczykowski-Górecki||3/29/14 3:55 PM|
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
@joanna Can you upload new AEM package also to current-testing repo?
|Re: [qubes-devel] Bug Reports: AEM in Qubes||cprise||3/29/14 11:34 PM|
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.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||David Hobach||3/30/14 4:32 AM|
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?
@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.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||cprise||3/30/14 11:54 AM|
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).
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Marek Marczykowski-Górecki||3/30/14 12:12 PM|
/proc/meminfo (in dom0) shows only dom0 memory. All detected memory can be
shown by 'xl info' (total_memory field).
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 is the only possible problem here. Is it reproducible, or happened just once?
|Re: [qubes-devel] Bug Reports: AEM in Qubes||cprise||3/30/14 9:11 PM|
5092 for AEM boot
7884 for non-AEM boot
Both times booting from the USB stick.
Its 100% reproducible.
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
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.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||joanna||3/31/14 1:45 AM|
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.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||joanna||3/31/14 2:24 AM|
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Olivier Médoc||3/31/14 10:31 AM|
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.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||cprise||3/31/14 12:19 PM|
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.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||joanna||3/31/14 4:13 PM|
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?
|Re: [qubes-devel] Bug Reports: AEM in Qubes||cprise||3/31/14 7:20 PM|
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
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Marek Marczykowski-Górecki||4/1/14 11:38 AM|
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.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||David Hobach||4/3/14 9:44 AM|
Thanks. I totally agree @prio.
Mostly for my convenience (I try to avoid pressing the same buttons day
Nevertheless it makes sense not to have plymouth as unnecessary
dependency of AEM from my point of view.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||cprise||4/3/14 8:33 PM|
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
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).
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Axon||5/17/14 4:34 PM|
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 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.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||joanna||5/19/14 3:44 AM|
On 05/18/14 01:34, Axon wrote: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.
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.
IIRC this should work fine:
mv /boot /boot.orig
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?
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Axon||5/19/14 8:15 AM|
> On 05/18/14 01:34, Axon wrote:So, this would require temporarily stopping the USBVM and transferring
the USB controller back to dom0?
Assuming you trust the template... and the USBVM? (I think we
established in a past thread that the USBVM always has r/w access to
the stick, even when the stick is "attached" to the DispVM.)
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
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...
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?
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.
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.)
|Re: [qubes-devel] Bug Reports: AEM in Qubes||cprise||5/19/14 9:33 AM|
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.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Axon||5/19/14 10:00 PM|
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...)
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).
|Re: [qubes-devel] Bug Reports: AEM in Qubes||cprise||5/20/14 8:33 PM|
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.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Axon||5/20/14 11:23 PM|
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.)
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Daniel Lukes||5/21/14 12:30 AM|
-----BEGIN PGP SIGNED MESSAGE-----
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.
Daniel Lukes (920)-901-9298 daniel...@yandex.ru
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Daniel Lukes||5/21/14 12:57 AM|
-----BEGIN PGP SIGNED MESSAGE-----
We could perform a sha512sum of the respective SINITs we download, andEDIT TO ADD: Meanwhile in conspiracy theories, TBird + Enigmail are
forcing SHA1 against my key prefs.
-----END PGP SIGNATURE-----
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Axon||5/22/14 1:47 PM|
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? :)
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Axon||5/22/14 2:14 PM|
Sorry, I meant "sneak and peek warrant" here.
|Re: [qubes-devel] Bug Reports: AEM in Qubes||cprise||5/22/14 6:24 PM|
This is no longer talking about AEM bugs. However, it would be
interesting to hear if anyone does have a solution.
AFAIK, Qubes' "strong security" is focused against remote/network
threats. AEM is there to try to prevent the *easy* physical attacks from
|Resistance against keystroke sniffers (was: Re: [qubes-devel] Bug Reports: AEM in Qubes)||joanna||5/23/14 5:13 AM|
On 05/22/14 22:47, Axon wrote:That's a very good point about backups being vulnerable to keystroke
sniffing attacks. I don't have a convenient solution to that problem,
apart from Being Carefull(TM) while entering your backup passphrase. The
"Being Careful(TM)" should include taking into account not only hidden
cameras, but also EM leaks (e.g. look out for a van with tinted windows
near your house while entering your passphrase ;)
A solution with splitting your backup passphrase to have part of it
being kept on some smartcard buys one little in case the adversary hsa a
warrant on you -- they can just seize your smartcard..
Perhaps a better solution would be to somehow keep the backup passphrase
in a text file in you dom0 and only copy-paste it for the backup, or
even do something like:
qvm-backup --passphrase `cat ~/my_backup_passphrase.txt`
The ~/my_backup_passphrase.txt could be created over a long period of
time, perhaps also using on-screen-keyboard for it (hm, I think KDE in
dom0 doesn't have one, oh well, but it could).
Of course, for this to make sense, one would need to have AEM properly
deployed, your system shut down when you leave your premises, and LUKS
configured to read keyfile from AEM stick (should be easy doable).
|Re: [qubes-devel] Bug Reports: AEM in Qubes||joanna||5/23/14 5:52 AM|
Hm, after thinking more about this, I think we're essentially faced with
the following dilemma:
1) Do we trust our (still fresh) stick to be "clean" (e.g. because we
just bought it in a shop and just freshly unpacked it),
2) Do we trust our usbvm or dispvm to be able to do a good job on
cleaning up a potentially compromised stick
If we're reasonably sure we bought a clean stick (case #1), I think we
would be safest to just: 1) stop the usbvm (if we have one), 2) assigned
the usb controller to dom0, 3) insert the stick there and proceed with
normal AEM installation procedure.
If, however, we assume the stick we bought at the shop might be
compromised already (these days it might not be an unreasonable
thinking) then we might want to clean it first. And so the tempatation
is to connect it to a usbvm first, clean it up and install AEM there
before connecting to Dom0. Only that... if it is compromised than, it
might just as well compromised the usbvm the moment we inserted it
there, and so we no longer will be able to clean it up reliably.
So, I think there is really no good workaround against #2 case, is it?
Yes :) Although, as just discussed above, this whole AEM preparation in
AppVM (usbvm or dispvm) really gives you nothing :/
No problem copying a stream of bytes to dom0, as long as they are not
used by anything in dom0 (or used only conditioned on some additional
verification of their signature). In case of SINIT files lying in /boot
on dom0, this is just the case -- these are merely some blobs, which no
software in dom0 ever uses (unless a user explicitly types in dom0
commands in Dom0 to somehow open them, etc). They are only used by tboot
during OS booting, as we trust tboot to be actually verifying them
At least I'm pretty sure that SENTER verifies the content of those files
before executing it. It is less clear to me if tboot does any
non-trivial processing of the .BIN files in order to extract what's
inside and pipe to SENTER? If so, this code would be the potential
attack point where a malicious SINIT file could potentially exploit.
Anybody care to research this further?
Ah, would "cp -r" instead of "mv" solve this problem? (Sorry, it's been
a while since I installed AEM on a HDD, and cannot test this ATM).
Hm, isn't that most RAID solutions (at least HW/BIOS-based) should be
exposing /dev/sdX device after all? I.e. that nobody should really be
using /dev/mdX? I don't know really...
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Axon||5/24/14 12:34 AM|
Many of the new, factory-sealed USB flash drives I buy have "stuff" on
them already. Usually it's some crap software put there by the
manufacturer. So I always like to zero-fill them before using them for
my own purposes. And, indeed, this presents exactly the dilemma you
describe. I have often wished there were a very simple device into which
I could plug a USB mass storage device, press a button, and it would
simply write zeros until there's no more room. (In addition to the
single button, there would be a single LED on this device, which would
be lit if and only if the device is writing. Once the light goes off, I
can unplug the drive. The firmware/software of this device would not be
modifiable in any way.) Is something like this possible? Anyway, I think
it would solve our problem. :)
In any case, the manufacturer bloatware (if you can call it that)
pre-written to USB drive is probably more annoying than malicious.
However, nowadays it's probably not unreasonable to fear that a USB
drive which you order online might have been "interdicted" and that
special software might have been added just for you that runs as soon as
you plug in the drive.
Oh, I see what you mean now. (I haven't tried it, but this clears up my
confusion. Thank you.)
For true hardware raid or BIOS fakeRAID, probably. But when you create
RAID partitions via the Qubes/Fedora installer, they end up as
"/dev/mdX". (This is effectively the same as using mdadm.) Consensus in
the Linux community seems to be that software RAID is superior (unless
you have a really expensive true hardware RAID controller).
|Re: Resistance against keystroke sniffers||Axon||5/24/14 12:37 AM|
Yes, I was thinking about this too. The only problem is that using an
on-screen keyboard doesn't help if your adversary has a hidden camera in
place already, since the camera can see on-screen keyboard inputs as
easily as (if not more easily than) physical keyboard inputs.
Of course, if you create my_backup_passphrase.txt *before* your
adversary has a hidden camera in place, then you're safe. But the whole
point of hidden pinhole cameras (and other hidden surveillance devices)
is that you can't tell whether they're there (at least not without
expensive specialized scanning equipment and/or lots of time). This, of
course, also applies to all other passphrase-sniffing methods. If you
create my_backup_passphrase.txt before your adversary has a chance to
install a hardware keylogger, then you're just as fine if you just use
the physical keyboard.
So, I suppose you can reduce your risk by only copy/pasting the backup
passphrase each time instead of typing it, but this assumes that you're
safe the first time you enter it, which may or may not be a valid
Would it be difficult to add a "remember passphrase" option to the Qubes
backup system? That would be a bit cleaner than copy/pasting from a text
file and serve the same function, I think. Also, the passphrase would be
masked while initially entering it, and there would be no risk of
accidentally unmasking it (as in the case of accidentally opening or
Another thing to note is that this means that the main system disk
encryption passphrase should be different from the backup passphrase.
Right. Somewhat related: If someone is *not* using AEM, then would it
actually be safer to leave the system powered on while away? Of course,
this leaves one vulnerable to cold boot attacks, but it seems like cold
boot attacks are actually much harder to pull off in practice than evil
maid attacks. And most intruders (whether robbers or law enforcement
agents) seem more likely to just rip all the cords out of the wall and
haul the hardware away (unless you are some sort of special high-value
|Re: [qubes-devel] Bug Reports: AEM in Qubes||Hakisho Nukama||5/24/14 4:59 AM|
I would be more concerned about the software, that resides inside
the micro-controller of such devices.
Zeroing out your drive wouldn't buy you an advantage, if the micro-controller
includes some adversary-friendly modification.
|Open Source USB/AEM stick (was: Re: [qubes-devel] Bug Reports: AEM in Qubes)||joanna||5/24/14 1:53 PM|
We need an open source USB stick, perhaps even optimized to act as Anti
Evil Maid stick (TBD). Surely doable using some Arduino boards (e.g.
Leonardo?). Only I'm not sure about how to implement mass storage for it
in a simple way (and not using a 3rd party USB or SD stick). Using
ATMega's flash/eeprom would give us only a few tens of KBs, sadly not
enough for AEM, which needs at least a few hundred of MBs.
Hmm, actually even if we used an Arduino that uses a 3rd party (off the
shelf) USB stick for mass storage and so just acts as a "proxy" for it,
it should actually be quite a safe setup, as we will be controlling the
USB stick's firmware that talks directly to our computer (so no
malicious attacks here). The Arduino might also be implementing a simple
crypto so that the 3rd party stick were also unable to meaningfully
modify the actual content exposed to our computer (e.g. expose malformed
partition table or filesystem metadata). Not sure about the performance
of this "simple crypto" on an 8-bit ATMega. But then, on the other hand,
it's just a few boot modules that we need to read from the stick (mbr,
grub, xen.gz, kernel and initramfs).
Anybody interested? :)
|Re: Resistance against keystroke sniffers||joanna||5/25/14 2:37 AM|
There is always a point where one needs to be safe "for the first
time"... In case of resisting camera -- that's relatively simple to put
on some "hood" around you and the laptop and enter it securely for the
first time :)
The bigger problem I would be afraid of was the EM-sniffing van next to
your apartment. Ok, then you could use a metal-sheet-hood.
I think that should be fine.
Yes, indeed. Although one should make sure that hot-pluggable devices
are not assigned to Dom0, or at least the modules for hotpluggable
bridges are not loaded (I think this is just enough to deactive
PCMCIA-based hotplug DMA attacks).
|Re: Open Source USB/AEM stick||Robert Fisk||1/31/15 7:39 PM|
This thread stuck in my mind last year, and having spent some time on
research I would like to re-animate it.
On the topic of taming BadUSB, I can envision a hardware widget that
contains two microcontrollers. One talks to the PC and emulates a USB
device, such as a flash drive (mass storage class). The other
microcontroller is a USB host talking to the actual untrusted flash
drive. The two microcontrollers pass data through a simple protocol over
a local bus such as SPI at ~10MHz.
Any attempt by the untrusted USB device to exploit the host stack cannot
break out of the first microcontroller due to the restricted protocol on
the local link. Any attempt to act as a composite device with keyboard
and thereby insert malicious keystrokes into the host PC will fail
because the microcontroller firmware cannot support both a flash drive
and a keyboard at the same time.
The hardware required for this widget will probably involve a couple of
development boards from Olimex. One has the device connector onboard,
while the other has the host connector. Some assembly of the inter-board
link will be required.
The STM32 processors on these boards are well-supported by opensource
development tools, and support a (relatively) easy upgrade path to USB2
with the addition of external PHYs. They also have enough horsepower to
perform simple encryption to obfuscate the data written to the flash drive.
This approach can be extended to isolate other USB devices, eg keyboards
and mice, and potentially 3G modems through the CDC device class. It
will also be possible to integrate the entire design onto a single PCB,
although that will be left as an exercise for the future.
This project will of course be of interest to users of all OSs. But I am
asking for input here to guide the project so that it may be more useful
to the paranoid group known as Qubes users! Any comments welcome.
|Re: [qubes-devel] Re: Open Source USB/AEM stick||coderman||1/31/15 7:43 PM|
On 1/31/15, Robert Fisk <rober...@fastmail.fm> wrote:
> The hardware required for this widget will probably involve a couple ofinteresting - i am currently waiting on delivery of USB Armory
devices; the cost is a premium, but a pair back to back could achieve
fun in either case; please report results here, too. good luck!