Originally published at: Emulation, Virtualization, and Rosetta 2: A Blend of Old, New, and Yet To Come - TidBITS
Rosetta 2 for Apple silicon Macs is the latest in a line of emulators and virtual machines that Apple has released to provide continuity across hardware and operating system transitions. What’s next to come? A full Intel chip emulator for Apple’s M-series ARM chips? We’ll see.
3 Likes
IANAL, but I bet a lawyer could argue that, per the recent Supreme Court decision in Oracle v Google, that reusing and reimplementing (in emulation) the copyright parts of an Instruction Set Architecture would constitute “fair use”. (For what it’s worth, I think the Supreme Court got that one exactly right. Justice Thomas’ dissent was not founded in a reasonable understanding of the difference between ‘interface’ and ‘implementation.’)
1 Like
The Oracle suit was reduced to copyright (Oracle originally attempted to include patent claims), while Intel has been able to defend on patents at times. So AMD and others built compatible chips in clean-room reverse-engineering implementations, but also with expired x86 patents. Intel continues to add proprietary instructions. The level to which Apple has deployed code that uses these instructions would be a fascinating exploration.
1 Like
Regarding running iOS apps on macOS, I would argue that this is neither emulation nor virtualization, but a kind of “comtainer” environment.
For those unfamiliar with the term, a “container” is a sub-environment within a host operating system. Apps running in it share the same OS kernel as the host environment, but they (usually) have separate resource partitions for RAM, I/O, storage, etc. The result is like a lightweight VM - it uses less resources because it is sharing the host OS kernel, but offers much of the resource isolation that a proper VM environment offers. The downside to containers is, of course, that apps in a container must be compatible with the host OS - if a different OS is required, then a full VM is necessary.
In the case of iOS apps running on macOS, it’s the same kernel (maybe with some different configuration parameters, but pretty much the same). And many system frameworks are the same, but with other frameworks (e.g. UI stuff) being completely different. Which is exactly the kind of thing containers excel at.
The fact that macOS has been using a container-like technology for “sandboxing” apps for quite some time is additional evidence to support my analysis.
This is fair! I’m not sure the extent of the kernel changes, so a container is a reasonable description, though I think it’s hovering between virtualization and containerization. Parallels has that Coherence mode in which the OS portion of a virtual machine largely disappears in favor of each app seemingly being available in the current host version of macOS. I think the way that iOS/iPadOS app compatibility is enabled in Big Sur under M1 Macs is more like that, in that a special environment is set up that allows the apps to appear like first-class citizens. Maybe we are saying the same thing here, but we certainly aren’t far apart. It’s clever as all get out.
Interesting to see a trial on whether this would constitute a ‘software patent’, particularly if it’s just the instruction set specification, versus the silicon implementation.
Is this what Docker is? I’ve never quite understood Docker.
Containers, VMs and emulators can all share the host OS’s GUI. It’s all a matter of developing a pair of cooperating display device drivers - one for the host and one for the guest - that can map drawing API calls from the guest onto a window owned by the host.
The way to tell what is going on with iOS-on-macOS is to look below the covers.
- If the environment is just running the app and it’s shared libraries/frameworks, sharing the host OS’s kernel, then it’s a container (or a container-like envionment).
- If the environment is running its own kernel, whether another instance of the host’s kernel or a different kernel, then it’s a VM.
- If the environment is a different CPU architecture (e.g. ARM on x86), then it’s an emulator of some kind.
Rosetta is a hybrid of these. The part that compiles the foreign architecture app into the native architecture is emulation technology. The part that runs the re-compiled app along with ported versions of the system frameworks is probably container technology (assuming that Apple sandboxes these apps). It could, however, run them as ordinary processes in the host environment as well.
Pretty much. Modern operating systems have the ability to partition resources within a single running instance of the kernel. Sort of like protected memory, but extended to many different kinds of resources. The specific mechanism varies from OS to OS (Linux uses something called “namespaces”), but the general idea is that you can create a child process with its own partition of system resources, including:
- RAM (very similar to normal memory protection)
- File system (e.g. chroot to make a specific directory the root directory for the child process and union mounting to combine file system fragments together for a process).
- Network. Assign specific network interfaces (physical and/or virtual) for exclusive use by a process. Also permit creation of separate instances of routing tables and related structures.
- Processes. The process can see itself and its child processes, but other processes are invisible and inaaccessible.
These mechanisms (along with others) are used to implement sandbox environments, to keep untrusted processes isolated from the rest of the system.
They can be used in other ways to create what is effectively a lightweight VM. The process and its children are isolated from the rest of the system, but without needing to run another copy of the kernel and system processes. This, when combined with a set of tools for convenient maintenance and administration, is pretty much what containers are.
Docker is one of the most popular suite of container-management tools. You can specify a set of file system fragments to comprise the container’s file system, a set of software packages (typically your app and what it depends on), and network interfaces for the outside world to communicate with the software in the container. You then compile this specification to create a convenient self-contained “container” object which you can launch and terminate at will in order to start and stop the software, along with the entire OS environment it depends on.
Docker also include a large repository of containerized software packages that you can combine together when making your own containers. So you can tell Docker that you need a container including an Ubuntu Linux environment, the Apache web server, the MySQL database server and PHP scripting (the so-called “LAMP” environment) and let the Docker tools build all that for you, so you only need to add your app and a place to store its files.
With a system like this, you can also create multiple instances of a container. You can also copy it to other compatible computers, running the app and its environment remotely. This makes for easy replication/distribution of software - which is great for developing cloud-based software. Docker includes tools like “Compose” for making apps that are composed of multiple containers and “Swarm” which allows dynamically creating and destroying container instances across a cluster of linked servers, as needed in order to keep up with requests from elsewhere on the network.
Another popular container-management infrastructure is Kubernetes. It provides facilities (typically built over Docker, but can also use other container systems) that many cloud app developers like to use for container infrastructure. It has been integrated in to nearly every cloud infrastructure (AWS, Google, Microsoft, IBM, etc.) these days.
3 Likes
I didn’t see any mention of this rumour on here. I do hope I won’t be affected (in the UK). Anyway, it certainly suggests something legal.