pefu's questions

I'm running Qubes-OS 4.1.0 While looking through the /var/log/xen/console/hypervisor.log I stumbled over the following messages:

...
(XEN) [VT-D] It's risky to assign 0000:00:14.0 with shared RMRR at c9f42000 for Dom40.
(XEN) [VT-D] It's risky to assign 0000:00:1d.0 with shared RMRR at c9f42000 for Dom40.

In my case those PCI devices in question are USB controllers. They are handled by a VM called sys-usb in order to protect the bare metal carrier system from the risks of any malicious USB device being plugged in.

My questions are: What is the meaning of the acronym RMRR in this context? And what are the risks involved with this so called "shared RMRR"?

I'm still struggling to understand boot sequence dependency configuration in systemd unit files. I've read the manual (systemd.unit).

I tried to add dependencies using the After= and Requires= lines to my unit configuration file. However it still regulary fails during system startup because systemd starts it too early before a needed resource (in my case a LUKS encrypted volume) has become available. In my tests it looked like systemd is ignoring these configuration lines. The content of these lines is also not listed when using the command:

systemctl list-dependencies

to check for configured dependencies. Example: My device volume is /dev/dm-6. How can I specify that systemd should wait with starting my unit until this device has finally appeared?

If I start my unit manually in a terminal window after boot using this command:

systemctl start name_of_my_unit

it works fine.

My question is related to this question:

In some bash script I found this snippet here:

...
if [ -e /etc/debian_version ]
then ipv4_localhost_re="127\.0\.1\.1"
else ipv4_localhost_re="127\.0\.0\.1"
fi
sed -i "s/^\($ipv4_localhost_re\(\s.*\)*\s\).*$/\1${name}/" /etc/hosts
sed -i "s/^\(::1\(\s.*\)*\s\).*$/\1${name}/" /etc/hosts
...

I'm wondering whether this method for editing the hostname is still correct for all other stems of Linux distributions and whether and how those other distributions handled the problem which was originally reported as Debian Bug in 2005 and which led to the introduction of the 127.0.1.1 workaround which seems to be still being used in Debian, Ubuntu and so on until today but not in Fedora, SuSE, and many others (If my research is correct).

To summarize: Do you know a Linux distribution out there which is not based on Debian or has no longer a /etc/debian_version file but has still adopted this 127.0.1.1 solution?

Imagine confidential information (certificates, keys, whatever) stored on an LUKS encrypted backup disk containing for example an ext4 file-system. AFAIK such a device contains a key file which is in turn encrypted with some pass-phrase. Suppose the secret pass-phrase was created using the utility:

pwgen -s 16

to get some semi-random string. For example "Z4sp9gmW47R8K0sy" After studying the cryptsetup FAQ I believe this should provide 94.4 bits of entropy and that should be enough to sleep well for the time being.

Imagine some such disk gets stolen or copied and some evil attacker is willing to spend reasonable resources to crack this media open.

How difficult will this really be?
Is the data really safe as long as the pass-phrase is not leaked (compromised) by other means?

During the last two nights we had mysterious events on a server running Ubuntu Linux 12.04 LTS with a Linux mdadm software RAID10:

DeviceDisappeared /dev/md0
NewArray /dev/md127

Both messages appeared in the same second, on the same time as the logrotate cron action happened. Although the array is still named /dev/md0 in /etc/mdadm/mdadm.conf, it appears as /dev/md127 in the output of cat /proc/mdstat:

Personalities : [linear] [multipath] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 
md127 : active raid10 sdb1[0] sdg1[5] sdc1[1] sdh1[6] sdf1[4] sdd1[2] sdk1[9] sdj1[8] sde1[3] sdi1[7]
      9746600960 blocks 512K chunks 2 near-copies [10/10] [UUUUUUUUUU]

unused devices: <none>

Why is this so and how can I fix this?

I recently read this nice Howto tutorial about doing backups with whole disk encryption using LUKS. Surprisingly for me this tutorial contains as the first part of step #3 a command to overwrite the new disk partition with encrypted binary zeros:

dd if=/dev/zero of=/dev/mapper/your_encrypted_disk_partition

Obviously this command will be very time consuming considering the huge disks available today. So the temptation to skip this command. If the disk is going to be filled and will be overwritten mostly anyway, because a full system backup is going to follow immediately as the next step after creating and mounting the encrypted disk device then the need to do this is difficult to understand.

What are the security risks of leaving this command out?

Does disclosure of usage pattern simply means that someone getting hold of the disk might be able to figure out how much space of the disk is occupied by my encrypted data?

Or might some resourceful secret agency be able to discover more private information?

I recently read about a talk by Corey Kallenberg and Xeno Kovah given at the CanSecWest-conference which describes how the firmware of a server mainboard can be reprogrammed to include malicious software. This has left me really worried! I'm now seeking for a method how to make sure that some given hardware has not been tempered with in such regard. How can I do this?

I have a licensed copy of MicroSoft Windows 7 professional installed and running as guest on my Linux server running qemu-kvm. This works just fine.

But I was unable to figure out how to Cut'n'paste text selections from a window of the Win7 VM into X11 or vice versa.

Is this possible? How?

How can I configure exim header rewriting to take care of forgotten Reply-To: headers in emails leaving our company?

We want to have certain Reply-To: headers added to all official emails leaving the company. E.g. Reply-To: [email protected], Reply-To: [email protected], ...

A single person might get sick, take a day off, go on a vacation or something like this. The addresses mentioned as example Reply-To: addresses above are aliases which distribute the incoming replies from clients to a group of colleagues in order to make sure that somebody will read and act on them in a timely manner.

I've studied the filter section of the exim documentation but I still feel unable to apply this to my particular problem. A working example would be fine.

Our mail server is debian based and uses the so called split configuration scheme if this matters.