4 ms·

I stumbled across WasmJIT about a year ago and actually used many of the concepts in the project for my own kernelspace implementation of the portable native cl

I stumbled across WasmJIT about a year ago and actually used many of the concepts in the project for my own kernelspace implementation of the portable native client (pNaCl). Projects like these are extremely interesting to me because they offer the possibility of a completely architecture-neutral userspace that can be used across multiple devices without recompilation.

infogulch 8y ago
This goes a step further and could offer an architecture-neutral kernel space. If part of loading the module includes validation and external memory access is checked as in browser implementations this could even lead to safer/less exploitable kernel modules with more well-defined failure modes.
- ChickeNES 8y ago
  The problem I see with this is that there are still no 8bit or 16bit data types (or bitfields for that matter) in the wasm spec, which are kind of useful for interfacing with hardware and for protocols (Ethernet, TCP/IP, etc). Sure, you can pack and unpack them with masks and shifts (which I assume clang,LLVM,gcc,etc do), but it seems awfully inefficient when the resulting code ends up running on x86 or other architectures with native 8/16 bit instructions.
  - josephg 8y ago
    Unless I'm missing something, this should be pretty easy for the webassembly working group to fix. At a guess they probably just need some clear decisions around how to handle endian issues. But right now they're just focussing on the browser use case. If kernel module developers become a vocal part of the wasm ecosystem, I'd expect 8- and 16- bit data types to get added before long.
    - infogulch 8y ago
      I wonder if the pattern is common enough and simple enough that wasmjit could substitute the load-shift-and/shift-or-store sequences into direct 8,16,32-bit stores and loads.
    - stepik777 8y ago
      > they probably just need some clear decisions around how to handle endian issues They are handling endian issues by simply requiring little-endian.
  - comesee 8y ago
    Wasm has efficient 16/8 byte load/store instructions. 16/8 bit data types are irrelevant on x86 since it internally uses 32 bit registers anyway.
    - ChickeNES 8y ago
      Huh? x86/x86_64 has segmented registers that can be used as 64 bit (rax), 32 bit (eax), 16 bit (ax), and the upper and lower 8 bits of the latter (ah,al). Not to mention I/O ports which use 16 bit addresses and allow for 8, 16, and 32 bit accesses, and various internal processor data structures that have 8 or 16 bit wide fields, among other uses.
      - comesee 8y ago
        Performing operations using the segmented registers is no faster than using the 32-bit analogues. Benchmark an add of eax,edx vs Al,dl in a loop.
protomyth 8y ago
Projects like these are extremely interesting to me because they offer the possibility of a completely architecture-neutral userspace that can be used across multiple devices without recompilation. It makes one wonder what would have happened if the Micro/370 had gone forward and the architecture-neutral userspace had evolved in the PC space. http://www.cpushack.com/2013/03/22/cpu-of-the-day-ibm-micro-370/ http://www.cpushack.com/2013/03/22/cpu-of-the-day-ibm-micro-...

infogulch 8y ago

This goes a step further and could offer an architecture-neutral kernel space. If part of loading the module includes validation and external memory access is checked as in browser implementations this could even lead to safer/less exploitable kernel modules with more well-defined failure modes.

ChickeNES 8y ago
The problem I see with this is that there are still no 8bit or 16bit data types (or bitfields for that matter) in the wasm spec, which are kind of useful for interfacing with hardware and for protocols (Ethernet, TCP/IP, etc). Sure, you can pack and unpack them with masks and shifts (which I assume clang,LLVM,gcc,etc do), but it seems awfully inefficient when the resulting code ends up running on x86 or other architectures with native 8/16 bit instructions.
- josephg 8y ago
  Unless I'm missing something, this should be pretty easy for the webassembly working group to fix. At a guess they probably just need some clear decisions around how to handle endian issues. But right now they're just focussing on the browser use case. If kernel module developers become a vocal part of the wasm ecosystem, I'd expect 8- and 16- bit data types to get added before long.
  - infogulch 8y ago
    I wonder if the pattern is common enough and simple enough that wasmjit could substitute the load-shift-and/shift-or-store sequences into direct 8,16,32-bit stores and loads.
  - stepik777 8y ago
    > they probably just need some clear decisions around how to handle endian issues They are handling endian issues by simply requiring little-endian.
- comesee 8y ago
  Wasm has efficient 16/8 byte load/store instructions. 16/8 bit data types are irrelevant on x86 since it internally uses 32 bit registers anyway.
  - ChickeNES 8y ago
    Huh? x86/x86_64 has segmented registers that can be used as 64 bit (rax), 32 bit (eax), 16 bit (ax), and the upper and lower 8 bits of the latter (ah,al). Not to mention I/O ports which use 16 bit addresses and allow for 8, 16, and 32 bit accesses, and various internal processor data structures that have 8 or 16 bit wide fields, among other uses.
    - comesee 8y ago
      Performing operations using the segmented registers is no faster than using the 32-bit analogues. Benchmark an add of eax,edx vs Al,dl in a loop.

protomyth 8y ago

Projects like these are extremely interesting to me because they offer the possibility of a completely architecture-neutral userspace that can be used across multiple devices without recompilation. It makes one wonder what would have happened if the Micro/370 had gone forward and the architecture-neutral userspace had evolved in the PC space. http://www.cpushack.com/2013/03/22/cpu-of-the-day-ibm-micro-370/ http://www.cpushack.com/2013/03/22/cpu-of-the-day-ibm-micro-...