UEFI Bindings for JavaScript
codeberg.org116 points by ananas-dev 3 hours ago
116 points by ananas-dev 3 hours ago
I think there are two philosophies here:
1) JavaScript must stay in the box (aka in the browser).
2) JavaScript as a general purpose programming language.
While I can absolutely understand 1), I have had wanted to access the filesystem via JavaScript, just as I do via ruby or python, for local use only. After I googled for a while, they would say that this is not possible unless one uses npm/node. I think this shows that there are use cases here and the "default" JavaScript, aka 1), does not cover these. I do not like JavaScript, but based on my own use cases, I actually favour 2) far more than 1). So from that point of view, being able to access UEFI can also be useful. So why not.
Oh hey, we've reached the "Metal" stage! https://www.destroyallsoftware.com/talks/the-birth-and-death...
Love this. An example of complete and total dominion over the machine. Great quote here too lol
> Prometheus stole fire from the gods and gave it to man. For this he was chained to a rock and tortured for eternity.
Can someone break this down for me? Looks like it's using... C? to load a js interpreter which bootstraps an API around all UEFI features? Do I have that right?
And, if so, does that mean that once the API has been bootstrapped, one could actually write an OS in js? Or are there other abstractions that would need to be migrated first?
I'm pretty sure someone already compiled Linux to asm.js a few years ago. As asm.js is/was a subset of JS, you could say it's already been done. In theory, you could continue work from there in JS.
https://medium.com/@retrage/lkl-js-running-linux-kernel-on-j...
You don't need a JS bootloader to write an OS in JS. The bootloader just drops the machine into some memory address for it to start executing your OS init script. that bit could be a Javascript interpreter. You can't do much with the architecture in Javascript though, because it doesn't allow you to map memory directly to your types (unless there's some ungodly nonesense I'm not aware of) so you'll have to drop into C/asm to e.g. interact with the ports/registers/tables to set up userspace.
> And, if so, does that mean that once the API has been bootstrapped, one could actually write an OS in js?
I bet somebody has done that.
https://www.google.com/search?q=os+kernel+in+javascript
Seems like a small number of hobbyists have attempted.
I've heard of people doing this with other high level languages. Basically you need enough low level code to bootstrap a VM. Once you have that, you can make the high level language decide some logic that traditionally would be in C code, like manipulating page tables or whatever.
Automatic Garbage Collection in a kernel probably won't work:
I vaguely remember hearing about someone trying to use .Net in the Windows kernel.
The big problem is garbage collection: If I remember correctly, the fact that "any" operation can fail with an out of memory exception was a huge problem. Another problem was that random pauses for garbage collections in the kernel had major stability issues.
In short, I hope that the js kernel is for amusement and education; otherwise it would need a much more advanced garbage collector then earl 2000's .Net.
You'd need to write an entire hardware abstraction layer to do anything useful. There's projects that do this for microcontrollers - eg MicroPython and Espruino.
Depending on your definition of OS, yeah you could do that :)
Hey, when Apple transitioned from m68k to PowerPC, it took them a hell of a long time to rewrite massive parts of their OS. It's a low bar, though...
I presume you'll add the network stack next, so that I can use my favourite, most useful packages?
import isOdd from "https://unpkg.com/is-odd";Well, there's a network stack already there, including HTTP and HTTPS on newer firmwares.
> If this makes you grin, you are probably holding the torch.
What if it makes me recoil in horror? screams into the void
This project will go places. Like every silly project not intended for production. :)
next step is to create a UEFI TUI using react (please don't)
This is hilarious lol, it’ll be any day now before we get a full JS kernel. Garbage collection could be an obstacle, but I know there have been some kernels written in Go/Java before
Who needs to garbage collect? Just leak memory until the system dies! That strategy seems to be good enough for claude code, anyway.
If it’s good enough for missile guidance systems, it’s good enough for me.
This is both so impressive and cursed that I'm not sure how to feel.
Does it manage to support floats? I am not sure if those can be safely used in the UEFI environment. (I recall GRUB’s build of Lua being integer-only, and Linux avoiding the use of floating-point arithmetic in kernel mode, but I don’t remember the reason.)
Wow, this is cursed.
"The Birth and Death of JavaScript" is coming true after all.
I was going to post this as well! A direct link to the video: https://www.destroyallsoftware.com/talks/the-birth-and-death...
Could this be used as a learning tool? Rebooting the computer takes so much more time compared to reloading the browser tab. And you probably can't brick your computer.
I’m always amazed and slightly envious of what programming languages with large developer bases can do. I mean if a language is Turing complete it can do anything, but JavaScript takes this to the extreme.
Mind you I never said anything about quality or performance, obviously doing everything in JavaScript comes with it’s own issues but if you were to say that someone got JavaScript running in the Linux kernel as a POC I wouldn’t even be surprised
Turning in the widening gyre, the falcon cannot hear the falconer. The center cannot hold.. The old prophecy is coming true.
Awesome! Everything will be rewritten in JS
Can't wait for browser support for this... ;-)
webuefi has already been shipped by google for use on chromebooks. but mozilla and apple irrationally refuse to implement the standard for "security reasons"
This is incredible.
> If this makes you grin you are probably holding a torch
Hilarious
Yeah, but your [developers] were so preoccupied with whether or not they could, they didn't stop to think if they should.
It begins!
"Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should."
Pretty neat, though.
Finally!
I love it.
Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should!
But why?
It's just a silly experiment; the real endgame is to make a bootloader that is customisable using HTML/CSS/JS
Since PDFs can contain JS, presumably that should be the preferred way of modifying your boot loader.
Why not?
Because this can end very badly. It is a new surface to attack
Why is it a new surface? Either you can run UEFI code, or you can't. Attacking the JS interpreter itself is unrealistic IMHO, it's the poorly written JavaScript running on top of this that might open new surfaces of attack. But other UEFI code is mostly written in C or C++, so let's call that a wash?
Cursed