Hacker News Reader

Comment by paulclinger | Hacker News Reader

For those not familiar with the project/name: Blink is a brand-new unprivileged userspace virtual machine that can emulate x86-64-linux binaries on any POSIX platform. It's basically a 220kb dependency-free static binary that implements about 600 x86 instructions and 180 Linux system calls, which makes Blink pretty good at running simple command line programs.

View on HN

What does that mean, though? I can run x64 Linux binaries on BSD? How about on ARM processors? On an M2?

Yes to all of that.

ARCHITECTURES = x86_64 x86_64-gcc49 i486 aarch64 arm mips s390x mipsel mips64 mips64el powerpc powerpc64le (https://github.com/jart/blink/blob/master/Makefile#L6)

Would love a second pair of eyes on the powerpc64le JIT, since it partially works but hangs on some tests. https://github.com/jart/blink/issues/17

you can run some x86 binaries on any arch/os Yes, bsd/x86, mac/arm and all other posix compatible OS/arch.

As the other commenters have said - yes. From the last paragraph of the link:

> One of the projects currently using Blink is Cosmopolitan Libc. Blink is more embeddable than qemu-x86_64 since Blink is 22x tinier in terms of binary footprint. So what Cosmo does is it vendors prebuilt Blink binaries inside each of the x86-64 executables it compiles. That way, whenever someone tries to run these programs on a different architecture like Arm, the Actually Portable Executable shell script wrapper will simple extract the appropriate blink binary and re-run itself.

Cosmopolitan LibC is truly “write once run anywhere” except instead of using JVM virtualization, it used x86_64 as the portable VM. Your users don’t need to install a VM or runtime, and you can ship a single exe that runs on all popular architectures and operating systems, including bare metal.

See https://justine.lol/cosmopolitan/

Huh, that's pretty damn cool, thanks!

It's pretty sick, but is anyone actually doing it? It seems pretty scary to use to me.

It's an unprivileged VM, so unless you're the type to do binary analysis before running things this is just as safe as any other binary.

From your explanation, I knew it must have been Justine before I saw the link in the post. Her work is nothing short of amazing.

According to google, there are somewhere between 900 to 4000 x86 instructions (not sure which value is correct or what variants means in this context), and 329 Linux calls. Meaning, there is a lot missing. Which leaves the question: will it communicate in an obvious way if it encounters an unknown instruction or call? Or can I check at least for potential problems before executing a program?

The default build (make MODE=) has logging enabled (so do the release binaries). If any system calls are missing, then Blink will return ENOSYS to the program and then create a "blink.log" file in the current directory reporting that, e.g.

    master jart@nightmare:~/cosmo$ blink ruby --yjit -e 'printf("%d\n",2+2)'
    <main>: warning: timer_create failed: Function not implemented, signals racy
    4
    master jart@nightmare:~/cosmo$ cat blink.log
    I2023-06-05T04:22:15.525179:blink/syscall.c:1020:29575 unsupported prctl op 0x29
    I2023-06-05T04:22:15.556803:blink/syscall.c:5720:29575 missing syscall 0x122
    I2023-06-05T04:22:15.556866:blink/syscall.c:5720:29575 missing syscall 0x122
    I2023-06-05T04:22:15.556886:blink/syscall.c:5720:29575 missing syscall 0x0de

You can also use `blink -es program...` to log system calls to stderr, similar to strace, when you need to troubleshoot further. Once you do that, please file a feature request.

Is there a list of unsupported syscalls and instructions, and how to add support for them for people interested in contributing?

Here are the missing system calls that people filed issues requesting: https://github.com/jart/blink/issues?q=is%3Aissue+is%3Aopen+... The place where they go is https://github.com/jart/blink/blob/master/blink/syscall.c Looking forward to any changes you send us!

A lot of those are post-SSE2 SIMD instructions. It's not something I would worry about.

Do applications not typically make use of SSE3+?

They do!

The most important post-SSE2 extensions are SSSE3 (pshufb) and SSE4.1 (rounding, min/max, blending, etc...). Pure SSE2 is a nightmare to use as it's a totally unbalanced SIMD ISA (a lot of missing stuff here are there requires a lot of workarounds and sometimes it's just better to go scalar). In addition, just [V]PSHUFB alone can do wonders and has a lot of application - I would say that almost all interesting problems can take the advantage of PSHUFB.

It's above 4400 instructions actually if you count different encoding of SIMD instructions (like SSE2, VEX, and EVEX variations) and consider instructions using 128-bit, 256-bit, and 512-bit SIMD as separate instructions.

Instructions can be comfortably explored here:

https://asmjit.com/asmgrid/

Why was it named after the chrome rendering engine?

What about direct syscall runtimes like Go's?

Reply on news.ycombinator.com