Using UTM on M-series Mac laptops

1. Installing UTM

Visit https://mac.getutm.app/, then click “Download”. (Downloading from the UTM website is more reliable than following the “Mac App Store” link.)

Once downloaded, locate and select the .dmg file you have downloaded. A dialog box should appear. Click and drag the icon to your Applications folder.

2. Selecting a virtual machine

You’ll need to download one or more virtual machine images, and then create virtual machines from them that you’ll use as a development environment. (You can download more than one, and you can delete any downloaded image if you like and try again.)

There are many options for downloading a virtual machine image – we outline three possibilities.

Use an ARM64 image

The “gallery” of pre-built UTM virtual machines doesn’t include any for Ubuntu 20.04, but it does include one for Ubuntu 22.04, which is very similar. You can visit this link to download the Ubuntu 22.04 image. Clicking the “Open in UTM” link should download the virtual machine image and open it using UTM.

This image uses an ARM64 processor, so it is not the same as the CITS3007 standard development environment (SDE) – see here for some of the differences. For most purposes, the virtual machine you’ve downloaded should behave quite similarly to the CITS3007 SDE, but:

when you get to lab 4 (in week 5), which covers buffer overflows: if you want to attempt the extension tasks for the lab, they won’t work on an ARM64 virtual machine. They use shellcode that only works on x86-64 processors.
when working on the project (due in week 11), you’ll need to allow for differences between platforms. The biggest difference is that the char type on an x86-64 platform is signed, but on ARM64 platforms it is unsigned. You may want to make use of GCC’s -fsigned-char option to mimic the x86-64 behaviour (see here). It’s also recommended that you test your code using a x86-64 virtual machine before submitting.

Use an old x86-64 image

The “gallery” of pre-built UTM virtual machines includes an image for a very old (2013) version of Ubuntu 14.04, which you should be able to use in order to test code on an x86-64 platform. However, x86-64 images run much more slowly than ARM64 images do – your Mac has to emulate a very different sort of CPU.

You can visit this link to download the Ubuntu 14.04 image. Clicking the “Open in UTM” link should download the virtual machine image and open it using UTM.

Another possibility, although it has not been very thoroughly tested, is to use UTM with a CITS3007 x86-64 Qcow image file.

Use the CITS3007 x86-64 Qcow image file

A Qcow image file – a format related to the one UTM uses – is available for the x86-64 CITS3007 standard development environment (SDE). However, UTM doesn’t provide very clear documentation on how such files can be used. Nevertheless, if you wish to try it, and are familiar with the Linux command line, some general instructions are:

Download the Vagrant .box file from here to your machine (the saved file should be called vagrant.box).
Extract the file box.img from the vagrant.box file using tar (vagrant.box is a standard gzipped tar file).
Rename box.img to cits3007.qcow2.
Import the qcow2 file into UTM.

A former CITS3007 student has also provided some tips on working with UTM here (PDF).

In the following section of this lab sheet, we discuss some ways that an ARM64 platform can differ from the x86-64 platform.

3. Notes on the ARM64 platform

3.1 What are some differences between ARM64 vs x86-64 platforms?

The standard CITS3007 development environment runs on the x86-64 architecture, and any code you submit for the CITS3007 project will be compiled and tested using GCC on the x86-64 architecture.

M-series Mac laptops, however, use the ARM64 architecture, which differs from x86-64 in several ways (note that the following list is not comprehensive!):

The architectures have a different instruction set – programs compiled for one will not run on the other, and shellcode written for one will not work on the other.
The char type can be either signed or unsigned – on the x86-64 platform, a char is usually signed, but when targeting the ARM64 architecture, C compilers (including GCC) usually default to it being unsigned (for performance reasons that are now largely historical).
It’s possible to force GCC to make the char type signed or unsigned by using the -funsigned-char and -fsigned-char options.
Data structure padding and alignment can differ between the two. GCC provides “attributes” which allow you to force variables or structs to use padding and alignment rules you specify. (Doing this can result in generated code being slightly slower, but you may not care about the difference.)

You can find comments on some of these differences in the “Miscellaneous C porting issues” section of the developer documentation for the ARMv7-A series of processors.

3.2 What platform will submitted projects be tested on?

Projects will be tested on the x86-64 platform, using GCC as a compiler, and the CITS3007 standard development environment.

3.3 How can I ensure my code runs correctly on the x86-64 platform?

It’s up to you to make sure that you thoroughly test your code and ensure it runs correctly on the x86-64 platform. Some suggestions as to how you might do so include:

Compiling and testing your code using a pre-built UTM virtual machine which emulates the x86-64 processor. (An example is the pre-built Ubuntu 14.04 virtual machine.) Note that emulated virtual machines will run quite slowly on a Mac ARM64 computer.
Compiling and testing your code using a virtual machine on GitPod. (Note that on GitPod, you won’t be able to alter the kernel parameters, which is required if you want to complete the “extension tasks” for the week 6 lab, on buffer overflows, and for the week 8 lab, on race conditions.)
Referring to published portability guidelines – one set of such guidelines is provided by Imperial College, London, and the GNU project also has some suggestions.
Compiling and testing on an ARM64 platform with a range of different static analysers, a range of different compilers (e.g. both GCC and Clang) – with all appropriate warnings enabled – with a range of different sanitizers enabled, and at a range of different optimization levels. While this won’t ensure your code works correctly on an x86-64 platform, it is likely to result in fewer problems once you do try to run it on an x86-64 system.