diff --git a/.wordlist.txt b/.wordlist.txt index 5eda687586..ee10db6454 100644 --- a/.wordlist.txt +++ b/.wordlist.txt @@ -3705,7 +3705,6 @@ HMMER ILP IoC Jython -Khrustalev LCP Maranget Minimap @@ -3872,4 +3871,4 @@ upscalers upscales upscaling vl -webbot \ No newline at end of file +webbot diff --git a/content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/_index.md b/content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/_index.md deleted file mode 100644 index bd90c7923a..0000000000 --- a/content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/_index.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: Build and test a custom Linux image on an FVP - -draft: true -cascade: - draft: true - -minutes_to_complete: 60 - -who_is_this_for: > - This is an advanced topic for developers who wish to run a Linux system (optionally using a custom kernel and - a C library) on an Arm Fixed Virtual Platform (FVP) model. This learning path might be useful to follow if you want to test patches for the Linux kernel or Glibc prior to having hardware available. - -learning_objectives: - - Build the Linux kernel. - - Install the Shrinkwrap tool, build firmware for the FVP and run it. - - Configure and boot a Linux system on the FVP. - - Configure guest OS and run Glibc tests. - - Build Glibc and run tests on the system running on the FVP. - -prerequisites: - - An AArch64 or x86_64 Linux machine. The instructions in this Learning Path have been tested on AArch64 Linux machine running Ubuntu 24.04. - -author: Yury Khrustalev - -### Tags -skilllevels: Advanced -subjects: Performance and Architecture -armips: - - AArch64 -tools_software_languages: - - Glibc - - Shrinkwrap - - Fast Models -operatingsystems: - - Linux - -### FIXED, DO NOT MODIFY -# ================================================================================ -weight: 1 # _index.md always has weight of 1 to order correctly -layout: "learningpathall" # All files under learning paths have this same wrapper -learning_path_main_page: "yes" # This should be surfaced when looking for related content. Only set for _index.md of learning path content. ---- diff --git a/content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/conventions.md b/content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/conventions.md deleted file mode 100644 index 8392333f7a..0000000000 --- a/content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/conventions.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: Development environment -weight: 2 - -### FIXED, DO NOT MODIFY -layout: learningpathall ---- - -In this section, you will install packages and review the directory structure used throughout the learning path. - -## Install dependencies - -Run the following commands to make sure the necessary dependencies are installed on your host machine: - -```bash -sudo apt update && sudo apt install -y \ - git make bash \ - flex bison build-essential libssl-dev bc libelf-dev libncurses-dev \ - python3 python3-pip python-is-python3 python3-venv wget xz-utils coreutils -``` - -Install GCC to cross compile Linux applications: -```bash -sudo apt install gcc-aarch64-linux-gnu -y -``` - -{{% notice Note%}} -The GCC cross toolchain installation directory contains everything a cross toolchain would need, for example, the path to the `gcc` tool would be `/usr/bin/aarch64-linux-gnu-gcc`. -{{% /notice %}} - -Install Docker, refer to the [Docker install guide](/install-guides/docker/). - - -## Directory Structure - -In the following sections you will checkout sources and build various tools on your Linux host machine. Before you begin, lets look at the directory structure of where you will build the different parts of software stack needed to run this learning path. - -Table 1. Directory layout - -| Path | Description | -|--------------------------------------|---------------------------------------| -| `$HOME` | Home directory of your host non-root user | -| `$HOME/workspace` | Workspace directory | -| `$HOME/workspace/linux` | Folder with the Linux kernel sources | -| `$HOME/workspace/linux-headers` | Directory for installing kernel headers | -| `$HOME/workspace/linux-build` | Folder for the Linux kernel build output | -| `$HOME/workspace/glibc` | Folder for the Glibc sources | -| `$HOME/workspace/glibc-build` | Directory for the Glibc build output | - diff --git a/content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/fvp.md b/content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/fvp.md deleted file mode 100644 index 0cfd00e2ac..0000000000 --- a/content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/fvp.md +++ /dev/null @@ -1,175 +0,0 @@ ---- -title: Boot Linux on the FVP -weight: 5 - -### FIXED, DO NOT MODIFY -layout: learningpathall ---- - -## Introduction - -During this step, you will set up everything for the FVP to run and then boot the Linux system -using the kernel and the root file system that you prepared earlier in the earlier sections. - -Arm [Fixed Virtual Platform (FVP)](https://developer.arm.com/downloads/-/arm-ecosystem-fvps) is a model that allows you to access functionality -of Armv8.x or v9.x hardware. You will use the Armv-A Base Rev C Architecture Envelope Model (AEM). - -In addition to the model itself, you also need the device tree and the firmware. To simplify -building these components, you will use a tool called [Shrinkwrap](https://gitlab.arm.com/tooling/shrinkwrap). - -This tool comes with a detailed [user guide](https://shrinkwrap.docs.arm.com/en/latest/) that covers all of its features and -configuration options. You will also leverage this tool to run and boot the images you prepared on the FVP. - -Shrinkwrap can be used in a few different ways. One of the ways is to use a Docker container to facilitate the building of the firmware and -running the FVP. This helps avoid installing all the dependencies on your host system. - -## Install Shrinkwrap - -First, install prerequisites in a Python virtual environment using Python 3.x: - -```bash -cd $HOME -python -m venv $HOME/workspace/venv -source $HOME/workspace/venv/bin/activate -pip install -U pip setuptools wheel -pip install pyyaml termcolor tuxmake -``` - -Shrinkwrap can be used directly from the source, which can be checked out from its Git -repository. Run this command in the workspace directory: - -```bash -git clone https://git.gitlab.arm.com/tooling/shrinkwrap.git -export PATH=${PATH}:${HOME}/workspace/shrinkwrap/shrinkwrap -``` - -Putting Shrinkwrap's main executable on your `PATH` is all you need to install the tool. -To check that it works, ensure that the Python virtual environment we created earlier -is activated, then run this command: - -```bash -shrinkwrap --version -``` - -You should see a version printed. - -```output -shrinkwrap v1.0.0 -``` - -## Build firmware for the FVP - -Now, you can use the Shrinkwrap tool to build the firmware, the third essential ingredient in our -setup. The following step needs to be done once although you will need to repeat it if you -want to rebuild the firmware: - -```bash -shrinkwrap build --overlay=arch/v9.4.yaml ns-edk2.yaml -``` - -This command uses the `arch/v9.4.yaml` config that enables Armv9.4 hardware features. -This config is included with the Shrinkwrap installation. We also use the `ns-edk2.yaml` -config. This configuration file is also a part of the Shrinkwrap tool. It defines the -settings for building and running the firmware using EDK2 on Arm FVPs. The build -process takes some time. During this step, Shrinkwrap downloads the required Docker -image and starts a container to clone all the required firmware repositories and build -the components including the device tree for the FVP. - -## Overlay config - -At this point, we have everything required to boot our system. Shrinkwrap uses so called overlay -configuration files. The following file instructs Shrinkwrap to connect all the pieces together -and locate the kernel image, and rootfs. It can also be used to tweak any of the FVP -parameters. Create a file in $HOME/workspace directory called `aarch64.yaml` using a text editor of your choice. Copy the contents shown below into the file: - -```yaml -run: - rtvars: - ROOTFS: - value: ~/workspace/rootfs.img - CMDLINE: - value: ip=dhcp kpti=off root=/dev/vda2 console=ttyAMA0 - KERNEL: - value: ~/workspace/linux-build/arch/arm64/boot/Image - params: - -C bp.hostbridge.userNetworking: 1 - -C bp.hostbridge.userNetPorts: 8022=22,8123=8123 - -C bp.smsc_91c111.enabled: 1 - -C bp.virtio_net.enabled: 0 - -C cluster0.NUM_CORES: 1 - -C cluster1.NUM_CORES: 0 - -C pctl.CPU-affinities: 0.0.0.0 -``` - -The most important parts in this configuration file are: - - * Paths to the rootfs image and the kernel image. - * The kernel command line, which contains `root=/dev/vda2`, specifying where to locate - the filesystem to be mounted at `/`. - * The port mapping `8022=22`, which is used for SSH access into the guest system. - You can add more ports as needed. - -The FVP has many parameters that can be tweaked in this config by adding a `-C param: value` -line to the `params` section. Refer to the [Fast Models Fixed Virtual Platforms Reference Guide](https://developer.arm.com/documentation/100966/latest/Getting-Started-with-Fixed-Virtual-Platforms/Configuring-the-model). -for more details. - -## Run FVP with Shrinkwrap - -To run the FVP using Docker, execute the following command: - -```bash -shrinkwrap run ns-edk2.yaml --overlay $HOME/workspace/aarch64.yaml -``` - -At first, Shrinkwrap starts a Docker container and runs the FVP in it. At the beginning -of the output, you may see a line containing the IP address that you need to use for SSH -access into the guest system: - -``` -Press '^]' to quit shrinkwrap. -All other keys are passed through. -Environment ip address: 172.17.0.2. -``` - -It also tells you how to stop the FVP execution: press `Ctrl+]` (more on this later). - -Booting the Linux on the FVP takes some time. Look out for the system log messages about -growing the root partition to utilize the empty disk space we created earlier. - -``` -=> Growing root partition -CHANGED: partition=2 ... old: size=1316864 ... new: size=5511135 -``` - -After a couple of minutes, you should be able to SSH in a different terminal into the -guest OS running on the FVP using the IP address reported by the Shrinkwrap tool and the -port number specified earlier in our overlay config: - -```bash -ssh root@172.17.0.2 -p 8022 -``` - -The default password is `voidlinux`. - -When you have logged in, check the properties of your guest system, for example: - -```bash -uname -a -cat /proc/cpuinfo -``` - -## Powering down - -You can always press `Ctrl+]` to stop Shrinkwrap in the terminal where Shrinkwrap is -running. However, this abruptly aborts execution of the FVP. This may leave the filesystem -in your rootfs image, used by the guest system, in a broken state, resulting in errors -during the next boot. To avoid this, it is advisable to shut down the guest system gracefully -from the root console of your guest system, for example: - -```bash -ssh root@172.17.0.2 -p 8022 poweroff -``` - -Continue to the next section for additional setup. The remaining steps are optional but it -helps prepare our guest system for running Glibc tests and doing other complex tasks. - diff --git a/content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/glibc.md b/content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/glibc.md deleted file mode 100644 index 5491039adf..0000000000 --- a/content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/glibc.md +++ /dev/null @@ -1,205 +0,0 @@ ---- -title: Glibc tests on the FVP -weight: 7 - -### FIXED, DO NOT MODIFY -layout: learningpathall ---- - -## Prepare kernel headers - -For this step you need the GCC cross-toolchain for the `aarch64-linux-gnu` target. -You can use the same toolchain as we used for building the kernel. - -Since we are going to use our Glibc on a system running a specific version of the kernel, -we should build the Glibc using the kernel headers of the same version. The Glibc build -scripts automatically pick up your host system's kernel headers unless configured to use -headers from a specific directory. To ensure that we use correct headers for the kernel, -we need to install them from source. - -We presume that the kernel source is in the `linux` subfolder, and we will install the -headers in the `linux-headers` subfolder. First, you have to set a few environment variables. -To do this, run the following commands: - -```bash -cd $HOME/workspace -export ARCH=arm64 -make -C linux headers_install INSTALL_HDR_PATH=$(pwd)/linux-headers -``` - -{{% notice %}} -If you are running an x86_64 Linux host, the `CROSS_COMPILE` flag needs to be set. Example: export CROSS_COMPILE=aarch64-none-linux-gnu- -{{% /notice %}} - -You should see kernel headers in the `$HOME/workspace/linux-headers/include` folder now. -We will use this path during the next step. - -## Get Glibc sources and build for AArch64 target - -Clone the Glibc Git repository: - -```bash -cd $HOME/workspace -git clone git://sourceware.org/git/glibc.git -``` - -To make the following command simpler, let's introduce the `CROSS` variable (notice the hyphen -at the end): - -```bash -export CROSS=/usr/bin/aarch64-linux-gnu- -``` - -Now configure the cross-build for the `aarch64-linux-gnu` target: - -```bash -mkdir glibc-build -cd glibc-build - -LC_ALL=C BUILD_CC=gcc \ -CC=${CROSS}gcc CXX=${CROSS}g++ \ -NM=${CROSS}nm READELF=${CROSS}readelf \ -AR=${CROSS}ar GPROF=${CROSS}gprof \ -OBJDUMP=${CROSS}objdump OBJCOPY=${CROSS}objcopy \ -RANLIB=${CROSS}ranlib \ -../glibc/configure --prefix=/usr \ - --host=aarch64-linux-gnu \ - --enable-hardcoded-path-in-tests \ - --with-headers=$HOME/workspace/linux-headers/include -``` - -Notice the path to the kernel headers in the last parameter in the `configure` command and -also the `include` at the end of it. - -Finally, run the build: - -```bash -make -j$(nproc) -``` - -## Run tests on FVP - -As you are using an AArch64 host, you can run Glibc tests both on your host and on the FVP -from the same build tree. Before we run some tests, we need to make sure that we have two -important prerequisites in place. - -First, we need to copy the target libraries from your toolchain's sysroot to ensure that -the tests are using them rather than your OS's libraries. Run the following commands in the -`glibc-build` folder: - -```bash -cp $(${CROSS}gcc -print-file-name=libstdc++.so.6) . -cp $(${CROSS}gcc -print-file-name=libgcc_s.so.1) . -``` - -Next, we will build the testroot. A Glibc testroot is a collection of files that resembles -an installation of the Glibc that we have just built. It allows us to create the correct -environment for the tests without actually installing the Glibc. Tun the following command -int the Glibc build folder: - -```bash -make $(pwd)/testroot.pristine/install.stamp -``` - -Now we can run the tests. Let's start with a single test to understand the structure of the -command. Ensure the following: - - * The FVP is running - * The guest system accepts SSH connections - * The Glibc source and build folders are available in the guest system via the NFS share - * The paths to these folders on the host and the guest systems are the same - -We should set the `TIMEOUTFACTOR` environment variable to extend the timeout for some of the -tests that may fail just because execution takes longer than usual. This is expected on an -emulated platform such as an FVP: - -```bash -export TIMEOUTFACTOR=10 -``` - -If you see any timeouts when running tests on the FVP, increase this value. - -To tell the Glibc test system to execute the tests on a remote system (in our case this -means on the guest system running on the FVP), we will use the test wrapper script that -is part of the Glibc sources: `scripts/cross-test-ssh.sh`. By default it uses `ssh` as a -command to start an SSH connection, but it is possible to override it via the `--ssh` option. -However, this option only accepts single word values. To avoid complexities related to -using `sh` instead of `bash` and Bash aliases not being expanded in non-interactive shells, -the easiest way to proceed is as follows: - - * Create a simple shell script and save it using file name `ussh`: - -```bash -#!/usr/bin/env bash -dbclient -p 8022 "$@" -``` - - Make it executable using the `chmod u+x` command, and save this script in one of the directories in your `PATH`, for example `/usr/bin`: - -```bash -chmod u+x ussh && sudo mv ussh /usr/bin/ussh -``` - -To run a single test, use this command: - -```bash -make test t=misc/tst-aarch64-pkey \ - test-wrapper="/home/user/glibc/scripts/cross-test-ssh.sh --ssh ussh fvp" -``` - -Let's see what we have here. The `test` target will build (or rebuild) one test and all -its dependencies and then run this test. This target requires one parameter, `t`, with the -name of the test that we need to run. The Glibc tests are grouped into folders, and a test name -would normally look like `misc/tst-aarch64-pkey` where `misc` is the name of the group and -`tst-aarch64-pkey` is the name of the test in this group. - -When we use SSH test wrapper to run a test on the FVP we need to supply its absolute path along -with any of the script's arguments as a value of the `test-wrapper` make parameter. Here, -we use the `--ssh` option of the wrapper script to tell it to use the `ussh` command instead -of `ssh` and we use `fvp` as the hostname of the remote system. All the setup that we have -done in the previous steps makes using this wrapper script easier. - -To run the same test on your AArch64 host rather than on the FVP, just omit the `test-wrapper=...` -parameter. - -With this particular test, you may see that on your AArch64 host, it reports that it is not -supported: - -``` -UNSUPPORTED: misc/tst-aarch64-pkey -original exit status 77 -``` - -And on your FVP with the Linux kernel 6.13 or newer, you should get: - -``` -PASS: misc/tst-aarch64-pkey -original exit status 0 -``` - -To run a group of tests, use the following command with the `check` target: - -```bash -make check -C $HOME/workspace/glibc/argp \ - objdir=`pwd` \ - test-wrapper="$HOME/workspace/glibc/scripts/cross-test-ssh.sh --ssh ussh fvp" -``` - -In this instance, we are building and running tests from the `argp` folder. We use the `-C` -option of `make` to point it to the right directory, and we also supply a path to the -build folder via the `objdir` parameter (which should be the current directory since we are -running this command from within the build folder). The `test-wrapper` part remains the same. - -To run all the tests, simply do: - -```bash -make check \ - test-wrapper="$HOME/workspace/glibc/scripts/cross-test-ssh.sh --ssh ussh fvp" -``` - -Note that this will take a considerable amount of time. Also, notice that we are not using -a parallel `make` command for running tests on the FVP. The reason is that the Fast Models -simulation code runs primarily on a single thread, and running tests in parallel would not -speed up the execution. - -By reaching the end of this learning path, you have completed setting up a Linux system on the FVP, and used it to run Glibc tests. diff --git a/content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/kernel.md b/content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/kernel.md deleted file mode 100644 index 9f2f57c253..0000000000 --- a/content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/kernel.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: Build Linux kernel -weight: 3 - -### FIXED, DO NOT MODIFY -layout: learningpathall ---- - -## Obtain kernel source - -The Linux kernel image is the first essential components that you need to build. You are going to build it from source. - -There are various ways to obtain the sources for a particular version of the Linux kernel that you want to use. As an example, lets checkout a stable -version from the mainline repository: - -```bash -cd $HOME/workspace -git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git -pushd linux -git checkout v6.13 -b release/6.13 -popd -``` - -Note that at the time when you are reading this, there might be a newer version -available. - -Using a stable kernel version is a good starting point. When everything is up -and running, you can switch to the version of the kernel that you are actually -interested in running. - -## Configure and build kernel - -Before moving on, export some environment variables, pointing out some key directories and options. -All the build output, including the binary that you intend to use later, will be put in -the `linux-build` subfolder. Run the following commands in the workspace directory: - - -```bash -export KBUILD_OUTPUT="$(pwd)/linux-build" -export ARCH=arm64 -```` - -{{% notice %}} -If you are running an x86_64 host, you will need to set the `CROSS_COMPILE` environment variable to point to your GCC cross compile toolchain. For example: export CROSS_COMPILE=aarch64-none-linux-gnu- -{{% /notice %}} - -Next, build the kernel image: -```bash -make -C linux mrproper -make -C linux defconfig -make -C linux Image -j $(nproc) -``` - -The `mrproper` target is used to clean the build folder. It will also create -this folder if it doesn't exist. The `defconfig` target generates the default -configuration for the selected architecture, `arm64`. At this point, you may -change this configuration if necessary, for example, if the feature that you -are interested in is not enabled by default. To do this, you would usually run -`make menuconfig` in the `linux-build` folder. Finally, building the `Image` -target will produce the binary that we need. - -When the build completes, check that the kernel image binary is present: - -```bash -ls linux-build/arch/arm64/boot/Image -``` - diff --git a/content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/rootfs.md b/content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/rootfs.md deleted file mode 100644 index cf13a1a021..0000000000 --- a/content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/rootfs.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: Build the Root file system -weight: 4 - -### FIXED, DO NOT MODIFY -layout: learningpathall ---- - -## Download and unpack root file system - -The root file system (or rootfs for short) is the second essential component -that you will need. The root file system is a collection of files that are essential -for a Linux system to function. Usually, it also includes various tools that -make using your system more convenient. - -Since you are providing your own kernel, there isn't much that is required from a -rootfs. All you need is for it to be built for the AArch64 target and contain -the tools that you require. - -To speed things up for this learning path, you will use a readily available rootfs -for the [Void Linux](https://voidlinux.org/) distro. There are other options for obtaining a working -root file system, but the rest of this learning path assumes that you are using -the Void Linux distribution. - -Download the image: - -```bash -cd $HOME/workspace -wget https://repo-default.voidlinux.org/live/20250202/void-rpi-aarch64-20250202.img.xz -``` - -Note that at the time when you are reading this, there might be a newer version available. - -Let's unpack and resize the image. The added size determines how much free disk space -you will have in your guest system: - -```bash -unxz --keep void-rpi-aarch64-20250202.img.xz -mv void-rpi-aarch64-20250202.img rootfs.img -truncate -s +2G rootfs.img -``` - -Here you added 2 GiB of free space. Of course, the file system in this image is not actually -resized at this point. Void Linux will be able to do it automatically during the first -boot. - -Note that when we run our system, the rootfs image file will be modified. If something -goes wrong, the image might be corrupted, and you might not be able to boot from it again. -That's why it's recommended to create a backup copy after the initial setup. - diff --git a/content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/setup.md b/content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/setup.md deleted file mode 100644 index 9fa2ca3c3d..0000000000 --- a/content/learning-paths/servers-and-cloud-computing/glibc-linux-fvp/setup.md +++ /dev/null @@ -1,292 +0,0 @@ ---- -title: Guest and host setup -weight: 6 - -### FIXED, DO NOT MODIFY -layout: learningpathall ---- - -In this section, you will configure the guest system to make it easier running more complex tasks. - -## Void Linux basics - -For a detailed guide on Void Linux, refer to the [documentation](https://docs.voidlinux.org/). - -Commands in this section are executed on the guest system. - -It is recommended to use Bash as your default shell on the guest system. To change -the default shell for a user, run this command: - -```bash -chsh -s /bin/bash root -``` - -You install packages using `xbps-install`. The `-S` option updates the repository cache. You need to run this once before installing additional packages. For example, install `vim` with the following commands: - -```bash -xbps-install -y -S -xbps-install -y vim -``` - -You can add a bit of automation to speed up configuring your system from scratch: - -```bash -required=(nfs-utils sv-netmount rpcbind) -optional=(vim binutils make strace python3) -for p in "${required[@]}" "${optional[@]}"; do - xbps-query -l | grep -w ${p} > /dev/null || { - xbps-install -y ${p} - } -done -``` - -Installing the required packages is important for the following steps. Choose -optional packages according to your use case. You can always install or remove -packages later. - -The rootfs image that we are using is limited in size, and it might be useful -to free up some space. Since we use our own kernel and firmware, we can safely -delete the following packages: - -```bash -unused=(rpi-firmware rpi-kernel) -for p in "${unused[@]}"; do - test -f "/etc/xbps.d/disable-${p}.conf" || { - echo "ignorepkg=${p}" > "/etc/xbps.d/disable-${p}.conf" - xbps-remove -y ${p} - } -done -``` - -Here, you also mask these packages to prevent them from being installed automatically -during system updates, saving time in the process. - -The last two code snippets are written so that you can re-run them multiple times. -If a change has already been applied, it will be skipped. - -Optionally, to update your guest OS, run: - -```bash -xbps-install -y -Su -``` - -## Lightweight SSH server - -Commands in this section are executed on the guest system. - -Our main interaction with the guest system will be via SSH. Running software on an -FVP is slower than on real hardware, so we want to reduce the overhead. One way to -do this is by replacing the preinstalled OpenSSH server with a more lightweight -alternative, such as [Dropbear](https://matt.ucc.asn.au/dropbear/dropbear.html). - -First, install Dropbear and enable corresponding service: - -```bash -xbps-query -l | grep -w dropbear > /dev/null || { - xbps-install -y dropbear -} - -test -h /var/service/dropbear || { - ln -s /etc/sv/dropbear /var/service/ -} -``` - -Now, disable the OpenSSH server: - -```bash -test -h /var/service/sshd && { - sv stop sshd - rm -vf /var/service/sshd -} -``` - -Finally, create a simple service that prints a message to the system log when the guest -system is ready for incoming SSH connections: - -```bash -test -h /var/service/hello || { - mkdir -p /etc/sv/hello - cat < /etc/sv/hello/run -#!/bin/bash -sv status dropbear || exit 1 -. /etc/runit/functions -msg "SSH service is ready" -sv stop hello -EOF - chmod a+x /etc/sv/hello/run - ln -s /etc/sv/hello /var/service/ -} -``` - -During the next boot, you should see this message in the system log. You might also -experience an improvement in SSH connection speed: - -``` -=> Initialization complete, running stage 2... -... -=> SSH service is ready - -``` - -## Configure SSH on host - -Commands in this section should be run on the host system. - -Using a password for SSH can be inconvenient when automating tasks. The solution is -to set up authentication via SSH keys. Since we are using the Dropbear server, we need -to use the Dropbear client and configure SSH keys for it. - -First, install the Dropbear client: - -```bash -sudo apt -y install dropbear-bin -``` - -To avoid typing the guest system's IP address every time, add it to `/etc/hosts`: - -``` -172.17.0.2 fvp -``` - -Now, create an SSH key and upload its public part to the guest system: - -```bash -test -f ~/.ssh/id_dropbear || dropbearkey -t rsa -f ~/.ssh/id_dropbear -dbclient -l root -p 8022 fvp mkdir -p .ssh -dropbearkey -y -f ~/.ssh/id_dropbear | grep "^ssh-rsa " | \ -dbclient -l root -p 8022 -T fvp "cat >> .ssh/authorized_keys" -``` - -Check that you can SSH into the guest system using the Dropbear SSH client without -entering a password: - -```bash -dbclient -l root -p 8022 fvp -``` - -## Set up a non-root user - -Commands in this section are executed on the guest system. - -Creating a non-root user in the guest system can be practical. Additionally, we will -copy the same SSH key used for the root user to avoid setting up different key pair -and having to alternate between them. For a non-root user in the guest system we -will use the username `user`. - -SSH as root into the guest system running on FVP and execute these commands: - -```bash -id -u user 2> /dev/null || useradd -m -s /bin/bash user - -test -d /home/user/.ssh || { - mkdir -p /home/user/.ssh - chown user:user /home/user/.ssh - chmod 0700 /home/user/.ssh -} - -test -f /root/.ssh/authorized_keys && { - cp /root/.ssh/authorized_keys /home/user/.ssh/authorized_keys - chown user:user /home/user/.ssh/authorized_keys - chmod 0600 /home/user/.ssh/authorized_keys -} -``` - -Now, you should be able to SSH into the guest system running on the FVP as a non-root user -without having to enter a password: - -```bash -dbclient -p 8022 fvp -``` - -## Configure a shared workspace - -Commands in this section are executed first on the host system and then on the guest. - -It is useful to share a folder between the host and guest systems to facilitate file exchange. -This is especially useful for running Glibc tests, as we will see in the following steps. - -To enable file sharing, we leverage the local network set up by Docker and configure an NFS -share. The FVP offers a Plan 9 filesystem protocol server as an alternative to using NFS, -but it does not currently support some file system operations such as `flock` which is used, -for example, by the Glibc tests, so it is not suitable for our use case. - -On your host, install the NFS server (this example is for Debian or Ubuntu): - -```bash -sudo apt -y install nfs-kernel-server -sudo systemctl disable nfs-kernel-server -``` - -Add this line to the `/etc/exports` file (we presume that host user ID is `1000` and group ID -is `1000`, amend according to your actual setup): - -``` -/home/user/workspace 172.17.0.0/24(rw,sync,no_subtree_check,all_squash,anonuid=1000,anongid=1000,insecure) -``` - -We allow access only from clients within the Docker network (`172.17.0.0/24`) and use the `insecure` -option to avoid complexities of requiring privileged ports on the guest system. To ensure that -the file permissions are aligned between the guest and the host systems, we also specify `anonuid` -and `anongid` options. - -Restart the NFS server for the changes to take effect: - -```bash -sudo systemctl restart nfs-kernel-server -``` - -Now, SSH into the guest system as root and continue the setup on the guest side: - -```bash -mkdir -p /home/user/workspace -chown user:user /home/user/workspace -``` - -Edit the guest system's `/etc/fstab` to mount the NFS share automatically when the system running -on the FVP boots: - -```bash -grep "FVP NFS shared folder" /etc/fstab > /dev/null || { - echo "# FVP NFS shared folder" >> /etc/fstab - echo "172.17.0.1:/home/user/workspace /home/user/workspace nfs4 defaults,_netdev 0 0" >> /etc/fstab -} -``` - -Finally, enable the necessary services for the NFS mounting: - -```bash -services=(netmount rpcbind statd) -for s in "${services[@]}"; do - test -h /var/service/${s} || { - ln -s /etc/sv/${s} /var/service/ - } -done -``` - -At the next boot, you should be able to SSH into the guest system as a non-root user and -access files in the workspace directory, which should be synchronized between the guest -and the host systems. - -## More configuration - -Disabling Address Space Layout Randomization (ASLR) in the guest system helps reducing host memory usage by the FVP: - -```bash -mkdir -p /etc/sysctl.d -test -f /etc/sysctl.d/01-disable-aslr.conf || { - echo "kernel.randomize_va_space = 0" > /etc/sysctl.d/01-disable-aslr.conf -} -``` - -These changes help prevent the OOM (Out of Memory) killer from unnecessarily terminating -processes on the guest system when they consume too much memory: - -```bash -mkdir -p /etc/sysctl.d -test -f /etc/sysctl.d/02-disable-vm-overcommit.conf || { - echo "vm.overcommit_memory = 2" > /etc/sysctl.d/02-disable-vm-overcommit.conf -} -``` - -You are now ready to do put your Void Linux system to the test. Let'sbuild the Glibc from source and run its tests on the FVP. -