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