As a bit of a gag, I’ve made a graphical IRC Client that runs entirely in the UEFI preboot environment. It features completely overdone features such as TrueType fonts, a cursor, and GUI decorations.
I first started this project as I was getting a bit tired building a from-scratch GPS receiver, and wanted to make something relatively quick and lighthearted. As tends to happen, this took a fair bit longer than I anticipated at the outset!
A fair chunk of that time was spent on the visualisations in the post showing how scroll views are modelled and how they’re rendered to a static viewport. I really hope you enjoy them!
When I first began wanting to "stuff something in UEFI that really shouldn’t be in UEFI", my first instinct was a Twitter client. As it turns out, someone has already done a great job making this by using UEFI’s HTTP protocol! I therefore decided that whatever I made shouldn’t use HTTP at all, because that’s taken. I went with IRC since it sits on top of TCP and has the same social media feel that doesn’t belong anywhere near a preboot environment.
Looking forward to ditching these bloated operating systems with all this cruft I I do not need for something smaller and simpler: UEFI. Not to mention faster startup. Easier "embedded" development.
Of course I am joking. Sort of.
As a minimalist I do not need a GUI or a mouse. It seems UEFI already has more than I need.
I would contend that software too large to cram into UEFI is all superfluous bloatware anyway. In my day, we had dual 360k floppies and that was plenty!
I've had an idea percolating in my mind for a while: Would it be possible to have VPN credentials stored in UEFI, and have a system reach out to a server for PXE network boot?
It seems like it would be a neat way of (securely?) allowing a remote system to automatically recover in the event of a nuked install that prevents proper bootup.
Actually, all it takes on modern hardware for PXE boot to occur on hardware failure is the BIOS boot order setting.
As PXE inherently trusts the LAN, and a LAN may have VLAN support, you can assign a default VLAN to the port which equates to the PXE server you want.
The PXE server can further configure by client MAC prefix, DHCP-assigned IP mapped to physical port number or similar. Configured systems can report status and/or other hardware identifiers to a server after installation and have default VLAN changed by the network fabric (more secure), or can actively request to join alternate VLANs (less secure).
With PXE, any information can be fed to the machine, not just VPN credentials.
This is how a lot of clusters are built, especially diskless (for CPU-bound operations) in this era of more-RAM-than-you-can-use.
All of the above should work with IPMI ports if the controller is flashed with PXE-enabled firmware.
Not OP, but what is much simpler is buying a motherboard with IPMI and placing that behind a VPN. If you cannot afford the couple hundred extra bucks for the motherboard, then a USB stick with minimal Linux setup + SSH and then doing a kexec from that is another option.
I am really glad to hear that there's interest, and hopefully I will have a 3-part series to share on this some time soon! Similar to Andrew's project linked down below, this is a 'true' home-brew receiver. I didn't know anything about DSP, etc, when I started out, so I learned a lot about signal processing (and the incredible techniques that make GPS work), and really hope I'll be able to publish it all soon!
Not OP, but in the meantime this may help alleviate your thirst for "how could someone do GPS from scratch", especially the end parts about radio signals and encoding: https://ciechanow.ski/gps/
I never seen an IRC server that only support SSL.... I don't use many networks nowadays though... I only know of one channel that supports encrypted DCC transfers though.
I think it also emphasizes the complexity and capability of software that underlies the systems most people think about. I think it is a common misconception that your OS is the "lowest level" of the software stack, but in actuality, there is this firmware-ish code that truly owns your system. Sometimes it does a job and goes away, other times stays running the whole time your system is up, transparent even to the OS.
Sometimes, the attitude people have about this is along the lines of... "who cares, its just low level code to get my devices running, nothing serious can happen down there".
But knowing that you can get a whole IRC client down there doesn't make it too hard to imagine all the other nefarious things that could go on.
This is the spirit I come to HN for. Thank you for sharing.
> The most frightening realization hit me: there wasn't any reason behind what I'd done. I mean, I knew why I'd done it - I just did it because it would be fun. But I knew they would ask, "Why the hell did you do this?" and if I didn't have a good enough reason, they would probably throw me into a mental institution." -- Boyd Rice
This is super cool. Had no idea UEFI APIs were so readily-available and well-documented. Awesome work! Out of curiosity, what was the dev cycle like? I assume you were running the thing in a VM. Did you have to "boot up" every time you wanted to run the client?
The other commenter is correct that the work loop typically revolved around booting a QEMU instance which ships my UEFI application. The main run script will regenerate an EFI filesystem that contains a fresh build of UEFIRC, then pass it to QEMU.
However, the overhead here can get a bit cumbersome when trying to build a GUI. I set things up such that the app could target either bare-bones UEFI, or a hosted environment that runs on my Mac. By flipping a build flag, my GUI toolkit would either draw directly to the UEFI-provided framebuffer, or would hook into my Mac's windowing system and receive/push events to that. You can see some of the overhead of this 'dual-target' approach in the app's entry point: https://github.com/codyd51/uefirc/blob/main/src/main.rs.
Nice! I would like to someday finish writing an OS for my IRC bot that is still running.
Maybe the most useless comment but: that non-linear mouse movement (aka acceleration) is the very first thing I turn off when I boot up a new OS. It literally hurts my hand somehow. For example linearmouse is free for Mac. For Windows you can just turn off acceleration. For Linux its easy, obviously.
Using mouse acceleration stops you from learning to map a distance traveled by the mouse to a distance on the screen. I do think its more efficient in the long run without it. Something I learned to do from gamers, and something I think all gamers still do for a good reason.
My main gripe with nonlinear mouse movenement is that it breaks learned behaviour if you do it faster. This is why most gamers use raw linear mouse data.
Because low-level applications like this were promised when UEFI was introduced, that's why. UEFI's creators went even as far as to dream of replacing the Linux-based Internet-only mini-OSes of some vendors which could be accessed by pressing a certain key during boot (though I don't remember what they were called).
Those were the quick view / quick boot festures that old Dell and the likes had. Usually booting into some bars ones productivity apps.
I did see a video on YT that did a deep dive into this. I beleive you are correct they were originally stripped down Linux or other custom OSes but then eventually switching to UEFI apps before falling okay of favor.
I think this might be the video you're talking about, in case anyone is also interested in a brief history of quick boot operating systems and UEFI: https://www.youtube.com/watch?v=ssob-7sGVWs
Nice writeup! This reminds me of the barebox bootloader April fools two years back, which will connect you to #barebox, when all other boot targets fail[1]. :-)
The focus there was on adding TCP support to barebox though and it lacks your nice GUI elements. Only interface was CLI (which can be drawn on top of EFI GOP when barebox is built as EFI payload).
Readit News
As a bit of a gag, I’ve made a graphical IRC Client that runs entirely in the UEFI preboot environment. It features completely overdone features such as TrueType fonts, a cursor, and GUI decorations.
I first started this project as I was getting a bit tired building a from-scratch GPS receiver, and wanted to make something relatively quick and lighthearted. As tends to happen, this took a fair bit longer than I anticipated at the outset!
A fair chunk of that time was spent on the visualisations in the post showing how scroll views are modelled and how they’re rendered to a static viewport. I really hope you enjoy them!
When I first began wanting to "stuff something in UEFI that really shouldn’t be in UEFI", my first instinct was a Twitter client. As it turns out, someone has already done a great job making this by using UEFI’s HTTP protocol! I therefore decided that whatever I made shouldn’t use HTTP at all, because that’s taken. I went with IRC since it sits on top of TCP and has the same social media feel that doesn’t belong anywhere near a preboot environment.
Seems to be quite the right place for me. How else would I get help on boot issues?
[0] https://ruexe.blogspot.com/
Of course I am joking. Sort of.
As a minimalist I do not need a GUI or a mouse. It seems UEFI already has more than I need.
Here is the Twitter client mentioned:
https://github.com/arata-nvm/mitnal
I've had an idea percolating in my mind for a while: Would it be possible to have VPN credentials stored in UEFI, and have a system reach out to a server for PXE network boot?
It seems like it would be a neat way of (securely?) allowing a remote system to automatically recover in the event of a nuked install that prevents proper bootup.
As PXE inherently trusts the LAN, and a LAN may have VLAN support, you can assign a default VLAN to the port which equates to the PXE server you want.
The PXE server can further configure by client MAC prefix, DHCP-assigned IP mapped to physical port number or similar. Configured systems can report status and/or other hardware identifiers to a server after installation and have default VLAN changed by the network fabric (more secure), or can actively request to join alternate VLANs (less secure).
With PXE, any information can be fed to the machine, not just VPN credentials.
This is how a lot of clusters are built, especially diskless (for CPU-bound operations) in this era of more-RAM-than-you-can-use.
All of the above should work with IPMI ports if the controller is flashed with PXE-enabled firmware.
Deleted Comment
(Also, it could be an extension)
I think it also emphasizes the complexity and capability of software that underlies the systems most people think about. I think it is a common misconception that your OS is the "lowest level" of the software stack, but in actuality, there is this firmware-ish code that truly owns your system. Sometimes it does a job and goes away, other times stays running the whole time your system is up, transparent even to the OS.
Sometimes, the attitude people have about this is along the lines of... "who cares, its just low level code to get my devices running, nothing serious can happen down there".
But knowing that you can get a whole IRC client down there doesn't make it too hard to imagine all the other nefarious things that could go on.
This is the spirit I come to HN for. Thank you for sharing.
> The most frightening realization hit me: there wasn't any reason behind what I'd done. I mean, I knew why I'd done it - I just did it because it would be fun. But I knew they would ask, "Why the hell did you do this?" and if I didn't have a good enough reason, they would probably throw me into a mental institution." -- Boyd Rice
Don't sell yourself short. There's a botnet C&C client project here!
OK the UI is a bit funny. :)
The other commenter is correct that the work loop typically revolved around booting a QEMU instance which ships my UEFI application. The main run script will regenerate an EFI filesystem that contains a fresh build of UEFIRC, then pass it to QEMU.
However, the overhead here can get a bit cumbersome when trying to build a GUI. I set things up such that the app could target either bare-bones UEFI, or a hosted environment that runs on my Mac. By flipping a build flag, my GUI toolkit would either draw directly to the UEFI-provided framebuffer, or would hook into my Mac's windowing system and receive/push events to that. You can see some of the overhead of this 'dual-target' approach in the app's entry point: https://github.com/codyd51/uefirc/blob/main/src/main.rs.
Parsing IRC messages also really doesn't need any accoutrements, so I developed those with a unit test suite running directly on my Mac - you can see part of that here: https://github.com/codyd51/uefirc/blob/main/src/irc/response....
Maybe the most useless comment but: that non-linear mouse movement (aka acceleration) is the very first thing I turn off when I boot up a new OS. It literally hurts my hand somehow. For example linearmouse is free for Mac. For Windows you can just turn off acceleration. For Linux its easy, obviously.
Using mouse acceleration stops you from learning to map a distance traveled by the mouse to a distance on the screen. I do think its more efficient in the long run without it. Something I learned to do from gamers, and something I think all gamers still do for a good reason.
I think you’d get a feel for it either way. Like how the throttle pedal in your car (probably) doesn’t map to a speed.
Because low-level applications like this were promised when UEFI was introduced, that's why. UEFI's creators went even as far as to dream of replacing the Linux-based Internet-only mini-OSes of some vendors which could be accessed by pressing a certain key during boot (though I don't remember what they were called).
I did see a video on YT that did a deep dive into this. I beleive you are correct they were originally stripped down Linux or other custom OSes but then eventually switching to UEFI apps before falling okay of favor.
The focus there was on adding TCP support to barebox though and it lacks your nice GUI elements. Only interface was CLI (which can be drawn on top of EFI GOP when barebox is built as EFI payload).
[1]: https://lore.barebox.org/barebox/20220401145902.GF4351@telli...