Hi josch, On Wed, 20 Nov 2019 at 11:21:31 +0100, Johannes Schauer wrote: > Indeed it would not. The autopkgtest does not even test upgrades. But when I > re-installed the system after the upgrade failed I also was unsure in many > points of how to do it correctly. The autopkgtest does not only serve as a > constant assurance that the current state does work but also serves as > documentation of which knobs have to be turned to successfully set it up. It > can thus serve as an addition to > /usr/share/doc/dropbear-initramfs/README.Debian
Fair enough :-) >> I'd also bind to INADDR_LOOPBACK, change the NIC and drive model from the >> default (resp. e1000 and ide) to virtio, and pass `-no-user-config >> -nodefaults`. Maybe also set the CPU model to host. Might also help to >> create a virtio-rng device, given that key material is generated on the >> guest. > > I'm unsure about -no-user-config -nodefaults. This will require a much larger > command line for what benefit? For ‘-nodefaults’ it might be reasonable to assume that the qemu maintainers make sure to have sane default that don't break on upgrade, however ‘-no-user-config’ shouldn't require a larger command line and will be really useful for those who run the pkgtest in unclean environments. (One could have tons of stuff there, including extra disks, different boot priorities, etc. and shoot oneself in the foot.) > What benefit would changing the nic and drive to virtio have? Sorry, I'm not > an > expert on this. :) I guess QEMU defaults to “full virtualization” (incl. hardware emulation) because not all guest OS are VirtIO-aware. When the guest OS can speak VirtIO it makes little sense to emulate a particular hardware. That said saving the abstraction cost won't give a huge perf gain here because there is not much I/O. Another advantage is the reliable block device paths (/dev/vda for the first drive), while otherwise that depends on the bus (SATA, IDE) and driver in use. > Yes, adding something like this might be useful: > > -object rng-random,filename=/dev/urandom,id=rng0 -device > virtio-rng-pci,rng=rng0 > > I'll benchmark this to see whether there is a noticeable difference. That's a hard requirement when the guest calls getrandom(,,GRND_RANDOM) or reads from the blocking PRNG. dropbear(8) doesn't *right now*, but other components in the software stack do and on headless VMs there is a real risk of entropy starvation without virtual hardware RNG (cf. last year's “Handling of entropy during boot” thread on debian-devel.) >>> printf myinsecurepassphrase | cryptsetup luksFormat /dev/sdb3 - >> To speep up things I suggest to skip the the PBKDF benchmark by passing >> `--pbkdf-force-iterations 4 --pbkdf-memory 32` (for Argon2), or >> `--pbkdf-force-iterations 1000` (for PBKDF2). cryptsetup <2.0 (up to >> Stretch) are only able to format and open LUKSv1 volumes, which only >> supports PBKDF2 as PBKDF algorithm; since cryptsetup 2.0 a new LUKS >> version format is available (and is the default as for Buster) with >> support for both Argon2i/d (default) and PBKDF2. > > Is this only for a potential speedup? Is it not better to test the default > setup? PBKDF are by design expensive functions; when a new keyslot is added, a benchmark is run to choose parameters that are 1/ expensive enough to defeat bruteforce attacks, and 2/ reasonable enough to avoid waiting too long for the device to unlock. When `luksFormat` and `luksOpen` are called from machines with different clock speed and/or RAM size, the benchmark is just moot; and when the former machine is much more beefy than the latter, which is likely the case here (though maybe not in the CI pipeline), unlocking might take a loooong time, or even trigger the OOM killer and cause the test to fail. With my cryptsetup maintainer hat on, the general recommendation when `luksFormat` and `luksOpen` are called from different machines, is to collect parameters on the latter machine, and use them when creating the keyslot. For a test though it makes sense to skip the benchmark altogether and PBKDF parameters that are as cheap as possible, to avoid wasting RAM and CPU cycles. FWIW this is also what I do in the tests for cryptsetup-initramfs (which I mean to turn into autopkgtests as well). :-) Thanks! Cheers, -- Guilhem.
signature.asc
Description: PGP signature
