Generally build env (rpmbuild, dpkg-buildpackage) provide sane and
useful defaults.
Fixes hardening-no-relro lintian warning.
QubesOS/qubes-issues#1416
By default dracut set 600 mode. While it isn't a problem for starting a
VM (which is done as root), it is a problem for creating standalone VM,
which has it's own copy of kernel directory.
New version of sfdisk have different syntax for other units (suffixes
beside the numbers, instead of global --unit). The only common unit is
sector, so use that.
FixesQubesOS/qubes-issues#1427
Commit https://github.com/QubesOS/qubes-linux-utils/commit/c1d42f1 --
"qfile-unpacker: do not call fdatasync() at each file" fixing
QubesOS/qubes-issues#1257 -- increased the chance of data loss with
qvm-move-to-vm: Say it nominally succeeds, and *deletes* the files from
the source VM. Soon after, the destination VM or the system could crash,
or an external drive hosting ~/QubesIncoming/srcVM could get unplugged
by accident, all before the data had really been persisted to disk.
But reverting the commit (ignoring the performance issue) wouldn't
completely solve this:
"Calling fsync() does not necessarily ensure that the entry in the
directory containing the file has also reached disk. For that an
explicit fsync() on a file descriptor for the directory is also
needed." - fsync(2)
It gets even worse for "slow symlinks" (whose target is too long to be
stored directly in the inode metadata), apparently they can't be synced
at all individually.
So instead, just call syncfs() once after everything has been unpacked:
+ Should prevent all data loss (if fs and disk are well behaved)
+ Allows caching and reordering -> no slowdown with many small files
- Blocks until any unrelated writes on the filesystem finish :\
The filesystem hosting ~/QubesIncoming/srcVM/ needs to support O_TMPFILE
too, in addition to the kernel. If it doesn't, take the use_tmpfile = 0
fallback.
Theoretically it shouldn't be a problem, because module isn't installed
in initramfs by default (in dom0), but since such error would be fatal
to dom0 (will prevent it from booting), add a safety check for it.
Probably it will be required when (if) we migrate dom0 to Debian
This package is responsible for kernel modules and initramfs additions
needed in Qubes VM. When installed, it is possible to switch the VM to
use PV Grub and load the kernel from inside of VM. This greatly ease
installing custom kernel modules.
Changes:
- make qubes_cow_setup.sh working with both dracut and initramfs-tools
- add initramfs-tools configuration/scripts (including
qubes_cow_setup.sh)
- modify DESTDIR to handle multiple binary packages out of single
source
QubesOS/qubes-issues#1354
When udev is installed (and scheduled to be started), but not running
yet, plain dmsetup will deadlock on waiting for udev. Since we call
`dmsetup mknodes dmroot` anyway
QubesOS/qubes-issues#1354
The module is required by gui-agent, so make sure it will be actually
installed. This would also install the module in dom0 (when
qubes-kernel-vm-support is installed there), but this this is harmless.
QubesOS/qubes-issues#1354
This makes is possible to modify /lib/modules content - especially
install other kernel packages, without unmounting the whole
/lib/modules. Since dom0-provided modules will no longer conflict with
VM kernel packages (assuming kernel versions are different), there is no
need for qubes-kernel-vm-placeholder anymore.
Having only one subdirectory of /lib/modules mounted is somehow tricky,
because:
1. Directory name isn't always the same - it depends on kernel version.
This means that mountpoint must be created dynamically (so $NEWROOT must
be mounted in R/W for a moment).
2. There is one-command way to mount only a subdirectory of some
filesystem. So use a trick: mount it in some temporary directory, get
interesting subdir with `mount --bind`, then unmount temporary
directory.
QubesOS/qubes-issues#1354
When PV Grub will be used, VM initramfs should not contain /lib/modules
mounting code, as the VM root.img will already contains kernel modules.
Make it possible by splitting the module.
QubesOS/qubes-issues#1354
This is counterpart of 5774c78 "qfile-agent: move data handling code to
libqubes-rpc-filecopy" in core-agent-linux. The main purpose is to
easily reuse the code in dom0 qvm-copy-to-vm tool.
QubesOS/qubes-issues#1324
At the moment, Xen has a 16TB limit on x86, so this has no practical
impact, aside for silencing compiler truncation warnings.
Also, the rest of the GUI/u2mfn code and protocol would need to be
expanded to use 64-bit mfns for Qubes to actually work there.
It is required to prevent deadlocks in single-threaded select-based IO
programs (namely: qrexec). POSIX API doesn't support checking how much
can be written to pipe/socket without blocking, so to prevent blocking
application must use O_NONBLOCK mode, and somehow deal with non-written
data (buffer it).
QubesOS/qubes-issues#1347
* origin/pr/1:
use 64-bit integers for memory sizes to support > 2 TB RAM
Report Xen balloon current size instead of Linux total memory
FixesQubesOS/qubes-issues#1136
POSIX requires that a read(2) which can be proved to occur after a
write() has returned returns the new data.
We want here only that other processes in the same VM will see the
file either fully written, or not see it at all. So ensuring that
linkat(2) is called after write is completed should be enough.
FixesQubesOS/qubes-issues#1257
At the moment, Xen has a 16TB limit on x86, so this has no practical
impact, aside for silencing compiler truncation warnings.
Also, the rest of the GUI/u2mfn code and protocol would need to be
expanded to use 64-bit mfns for Qubes to actually work there.
* origin/pr/1:
archlinux: ensure /usr/sbin is not use to follow archlinux packaging guidelines
archlinux: update to match new dependancies and archlinux /usr/lib guidelines
Since migration to QubesDB, it isn't needed anymore (QubesDB have no
problem with concurrent writes, as transactions are not supported).
This should speedup system startup.
