How about the infamous iOS hack with a VM implemented in a JBIG2 PDF? https://projectzero.google/2021/12/a-deep-dive-into-nso-zero...
This is one of my favourite exploit stories. Incredible work.
Bytecode VMs in surprising places (2024)
51–60 of 74 posts
Re: Bytecode VMs in surprising places (2024)
#52SBus peripherals use the Forth language in their PROMs to initialize themselves[1]. [1] https://docs.oracle.com/cd/E19957-01/802-3239-10/sbusandfc.h...
Good call! (Whether it's a directly threaded, indirectly threaded, subroutine threaded, token threaded, Huffman threaded, or string threaded call.) https://en.wikipedia.org/wiki/Threaded_code#Token_threading Mitch Bradley created OpenFirmware. It started at Sun as OpenBoot (informally "SunForth") on the SPARCstation 1 in 1989, was standardized as IEEE 1275-1994, and was renamed OpenFirmware at that time. Its lineage…
This is FASCINATING, thank you!
Re: Bytecode VMs in surprising places (2024)
#53A medium-spicy take of mine is that a bytecode VM in a GPU kernel is not as bad of an idea as one might think, and in some cases it can actually be the most reasonable solution. Some fun examples: 1. As mentioned in the post above, the Dolphin emulator famously implements the entire Gamecube/Wii GPU pipeline in a single gigantic ubershader, and this is useful because it avoids shader compilation stalls [1]. 2. Blende…
Linux running in a shader https://blog.pimaker.at/texts/rvc1/
Re: Bytecode VMs in surprising places (2024)
#54Don't forget Sweet16 by Woz
Re: Bytecode VMs in surprising places (2024)
#55Earlier quoted context omitted.
Since ACPI was mentioned, let's not forget about EFI! https://uefi.org/specs/UEFI/2.10/22_EFI_Byte_Code_Virtual_Ma...
Since that page is a little dense, the higher-level version: PCI supports Option ROMs (OpRoms) - plug in device like a NIC or a GPU, your BIOS actually loads compiled code from it and executes it on the CPU. In many systems for example PXE booting (net booting) is actually a function of the NIC, executing code on the CPU to load an operating system. We're talking actual x86/x86_64 machine code here running in the pri…
The network is the computer
Re: Bytecode VMs in surprising places (2024)
#56Earlier quoted context omitted.
Power Macs had an x86 emulator which ran the x86 ROM in PCI cards.
I don't think that's true? Macs were running Open Firmware, they had an expectation of the same Forth code that Suns made use of, and several cards needed to be flashed with Apple firmware to be Mac compatible. Alphas definitely ran x86 video card init code under emulation, though.
I probably misremembered Alphas.
Re: Bytecode VMs in surprising places (2024)
#57The Python pickle format is a bytecode [1], although not a Turing-complete one, I think. [1] https://formats.kaitai.io/python_pickle/
Pickle is definitely turing-complete. It's a super easy way to RCE your system.
Where does that come from though? I don't see any flow control or anything else compute-y in the bytecode itself. I know unpickling can run Python code, but i wouldn't say that makes the bytecode itself Turing-complete.
Re: Bytecode VMs in surprising places (2024)
#58LEGO Mindstorms programs run in an on-brick VM, iirc
Re: Bytecode VMs in surprising places (2024)
#59Earlier quoted context omitted.
I don't think that's true? Macs were running Open Firmware, they had an expectation of the same Forth code that Suns made use of, and several cards needed to be flashed with Apple firmware to be Mac compatible. Alphas definitely ran x86 video card init code under emulation, though.
I probably misremembered Alphas.
Very easy things to confiate given we're talking about hardware that's on the order of 30 years old!
Re: Bytecode VMs in surprising places (2024)
#60I guess all (or most) of these could be replaced by a RISC-V VM, with the necessary domain extensions. A RISC-V VM already competes with WASM for many applications.