mrugiero

> that would have been implement in something like forward only language like ebpf. wasm is just an outgrown hack that people are hopping will be that safe sandbox and solve all JavaScript problems.

It's funny that every time an article on new functionality for eBPF appears in LWN everybody is like "why don't they just use WASM???". More seriously, a forward only language is by definition too strict for the general case of sandboxing, unless you mean using it only for hooking the syscalls rather than as a target for your program. In particular, the Linux implementation caps your execution to 1M instructions, which is not a lot for something you'd want on your browser.

> But for a plugin system, many people would prefer to write plugins in JS itself, so for WASM plugins, they might have to be compiled to WASM first. Dont know how if there is a mature implementation of JS->WASM.

Not everyone tho, which is kinda the point of abstracting away your language for plugins. People like Python, Lua, Go, Rust, etc... Some do like JS of course, but not everybody. Re: mature implementations, I would guess worst case QuickJS probably can compile to WASM and it's small enough that your runtime will probably offset the extra blob size.

I see. I'll try to read the links over the weekend, they seem really interesting. It's sad that the terms are so overloaded though, as it makes it hard to reach preexisting approaches and leads to rediscoveries of the same idea (I see that both Jitter and C&P seem to implement this very same idea, except maybe in the way the templates are created, and both seem to believe their invention is novel).

That's true. But it's still a stretch to say they are the same thing. That's why I said it can be seen as generalizing the approach.

The question was about OSes with hardened runtime protections. The most basic of them all is W^X. All BSDs use it, and IIRC Linux is able to enforce it as well. I'd be surprised if it isn't the default in most distros, but I guess it's not impossible. I need to go for lunch so I won't check right now.

That is not the point though. I know threading allows using a custom convention and just jumping. What it doesn't, IIUC, is allow specializing your code for runtime data. Copy-and-patch and Jitter do. It's essentially static vs dynamic. I'm new to this so I may very well be misunderstanding threading, but I don't think it allows for modifying the functions on runtime by itself.

Do you have any links to the traditional ones for those interested (i.e. me)? I only found out about the approach due to the author's articles a few months ago.

Does that even work in W^X platforms? Context for my response has that assumption, we can't simply throw it out the window, right? I think I read somewhere about making two mappings to the same physical page (one W, one X), are you referring to that? (I'd still need to know how that works as it kinda defeats the protection, the OS should prohibit that, right?)

I don't think this counts as threading, though it makes use of it. Threading mostly removes the dispatch overhead, but you still have a general function per instruction, a function call, and an inability to inline constants. Copy and patch could be thought of as a generalization of threading in the sense that you still precompile code for your instructions, but instead of calling that code you poke holes in it to replace constants you only know at runtime, then make a single callable program out of those instead of jumping around for every instruction.

There is a prior, very similar approach in GNU Jitter, but it uses only the compiler and some magic rather than the linker for marking spots to replace. I read about it by mention of moonchild in a thread[0] linked by foota here.

[0]: https://news.ycombinator.com/item?id=40410420

The same as with any other JIT runtime: you do your transformations first, and then you do the `mprotect` call that turns write permissions off and execution permissions on. The only caveats I can think of (`pledge`d not to use `mprotect`, marked most of the address space with `mimmutable`) apply to all other JITs too. The gist is that you operate on a copy of code, and that copy is in a writable page until it's ready to run, so you never violate the W^X rule.

I mailed the authors a few months ago and indeed, it lives there but is independent-ish. They don't consider it ready to use for anything else other than experiments, though.

Why FreeDOS vs nothing or why FreeDOS vs Linux? The former, because some OEMs have agreements with Microsoft that prohibit shipping systems without an OS. They found the loophole that they could ship a free OS as a placeholder. Why not Linux? I guess it was easier at the time and they then just kept shipping what was already working. It was never intended to keep the original OS anyway (and in particular, Linux users tend to be opinionated and install their favorite distro anyway).

squashfs is supposed to be read-only, right?

As if BIOS is any more open than UEFI is. At least UEFI had an open reference implementation since the beginning. BIOS had to be reverse engineered from IBM's implementation AFAIR. Besides, two wrongs don't make one right. BIOS was a clutch from the beginning (it was probably appropriate for the time tho) and we should strive for better. We should keep functional systems working of course (e-waste is a real problem), but we shouldn't keep using it for the new stuff because we see the past with rose tinted glasses. Rather than push for the past we should push for the future, for having all boards ship Coreboot and have that support upstream instead. That's how you achieve openness, not by sticking to _proprietary blobs_ of an outdated interface.