The minix set is now divided into minix-base, minix-comp, minix-games,
minix-kernel, minix-man and minix-tests.
This allows massive space savings on the installlation CD because only
the base system used for installation is stored uncompressed. Also, it
makes the system more modular.
Change-Id: Ic8d168b4c3112204013170f07245aef98aaa51e7
The CD now boots directly from the ISO 9660 filesystem instead of using
MBR partitioning with Minix file systems. This saves some space on the
CD and reduces memory requirements by some unknown amount as the root
ramdisk is completely eliminated.
The x86 hard drive image creation is also rewritten in the same
fashion.
The setup is modified to be more NetBSD-like (unpacking sets
tarballs instead of blindly copying the CD contents). Splitting MINIX
into sets is done in another commit due to it being a nightmare to
rebase.
Since MINIX lacks union mounts for now, a bunch of ramdisks are
generated at run-time to make parts of the filesystem writeable for the
CD. This solution isn't ideal, but it's enough for an installation CD.
Change-Id: Icbd9cca4dafebf7b42c345b107a17679a622d5cd
This commits adds a basic infrastructure to support Address Space
Randomization (ASR). In a nutshell, using the already imported ASR
LLVM pass, multiple versions can be generated for the same system
service, each with a randomized, different address space layout.
Combined with the magic instrumentation for state transfer, a system
service can be live updated into another ASR-randomized version at
runtime, thus providing live rerandomization.
Since MINIX3 is not yet capable of running LLVM linker passes, the
ASR-randomized service binaries have to be pregenerated during
crosscompilation. These pregenerated binaries can then be cycled
through at runtime. This patch provides the basic proof-of-concept
infrastructure for both these parts.
In order to support pregeneration, the clientctl host script has
been extended with a "buildasr" command. It is to be used after
building the entire system with bitcode and magic support, and will
produce a given number of ASR-randomized versions of all system
services. These services are placed in /usr/service/asr in the
image that is generated as final step by the "buildasr" command.
In order to support runtime updating, a new update_asr(8) command
has been added to MINIX3. This command attempts to live-update the
running system services into their next ASR-randomized versions.
For now, this command is not run automatically, and thus must be
invoked manually.
Technical notes:
- For various reasons, magic instrumentation is x86-only for now,
and ASR functionality is therefore to be used on x86 only as well.
- The ASR-randomized binaries are placed in numbered subdirectories
so as not to have to change their actual program names, which are
assumed to be static in various places (system.conf, procfs).
- The root partition is typically too small to contain all the
produced binaries, which is why we introduce /usr/service. There
is a symlink from /service/asr to /usr/service/asr for no other
reason than to let userland continue to assume that all services
are reachable through /service.
- The ASR count field (r_asr_count/ASRcount) maintained by RS is not
used within RS in any way; it is only passed through procfs to
userland in order to allow update_asr(8) to keep track of which
version is currently loaded without having to maintain own state.
- Ideally, pre-instrumentation linking of a service would remove all
its randomized versions. Currently, the user is assumed not to
perform ASR instrumentation and then recompile system services
without performing ASR instrumentation again, as the randomized
binaries included in the image would then be stale. This aspect
has to be improved later.
- Various other issues are flagged in the comments of the various
parts of this patch.
Change-Id: I093ad57f31c18305591f64b2d491272288aa0937
Make disk image size sufficient for LLVM bitcode build with symbols.
Edited by David van Moolenbroek to do this only when -b is given.
Change-Id: I3bde164756c477b4af5ed9435ca03da3b186cf7e
- Fix a bug in clientctl which tried to test for kvm. This simply
remove this faulty test as the kvm command has been deprecated by the
QEMU project for a couple of years now.
- Specify by default 256M of RAM as this is the minimal amount required
for the whole-OS live update test to succeed.
- Update the default command printed out at the end of the x86_hdimage
script to be more generic, less focused on one use-case.
Change-Id: Ic555d50a3a1471f7d35cc7fd369f2292add6ac39
This patch adds support for Unix98 pseudo terminals, that is,
posix_openpt(3), grantpt(3), unlockpt(3), /dev/ptmx, and /dev/pts/.
The latter is implemented with a new pseudo file system, PTYFS.
In effect, this patch adds secure support for unprivileged pseudo
terminal allocation, allowing programs such as tmux(1) to be used by
non-root users as well. Test77 has been extended with new tests, and
no longer needs to run as root.
The new functionality is optional. To revert to the old behavior,
remove the "ptyfs" entry from /etc/fstab.
Technical nodes:
o The reason for not implementing the NetBSD /dev/ptm approach is that
implementing the corresponding ioctl (TIOCPTMGET) would require
adding a number of extremely hairy exceptions to VFS, including the
PTY driver having to create new file descriptors for its own device
nodes.
o PTYFS is required for Unix98 PTYs in order to avoid that the PTY
driver has to be aware of old-style PTY naming schemes and even has
to call chmod(2) on a disk-backed file system. PTY cannot be its
own PTYFS since a character driver may currently not also be a file
system. However, PTYFS may be subsumed into a DEVFS in the future.
o The Unix98 PTY behavior differs somewhat from NetBSD's, in that
slave nodes are created on ptyfs only upon the first call to
grantpt(3). This approach obviates the need to revoke access as
part of the grantpt(3) call.
o Shutting down PTY may leave slave nodes on PTYFS, but once PTY is
restarted, these leftover slave nodes will be removed before they
create a security risk. Unmounting PTYFS will make existing PTY
slaves permanently unavailable, and absence of PTYFS will block
allocation of new Unix98 PTYs until PTYFS is (re)mounted.
Change-Id: I822b43ba32707c8815fd0f7d5bb7a438f51421c1
- Removed an "export CPPFLAGS=${FLAG}" which prevented proper settings
from the environment to be passed to the build step.
- Re-arranged variable settings at the top, so that we don't need
to evaluate the argument to vfat mkfs command anymore in
arm_sdimage.sh
- "Merged" both script for easier comparison in the future.
Change-Id: Id59f902e4eaeb7f268d5051789462f14421a114a
The syntax of the stat(1) command varies between Linux and FreeBSD.
This prevented `x86_hdimage.sh -i` from succeeding on FreeBSD 10.0.
The fix is to use the NetBSD stat from the tooldir for all systems.
Change-Id: I121e5fd36b0d4a944ba0109cf58095ab7d150847
Remove the usage of sloppy files list in the build scripts to
get early errors when files are added.
Change-Id: Id89c1391da675c76d7511a973f7f2dcda8befbb2
MKGCCCMDS=yes and MKBINUTILS=yes where added on the build command line
while they should have been left to the developer's discretion.
To build and install binutils and gcc do the following:
$ BUILDVARS='-V MKBINUTILS=yes -V MKGCC=yes -V MKGCCCMDS=yes' \
./releasetools/arm_sdimage.sh
or
$ BUILDVARS='-V MKBINUTILS=yes -V MKGCC=yes -V MKGCCCMDS=yes' \
./releasetools/x86_hdimage.sh
Change-Id: Icb46a3422f527747768fa107d14fc19ff3ac0a63
* Remove static proto.dev
* Update releasetools/*image.sh not to use proto.dev, as well as
minor comments cleanup
* Add TOOL_TOPROTO
Change-Id: If7dc16d4ebb3b0c4e859786fad25d4af000c999f
. build writeisofs as a native tool too for it
. also mkfs.mfs: make missing file in proto nonlethal
. make setup script a little more self-sufficient
. hdboot: use INSTALL_FILE instead of INSTALL so that the
results get added to the METALOG
Change-Id: Id233e4c861f81046bf6c4be0510b8a3bf39ff9be
A script that creates a HD image ready to be booted by an x86
emulator, ready to work in a crossbuild environment.
It's really just for qemu/kvm as there's no boot code in
the MBR and no bootloader installed so we rely on the in-kvm
multiboot implementation for now. This is very convenient for
passing args too.
To minimize reliance on external tools, we use the Minix
'partition' utility to write the partition table of the HD
image, which therefore has to be compiled natively.
. new script releasetools/x86_hdimage.sh
. natively compile minix 'partition' utility
. make <machine/partition.h> 64-bit safe for it
Change-Id: If645b4691536752271e0b8a8ed59a34f248dace4
