[HN Gopher] UEFI Bindings for JavaScript
___________________________________________________________________
UEFI Bindings for JavaScript
Author : ananas-dev
Score : 180 points
Date : 2026-02-09 14:07 UTC (8 hours ago)
(HTM) web link (codeberg.org)
(TXT) w3m dump (codeberg.org)
| edward28 wrote:
| Wow, this is cursed.
| monax wrote:
| I think r/unixporn will love it once it gets DOM support :^)
| kijin wrote:
| Finally, we can create splash screen animations in pure CSS!
| lnenad wrote:
| I think the proper term is blursed.
| madduci wrote:
| But why?
| monax wrote:
| It's just a silly experiment; the real endgame is to make a
| bootloader that is customisable using HTML/CSS/JS
| magicalhippo wrote:
| Since PDFs can contain JS, presumably that should be the
| preferred way of modifying your boot loader.
| monax wrote:
| Yeah that's the natural next step, I'll work on that next
| ThrowawayTestr wrote:
| Why not?
| madduci wrote:
| Because this can end very badly. It is a new surface to
| attack
| yjftsjthsd-h wrote:
| Maybe? What's your threat model?
| M95D wrote:
| Exactly! It's actually great! More ways to jailbreak stuff.
| eqvinox wrote:
| 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?
| g051051 wrote:
| "Your scientists were so preoccupied with whether or not they
| could, they didn't stop to think if they should."
|
| Pretty neat, though.
| fbnszb wrote:
| Yeah, but your [developers] were so preoccupied with whether or
| not they could, they didn't stop to think if they should.
| redvulps wrote:
| next step is to create a UEFI TUI using react (please don't)
| monax wrote:
| OMG we can use ink for that
| aruametello wrote:
| you may just have casted a curse on our future motherboards,
| damn you
| tracker1 wrote:
| Considering how bad some of the Gamer-ish firmware UIs are now,
| it might be an improvement.
| my_throwaway23 wrote:
| 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";
| monax wrote:
| We are getting isOdd in the bootloader before GTA-IV
| spiffyk wrote:
| Wait, when did I time-travel?
| monax wrote:
| oops typo
| p_l wrote:
| Well, there's a network stack already there, including HTTP and
| HTTPS on newer firmwares.
| catapart wrote:
| 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?
| monax wrote:
| Depending on your definition of OS, yeah you could do that :)
| nxobject wrote:
| 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...
| DustinBrett wrote:
| OS in JS, ok I am interested now...
| asveikau wrote:
| > 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.
| gwbas1c wrote:
| 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.
| asveikau wrote:
| > I vaguely remember hearing about someone trying to use
| .Net in the Windows kernel.
|
| Microsoft did that, it was called Longhorn. That release
| cycle was long delayed and they abandoned most of its
| ambitious projects, especially C# in the kernel, and the
| result was Windows Vista.
|
| GC was not the only reason for the failure of that project.
| Someone could write a book about it. A lot of it was
| actually more about the organization of people. I also had
| heard from insiders that lack of ahead of time compilation
| was an issue. The other issue I remember hearing about was
| a complaint that Windows components were not layered
| cleanly and they ended up with circular dependencies when
| they tried to rewrite them.
|
| I think it's possible to write a kernel with GC, and to
| still be judicious about memory usage with a GC language.
| And I say that as someone who happens to think that a big
| issue with modern software is that too many programmers are
| spending their whole education and career to depend on GC
| without thinking about it carefully. That is to say I'm
| already a skeptic of high-level languages and GC, but I
| will still afford that it is technically possible.
| anonymars wrote:
| > trying to use .Net in the Windows kernel.
|
| > Microsoft did that, it was called Longhorn
|
| Do you have any reference for that? Or are you confusing
| Longhorn with Singularity (https://en.wikipedia.org/wiki/
| Singularity_(operating_system)) / Midori (https://en.wiki
| pedia.org/wiki/Midori_(operating_system))?
|
| I suspect you're referring to the shell/internals,
| though, not the kernel (https://longhorn.ms/the-
| reset/#:~:text=Why%20start%20over,re...)
| asveikau wrote:
| My source for that is I was on the Windows team at
| Microsoft from 2008-2011. I learned a bunch of this
| history from talking to coworkers who were there. I
| specifically recall people talking about c# in the
| kernel.
| danudey wrote:
| Another part of it was, IIRC, that Longhorn was based off
| of the Windows XP core, i.e. the non-server stuff. While
| the Windows Server development continued apace, with lots
| of security and hardening to make for a reliable OS to
| build upon, the Windows Non-Server team continued with
| the existing mess of a codebase, not prioritizing
| security features or stability in favor of trying to
| manage feature creep. Longhorn was meant as a stopgap
| between XP and 'Blackcomb', but a lot of Blackcomb stuff
| started creeping backwards, bogging them down.
|
| When security and reliability were suddenly key issues
| for Microsoft (to the extent that they ever were), it was
| obvious that what the Longhorn team had built was never
| going to meet that bar so they started over building off
| the Windows Server codebase instead.
|
| Most of this story I remember from a video on YouTube of
| that old guy who worked at Microsoft since forever and
| left around the time of the Longhorn debacle, but a lot
| of it is corroborated in the Wikipedia article as well. h
| ttps://en.wikipedia.org/wiki/Development_of_Windows_Vista
| leoedin wrote:
| 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.
| tracker1 wrote:
| Should be able to do similar with MicroQuickJS or maybe
| just QuickJS...
| tatskaari wrote:
| 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.
| Zambyte wrote:
| An OS doesn't need to have a user space :)
| monocasa wrote:
| You should be able to write a meta circular VM in JavaScript
| that targets bare metal without any C or asm.
| hajile wrote:
| 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...
| bayindirh wrote:
| This project will go places. Like every silly project not
| intended for production. :)
| faxmeyourcode wrote:
| 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.
| falcor84 wrote:
| Talking about quotes, I also absolutely loved this note at the
| end of the readme:
|
| > If this makes you grin, you are probably holding the torch.
| Smalltalker-80 wrote:
| Can't wait for browser support for this... ;-)
| monax wrote:
| Soon(tm)
| ruined wrote:
| webuefi has already been shipped by google for use on
| chromebooks. but mozilla and apple irrationally refuse to
| implement the standard for "security reasons"
| outadoc wrote:
| I love it.
| bwat49 wrote:
| Your scientists were so preoccupied with whether or not they
| could, they didn't stop to think if they should!
| fenwick67 wrote:
| Finally!
| lioeters wrote:
| Turning in the widening gyre, the falcon cannot hear the
| falconer. The center cannot hold.. The old prophecy is coming
| true.
| grougnax wrote:
| Awesome! Everything will be rewritten in JS
| GranPC wrote:
| "The Birth and Death of JavaScript" is coming true after all.
| marijnz0r wrote:
| I was going to post this as well! A direct link to the video:
| https://www.destroyallsoftware.com/talks/the-birth-and-death...
| rezmason wrote:
| It begins!
| dfedbeef wrote:
| Cursed
| ycombinatornews wrote:
| > If this makes you grin you are probably holding a torch
|
| Hilarious
| pwdisswordfishy wrote:
| 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.)
| monax wrote:
| Yeah floats works
| flopsamjetsam wrote:
| Floating point was not supported in the Linux kernel to avoid
| having to save/restore FP registers.
| rafram wrote:
| This is incredible.
| eqvinox wrote:
| > If this makes you grin, you are probably holding the torch.
|
| What if it makes me recoil in horror? _screams into the void_
| fnimick wrote:
| Oh hey, we've reached the "Metal" stage!
| https://www.destroyallsoftware.com/talks/the-birth-and-death...
| monax wrote:
| I'm doing my part [?]('-')
| ruined wrote:
| thank u 4 ur serves
| kiddico wrote:
| Thank you for the reminder to do my yearly viewing of that
| video lol
| epistasis wrote:
| Whoa, I haven not been following ASM.js stuff in any detail.
|
| Seeing that Metal replaces kernel/userspace boundaries with VM
| protections for memory, meaning that system call overhead is
| eliminated, at the price of ASM/VM overhead.
|
| What a fascinating idea. Kidding on the square...
| p0w3n3d wrote:
| I don't know if it's only me, but did this guy... Did this guy
| make a huge mistake?
|
| I think he was trying to bend reality with words. I can see
| many apps that are running in electron on my laptop, each
| consuming 300MB+ (e.g. Spotify), while many other apps are
| written in native Swift for example, especially with the help
| of AI, giving the best performance possible...
|
| Edit.
|
| And prices of RAM nowadays...
| pwdisswordfishy wrote:
| Those apps are not consuming 300MB of RAM because they are
| written in JS. JS is running on microcontrollers and the
| James Webb Space Telescope.
|
| They are consuming 300MB of RAM because they are built on
| Electron and the NPM ecosystem.
| Decabytes wrote:
| 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
| vaylian wrote:
| 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.
| sanufar wrote:
| 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
| fnimick wrote:
| Who needs to garbage collect? Just leak memory until the system
| dies! That strategy seems to be good enough for claude code,
| anyway.
| cluckindan wrote:
| If it's good enough for missile guidance systems, it's good
| enough for me.
| xp84 wrote:
| I don't have real context here, but I can imagine that a
| platform where the hardware costs millions of dollars, will
| be booted up in "Production" exactly once, and is
| guaranteed to be physically destroyed before it hits 1 day
| of uptime, just "Give it 128GB of RAM and YOLO (literally)"
| is great advice!
|
| Note: 128GB of DRAM may add another million dollars to the
| build cost by 2027 at the current derivative of the $/GB
| curve
| cluckindan wrote:
| Context: https://devblogs.microsoft.com/oldnewthing/20180
| 228-00/?p=98...
| shepherdjerred wrote:
| It could be even better!
|
| https://en.wikipedia.org/wiki/Java_processor
| juancn wrote:
| This is both so impressive and cursed that I'm not sure how to
| feel.
| shevy-java wrote:
| 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.
| notpushkin wrote:
| > I have had wanted to access the filesystem via JavaScript,
| just as I do via ruby or python
|
| There are some (limited) ways to do so now:
| https://developer.mozilla.org/en-US/docs/Web/API/File_System...
|
| As for (1) vs (2), it's not really an issue of JavaScript at
| all. The main question is, do you want to build something that
| runs in a browser? If you're building a web app, you'll have to
| use the sandboxed APIs (and probably JavaScript). If you don't
| care about the runtime, yeah, you can use Node or Bun or Deno
| (or use another language altogether).
| DJBunnies wrote:
| Try webkitdirectory file attribute for browser access to the
| file system.
| watermelon0 wrote:
| You are missing one option:
|
| 0) JavaScript must be abolished from the browser
| pwdisswordfishy wrote:
| > I googled for a while, they would say that this is not
| possible unless one uses npm/node
|
| Gnome Shell and Firefox/SeaMonkey/Mozilla Application
| Suite/Netscape 6+ (and Zotero[1]) are implemented on top of
| SpiderMonkey.
|
| 1. <https://news.ycombinator.com/item?id=46735616>
| tracker1 wrote:
| I've been using Deno a _LOT_ for general shell scripting... it
| 's been pretty nice in general. FWIW, Node, Bun and Deno have
| FS interfaces in the box, so yes, you can do it without npm
| modules. Though Deno allows you to directly reference the
| modules/repos from the script without needing a separate
| install step, package.json or node_modules directory.
|
| It's also a single, self-updating executable and includes a lot
| in the box. Including SQLite3.
| raphaelmolly8 wrote:
| The choice of Duktape here is smart -- it's one of the few JS
| engines that can actually run freestanding with minimal libc
| stubs, since it was designed for embedding in constrained
| environments. V8 or SpiderMonkey would be a nightmare to get
| running pre-boot.
|
| What I find most interesting is the UEFI services binding
| approach. Rather than trying to abstract away the hardware, it
| exposes the raw EFI protocols (GraphicsOutput, SimpleFileSystem,
| etc.) directly to JS. That's a much more pragmatic design than
| trying to build a full HAL -- you get to prototype UEFI
| applications rapidly while keeping the escape hatch to C for
| anything performance-critical.
|
| Would love to see if anyone tries hooking this into UEFI's built-
| in network stack for PXE boot scripting. That could actually be
| useful beyond the novelty factor.
| written-beyond wrote:
| Are em-dashes really that common to use or did I just start
| noticing them after LLMs became popular for rewriting comments?
|
| Not implying your comment is LLM generated, clearly it isn't
| but asking as a genuine question.
| Kerrick wrote:
| Pretty dang common. OS X and macOS (and maybe iOS and iPadOS,
| though I'm not certain) have been autocorrecting "--" into
| "--" for over a decade. Windows users have been using Alt
| codes for them since approximately forever ago:
| https://superuser.com/q/811318.
|
| Typography nerds, which are likely overrepresented on HN,
| love both em dash _and_ en dash, and we especially love
| knowing when to use each. Punctation geeks, too! If you know
| what an octothorp or an interrobang are, you 've probably
| been using em dashes for a long time.
|
| Folks who _didn 't_ know what an em dash was by name are now
| experiencing the Baader-Meinhof phenomenon en masse. I've
| literally had to disable my "--" autocorrect just to not be
| accused of using an LLM when writing. It's annoying.
| geocar wrote:
| [?]- produces a - as well. That's sometimes easier than
| typing `--` and hoping for the best.
| ziml77 wrote:
| That's an en-dash. You want to also hold shift to make it
| an em-dash.
| xp84 wrote:
| It really is. We dash-users are the real and most important
| victims of the AI revolution. I hope someday our story will
| be told (by the machines)
| smetannik wrote:
| Cursed, but fun
| moffkalast wrote:
| >boot sector
|
| >looks inside
|
| >node modules
| IshKebab wrote:
| Javascript is a horrible choice but I think having a scripting
| language for this is actually quite a good idea. If only there
| was a popular scripting language that didn't totally suck balls.
| fennec-posix wrote:
| good. god.
| javascriptfan69 wrote:
| Beautiful
| iberator wrote:
| Finally I will be able to have graphical bootup logo like in The
| Hackers?
___________________________________________________________________
(page generated 2026-02-09 23:00 UTC)