Yesterday, Apple did release RosettaLinux as part of the macOS Ventura preview. Let’s take a first quick look…<\/p>\n\n\n\n
RosettaLinux is located at No. Rosetta on Linux exclusively operates in JIT mode, at least for the time being.<\/p>\n\n\n\n That directory is mapped through When the Rosetta directory is mapped to the virtual machine, all of the VM runs in Total Store Ordering<\/em> mode. This provides the guarantees needed by Rosetta to provide x86-compatible memory model semantics.<\/p>\n\n\n\n If TSO mode is not present or not active on a given Arm platform, Rosetta explicitly does not provide those guarantees. It does not<\/em> try to handle that use case. As such, to provide proper semantics on those environments, you can use Rosetta has a mechanism to restrict it to A re-creation of that mechanism is pasted below:<\/p>\n\n\n\n As we can see, the mechanism is quite trivial to bypass. However, please rely on another solution if you’re running on non-Apple hardware.<\/p>\n\n\n\n Running it on a Mac is fun, but what if we try to run it on other processors? <\/p>\n\n\n\n My first thought was the Tegra Xavier processor, which provides sequential consistency in hardware. As such, it satisfies the programmer-visible memory ordering constraints required for Rosetta to be functional. <\/p>\n\n\n\n However, Rosetta relies on And the Which Arm platforms are easily accessible with flag manipulation instructions? There are some, such as the AWS Graviton3 processor, which uses Arm’s Neoverse V1 core.<\/p>\n\n\n\n Rosetta supports Let’s override the value reported to Rosetta with 1.00 GHz. This is close enough for things to work fine for testing purposes. <\/p>\n\n\n\n\/Library\/Apple\/usr\/libexec\/oah\/RosettaLinux<\/code>. A rosetta<\/code> ELF executable is present on that directory.<\/p>\n\n\n\nDoes it do AoT?<\/h2>\n\n\n\n
Mapping to the VM<\/h2>\n\n\n\n
virtiofs<\/code> to the virtual machine. binfmt_misc<\/code> is then used to make execution attempts of x86_64 binaries run through Rosetta.<\/p>\n\n\n\ntaskset<\/code> to bind applications using Rosetta to a single core.<\/p>\n\n\n\nNot-really-DSMOS*<\/h2>\n\n\n\n
Virtualization.framework<\/code> virtual machines. The ioctl<\/code> is passed through virtiofs<\/code> to the host.<\/p>\n\n\n\n char* AppleRosettaKey = \"Our hard work\\nby these words guarded\\nplease don't steal\\n Apple Inc\";\n\n int fd = openat(AT_FDCWD ,\"\/proc\/self\/exe\", 0);\n\n if (fd < 0) {\n rosetta_error(\"Unable to open \/proc\/self\/exe: %lu\", fd);\n }\n\n char key[0x45];\n int ioctl_result = ioctl(fd, _IOC(_IOC_READ, 0x61, 0x22, 0x45), key);\n\n if (ioctl_result < 0 || memcmp(key,AppleRosettaKey,0x45) != 0) {\n rosetta_error(\n \"Rosetta is only intended to run on Apple Silicon with a macOS host \\\n using Virtualization.framework with Rosetta mode enabled\"\n );\n }\n<\/code><\/pre>\n\n\n\nRunning it on non-Apple CPUs?<\/h2>\n\n\n\n
Tegra Xavier testing<\/h3>\n\n\n\n
FEAT_FlagM<\/code> flag manipulation instructions. Those are not implemented on Carmel. As such, I skipped over to another potential testing target.<\/p>\n\n\n\nCNTFRQ_EL0<\/code> timer frequency of 31.25MHz on Xavier doesn’t match with what Rosetta expects either.<\/p>\n\n\n\nGraviton3 testing<\/h3>\n\n\n\n
rosetta error: Unsupported counter frequency, check value of CNTFRQ_EL0\nTrace\/breakpoint trap<\/code><\/pre>\n\n\n\nCNTFRQ_EL0<\/code> timer frequencies of 24 MHz and 1.00GHz, which is unlike the 1.05 GHz value used by the Graviton3 platform.<\/p>\n\n\n\n