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?
>> 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?
Yes :) Although, as just discussed above, this whole AEM preparation in
AppVM (usbvm or dispvm) really gives you nothing :/
> 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...
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?
>> 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?
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...