[HN Gopher] An IRC client in your motherboard
___________________________________________________________________
An IRC client in your motherboard
Author : codyd51
Score : 192 points
Date : 2024-04-05 11:13 UTC (11 hours ago)
(HTM) web link (axleos.com)
(TXT) w3m dump (axleos.com)
| codyd51 wrote:
| Hi everyone!
|
| 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.
| myself248 wrote:
| 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!
| knodi123 wrote:
| Dual? Pffft.
| johannes1234321 wrote:
| > 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?
| molticrystal wrote:
| It would be an interesting experience to dcc somebody RU [0],
| run it from ram, and guide that person through diagnostics.
|
| [0] https://ruexe.blogspot.com/
| codyd51 wrote:
| Ha! I take your point.
| Ecoste wrote:
| I wanna know more about the from scratch GPS receiver
| Terr_ wrote:
| 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/
| thatcherc wrote:
| This is my favorite write up of someone truly building a
| GPS receiver from scratch:
| http://www.aholme.co.uk/GPS/Main.htm
|
| A real tour de force of DSP - really cool stuff, and well-
| written
| codyd51 wrote:
| Andrew Holme's receiver was a crucial resource in my
| journey! There were times when a sentence or two from his
| post unlocked an insight for me.
| codyd51 wrote:
| 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!
| nxobject wrote:
| I mean, UEFI apps don't _just_ have to be preboot environments
| - not with that attitude, at least!
| anthk wrote:
| Gopher it's easy, and you can read gopher://hngopher.com and
| gopher://magical.fish as starting points.
| backspace_ wrote:
| This does not include ssl support? How much does this limit the
| number of irc nets that you can connect to?
| ijijijjij wrote:
| 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.
| backspace_ wrote:
| Link-net comes to mind
| pred_ wrote:
| FYI: The site keeps crashing the tab in Firefox 115.7.0esr.
| bbarnett wrote:
| You should report it to Mozilla, nothing a site does should
| ever crash a browser.
|
| (Also, it could be an extension)
| hex4def6 wrote:
| This is extremely cool!
|
| 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.
| Jhsto wrote:
| 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.
| E39M5S62 wrote:
| https://docs.zfsbootmenu.org/en/v2.3.x/general/tailscale.ht
| m... . Connect to your bootloader via your Tailscale
| network, select your ZFS boot environment and kexec in to
| it, all through a 'pretty' TUI !
| contingencies wrote:
| 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.
| 1vuio0pswjnm7 wrote:
| 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.
|
| Here is the Twitter client mentioned:
|
| https://github.com/arata-nvm/mitnal
| badrabbit wrote:
| If this supports TLS, I would use it all the time.
| rdl wrote:
| Perfect for preboot botnets :)
| pram wrote:
| Amazing visualizations in the article, very impressive.
| codyd51 wrote:
| Thank you very much, I've spent a lot of time on them over the
| past week and am really pleased to hear that you enjoyed them!
| wngr wrote:
| I was really impressed when I clicked the reload button --
| inspiring attention to detail! How did you create those?
| codyd51 wrote:
| Wow, thank you so much! I made these using HTML canvases
| and TypeScript. I'm drawing everything in code, including
| the pixel art (which is defined in the source).
|
| The animations are made using a small animation system that
| I made for this post. This system has two useful
| properties:
|
| 1. It allows me to animate whatever property of the object
| I'm interested in (alpha, frame, etc).
|
| 2. It allows me to set up other work to be triggered when
| the animation has reached a certain completion threshold,
| which lets the animations flow into each other. This is how
| (for example) the grid lines 'cascade' in after each other.
|
| The 3D animations are also primarily HTML canvases, and I
| used Three.js to place them as textures in a 3D scene. I
| have some logic to map the coordinate system of the
| canvases to the 3D scene, so that I can draw the connective
| tissue between the canvases and run animations that operate
| on objects both on the 2D canvases and the 3D scene.
| themaninthedark wrote:
| As always, the relevant xkcd: https://xkcd.com/1782/
|
| I understand that BIOS had limitations but I still think that
| UEFI is way too much.
| dvt wrote:
| 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?
| speps wrote:
| QEMU can run UEFI apps
| codyd51 wrote:
| Thanks very much!
|
| 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: htt
| ps://github.com/codyd51/uefirc/blob/main/src/irc/response....
| anthk wrote:
| Now do a gopher client and head to gopher://hngopher.com
| Solvency wrote:
| This would be even better if it were a chat interface to ChatGPT
| so you could ask it troubleshooting questions next time your
| machine won't boot into OS.
| forgotpwd16 wrote:
| Considering there're ChatGPT IRC bots, can already do that
| indirectly.
| quesera wrote:
| But not on a pre-booted system!
| trhway wrote:
| I think we'll soon see a ChatGPT embedded in UEFI, and it will
| be solving boot issues on its own.
| quesera wrote:
| > _I told a friend I was making a joke project, then explained
| it. She said she wasn't sure when to laugh. I'm not so sure
| either._
|
| Don't sell yourself short. There's a botnet C&C client project
| here!
|
| OK the UI is a bit funny. :)
| r3trohack3r wrote:
| > "Why"? What kind of question is "why"?
|
| 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
| SuperNinKenDo wrote:
| I don't know whether to think this is awesome, or a horrifying
| demonstration of bloat in UEFI.
| toast0 wrote:
| I don't think this really demonstrates UEFI bloat. A tcp/ip
| stack from boot services is handy and useful for 'legitimate'
| network booting, not really bloat IMHO; pxe and undi is similar
| in a bios environment but ddoesn't necessarily come from the
| motherboard firmware. Access to input devices, such as keyboard
| and mouse is reasonable too. Graphical output seems reasonable
| too.
|
| And then everything else is stuff the author did or linked in.
| Where's the firmeware bloat?
| blueflow wrote:
| Sit back and relax. Make this project more popular. People will
| decide for themselves.
|
| You are right and it is already going your way, even if you are
| not seeing it yet.
| syngrog66 wrote:
| bad ideas are bad. even if one can do them
| ultra_nick wrote:
| Lol, this is great. You missed your chance to release it on 4/1
| though.
| a3f wrote:
| 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).
|
| [1]:
| https://lore.barebox.org/barebox/20220401145902.GF4351@telli...
| sunday_serif wrote:
| I love this!
|
| 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.
| imag0r wrote:
| I recall contributing to IRC client that was running inside a
| SoftICE debugger... but this is another level ;)
| Latty wrote:
| This instantly made me think of a recent video by the Cathode Ray
| Dude, talking about HP's 'email client' (read: Outlook Plugin)
| "QuickLook" which was a shipped product implemented this way:
| https://www.youtube.com/watch?v=ssob-7sGVWs (also goes into some
| even weirder stuff they did).
|
| This does the hard bit of networking that QuickLook skipped
| though.
| tomsmeding wrote:
| > Each time we draw a bit of graphical content to a scroll view,
| we first allocate the tiles necessary to display the
| corresponding visual area.
|
| I get the intent here, to avoid the issue of not knowing how
| large a buffer to allocate for your scroll view in the first
| place. But doesn't this still use way too much memory? Especially
| for something like an irc client, the scroll view will only grow
| as the program is used longer, and as such the number of tiles of
| rendered content will also only grow. You'll of course need to
| keep the textual history in memory, but that's _far_ smaller than
| the rendered screen contents.
|
| Proper GUI toolkits (disclaimer: I have worked with few, and only
| a little at that) handle this, I think, by not considering the
| scroll view a canvas to draw stuff on, but instead a thing that
| you can place _widgets_ on. Each widget has access to some data
| that allows it to re-draw its graphical content at some position
| on-screen, and the scroll view forgets rendered content far
| outside the visible area, and asks widgets to re-draw their
| content whenever they get scrolled onto the screen again.
|
| Of course, you could expect requests for even more over-
| engineering ;)
|
| Cool stuff! As someone else mentioned, you missed April 1st.
| codyd51 wrote:
| Yes, you're absolutely correct! The design here totally suffers
| from unbounded memory use if you draw onto a large canvas.
| (Restating parts of your comment for confirmation that this is
| also how I think about it.)
|
| To resolve this while maintaining the spirit of the design, I
| think two representations need to be kept: one for the rendered
| pixel data, and one 'out of band' representation (such as the
| textual data - you also highlighted this in your comment).
|
| The idea is that, when the pixel buffer memory gets too large,
| some of it can be dropped. When it scrolls back into view
| again, it can be repopulated by the secondary representation.
| What I don't like about this is how it doesn't feel like it
| generalises well - you always need to be able to store the
| secondary representation, and have code to redraw it.
|
| I think the concept you suggested is a really good one: just
| make sure everything that's drawn is its own 'encapsulated'
| widget with its own drawing logic, and you can ask it to render
| itself whenever that's convenient. I'm grateful for the input
| here, and think I will end up switching to this sort of
| approach in the future.
| paradox460 wrote:
| Makes me miss KillerNIC
| minusLik wrote:
| > "Why"? What kind of question is "why"?
|
| 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).
___________________________________________________________________
(page generated 2024-04-05 23:00 UTC)