What if you have a very modern machine that is entirely UEFI-only, meaning it has no compatibility support module and thus no way of enabling a legacy BIOS mode? Well, install a CSM as an EFI application, of course!
CSMWrap is an EFI application designed to be a drop-in solution to enable legacy BIOS booting on modern UEFI-only (class 3) systems. It achieves this by wrapping a Compatibility Support Module (CSM) build of the SeaBIOS project as an out-of-firmware EFI application, effectively creating a compatibility layer for traditional PC BIOS operation.
↫ CSMWrap’s GitHub page
The need for this may not be immediately obvious, but here’s the problem: if you want to run an older operating system that absolutely requires a traditional BIOS on a modern machine that only has UEFI without any CSM options (a class 3-machine), you won’t be able to boot said operating system. CSMWrap is a possible solution, as it leverages innate EFI capabilities to run a CSM as an EFI application, thereby adding the CSM functionality back in. All you need to do is drop CSMWrap into /efi/boot on the same drive the operating system that needs BIOS to boot is on, and UEFI will list it as a bootable operating system.
It does come with some limitations, however. For instance, one logical core of your processor will be taken up by CSMWrap and will be entirely unavailable to the booted BIOS-based operating system. In other words, this means you’re going to need a processor with at least more than one logical processor (e.g., even a single-core machine with hyperthreading will work). It’s also suggested to add a legacy-capable video card if you’re using an operating system that doesn’t support VESA BIOS extensions (e.g. anything older than NT).
This is an incredibly neat idea, and even comes with advantages over built-in CSMs, since many of those are untested and riddled with issues. CSMWrap uses SeaBIOS, which is properly tested and generally a much better BIOS than whatever native CSMs contain. All in all, a great project.
This is very interesting work! I think all of my computers can already run legacy CSM BIOS out of the box, but I expect I’ll eventually run into machines where it’s no longer offered.
I don’t think I’ve ever experienced seabios running on bare medal. only in VMs. Makes me wonder about compatibility with motherboard features like lmsensors and cpufreq, etc. I’m also curious to see if the output of dmidecode is complete on a system running CSMWrap.
The project page lists some interesting caveats…
I guess seabios assumes there is a SMM.
Finally, I can install DOS and CP/M on my Macbook.
This is a neat solution, but seems to come with many caveats.
They also mention their VGA bios is incomplete, and it won’t be able to run DOS games on modern GPUs. Makes a bit of a sense, as they have to actually produce a generic VGA driver for mode setting, which does not exist in the original SeaBIOS (which depends on the VM ecosystem for graphics)
But otherwise will be immensely be more compatible with legacy operating systems, as QEMU actually tests this with ancient DOS. I’m not sure your latest Dell machine will bring up a rare DOS floppy to ensure their CSM is actually working.
sukru,
I suspect the problem probably has less to do with seabios not being able to provide a functional VGA BIOS and more to do with the fact that many DOS programs only used the mode setting function of int 10h and then bypassed the BIOS to access the hardware directly for performance reasons. Unless you are running in vm86 or protected mode to trap direct hardware access, software that tries to access VGA hardware that isn’t there obviously can’t work.
When I wonder about compatibility, it’s not the compatibility with DOS I’d be concerned about but rather the compatibility with the motherboard on the flip side of that. Like temp sensors/fan controls/etc. I don’t know that seabios can generically handle these things given that motherboards all use various controllers that the official BIOS was programmed to support.
Alfman,
As far as I can tell, their primary function is just letting INT 10 happen… and getting out of the way.
Except, they hide one of the cores, as INT 10 requires privileged access, and they cannot enforce it if you started Windows 95 or an DOS4WG game otherwise. (Essentially an “remote procedure call” across cores. That single core will then handle the interrupt… except VGA)
So, anything the existing software can do, this should be able to do automatically. If the DOS game or a Windows 3.1 driver knows how to talk to hardware, from their point of view this should be (almost) transparent.
sukru,
SeaVGABIOS ought to work for software that actually uses int 10h calls. What doesn’t work is old real mode DOS software that access hardware directly. A lot of DOS software did this.
I am curious why they went this route, but either way I think CWMWrap is running in real mode were restrictions aren’t a problem. SeaBIOS is free to implement int 10h any way it pleases, The article specifically says it has to do with software bypassing the BIOS and I believe it to be correct.
https://github.com/CSMWrap/CSMWrap
The reason “new” operating systems work, including linux and windows, is because they use “new” VESA BIOS modes that no longer rely on legacy VGA hardware to be implemented.
https://en.wikipedia.org/wiki/VESA_BIOS_Extensions
Alfman,
Having to hide a code, and doing remote INT 10 has to do with being unable to access System Management Mode (Ring -2) after firmware locks it down.
(Due to very obvious security reasons, that can be initialized only once)
Some of the features require BIOS always be present. They cannot just assume the OS will play “nice”. Hence they keep one CPU core “dark” from the OS, it never sees that one exists.
The VGA thing?
Yes, it is another matter. Not related, but also a shortcoming of this implementation. That can be fixed though, just needs a bit more code. (Can be a good challenge for an LLM).
(Update)
Since I don’t have deep knowledge on how this works, I asked Gemini to process a simple tutorial:
https://gemini.google.com/share/bb1ad2c4d9bc
It shows why and how that Inter-Processor-Interrupt works.
sukru,
VGA hardware can be accessed from any core, they all exist on the same bus.
I don’t follow why a core has to be disabled. Unfortunately the article offers no insight and my searches for specific answers in the project came up empty handed. Neither the OS nor SMM should require a core to be disabled.
I don’t think the problem is that SeaVGABIOS is missing functionality though. but that the graphics hardware itself is. As the article stated the problem isn’t applications using the BIOS, but rather those that access hardware directly, it makes perfect sense why this happens. There isn’t really a remedy for this short of using supervisory CPU features (ie VM86 and protected mode) to trap direct IO in the same way windows 3.x+ did when running DOS software in a window.
Alfman,
Yes it can
Since I/O operations are privileged, and BIOS normally does them through SMM.
Assume for a moment we have loaded Windows 95 through this “BIOS”. And it makes an INT13 call to access disk (no native 32-bit driver). The call will fail otherwise.
As the INT13 “BIOS” will live in unprivileged selector. (As Windows has full control of the actual protected memory and Ring 0)
Instead it packs the request in a data structure, and sends an interrupt to the dark core
EAch core in the CPU is (almost) entirely independent. So “BIOS” would be running this disk request without any restrictions.
(Yes this means, one core run Linux while another does Windows. It is not advices though)
And actual source of truth, the source code for that section:
https://github.com/CSMWrap/CSMWrap/blob/main/src/bios_proxy.c
sukru,
It doesn’t show me what your question was. Did you ask it about “BIOS emulation”? It’s running natively and we shouldn’t be talking about emulation at all. The article says this explicitly…
Gemini…
I know this to be not true, BIOS requests in general do NOT get routed to SMM. The fact that SeaBIOS can’t enter SMM is true, but hardware IO is done from ring 0 whether it’s BIOS services/OS drivers/or applications programming the hardware. None of these paths involve the use of SMM.
Did you prompt this? Honestly for me the “how” is much less interesting than the “why”. All cores share the same bus and can access the same hardware. You could implement a remote int 10h handler as described, but I can’t think of a rationale for doing it. The SMM lock down in the CPU, while true, is irrelevant for accessing VGA or any other hardware.
I tried to download source from the git repo to dig for clues, but it’s currently down.
I see various forums with users talking about instances of new GPUs that lack legacy BIOS support and old GPUs that lack EFI support.
https://forums.anandtech.com/threads/gpus-with-legacy-bios-support-how-do-you-know.2554926/
Apparently these aren’t that common, but if ever I do encounter it myself I might try to investigate it more thoroughly.
Alfman,
Again this is NOT about the VGA. It is a completely different issue.
It is not entirely about SMM either… But…
(The prompt was to analyze what is going on and how this was worked. Unfortunately I don’t save history… privacy reasons)
The why is there.
It is also at the top of the source file:
When the operating system is in protected mode, the “BIOS” needs to have some way of direct hardware access.
Traditionally this is done by SMM.
This extension does not have access to it, so it hacks it own version.
Technically, they could find some other way. But they have another major issue.
Seabios is 32-bits.
V86 is 16…
(I reserve the right to be completely wrong about this. I’m just reading the code at a high level)
Or maybe this is going to be cleaner, sorry for stretching it so long…
The Seabios module does not NEED what is currently inside SMM.
But it would be an ideal hiding spot. It is literally designed to hide things from OS
(Which includes 16-32 bit mode switch)
So, since it cannot have SMM, it emulates it the best way it can (with that dark code)
Thinking back, this is a good solution.
sukru,
Fascinating! It explains what they’re doing with the extra core.
Also…
https://github.com/CSMWrap/CSMWrap/releases
This is not for DOS applications running on bare metal, but rather DOS applications that are running under windows. In real mode, CWMWrap does proper thunking as one would expect (ie without the need for bios_proxy).
https://github.com/CSMWrap/CSMWrap/blob/main/src/x86thunk.c
But when windows takes over and enters VM86 mode, *windows* would normally become responsible for thunking back into protected mode or real mode. It looks like CSMWrap is making use of the hidden core to establish a communication channel with an unrestricted core existing outside of windows control Wow that’s sneaky. I don’t know why they needed access to full memory from VM86 mode. I suspect the proper way to do it would have been to use a VXD driver…
https://en.wikipedia.org/wiki/VxD
But heck, this is such a creative way to circumvent windows restrictions!
Edit:
The thing is I don’t see any evidence for this at all though.
Alfman,
https://en.wikipedia.org/wiki/System_Management_Mode
This is for example how BIOS manufacturers did legacy USB support among other things.
Again, IF Seabios had access to SMM, which is purpose built for this, they would not need to steal one core.
sukru,
System_Management_Mode…I am aware of what it is. My point was that I see no evidence whatsoever that Seabios needs it to support legacy hardware like VGA graphics. It’s not in the pipeline at all.
Just for clarity’s sake I think you should be saying “CSMWrap” rather than “Seabios”. Seabios itself touts System Management Mode as a feature:
https://en.wikipedia.org/wiki/SeaBIOS
I wanted to check the SeaBIOS source code to see everything it uses SMM for but the git repo is offline.
Alfman,
Once again this has NOTHING TO DO with VGA. It is a completely different issue.
(Sorry for using INT10 as exmaple. It was a coincidence)
My bad. I am not very used to this CSMWrap name, Seabios keeps coming to my mind.
You can’t find it there, there is only support for emulators (Qemu support):
https://github.com/coreboot/seabios/blob/master/src/fw/smm.c
This is where you’d find it for real hardware:
https://github.com/coreboot/coreboot/tree/main/src/cpu/x86/smm
And it does more or less the same thing as this dark core.
(Again, this is beyond my expertise to understand how exactly it is set up. But you can clearly see similar data structures to hide in that SMM section, using a 16->32 shim, etc)
Alfman,
I have to use this card.
Older BIOS’es … used to do this trick with SMM
Apparently, it is a very bad idea.
Today, there is something called x86emu
https://github.com/coreboot/coreboot/tree/main/src/device/oprom/include/x86emu
They use a full blown emulator to handle these calls.
Ooops…
(Asked Gemini how coreboot actually does this… And learned some more things today. I’m getting older)
sukru,
Clearly both CWMWrap and SMM are jumping between modes. The thing is that windows 3.11 and DOS both ran fine without needing SMM, True DOS and even windows compatible hardware has never needed SMM.
https://docs.system-transparency.org/st-1.0.0/docs/selected-topics/system-management-mode/
Therein lies the rub, contemporary hardware that is natively DOS compatible may be disappearing and this changes the situation. I can start to see why CWMWrap may be looking at hacks to try and emulate historic hardware to keep things working even though such hacks were not historically needed. SMM can provide emulation of hardware that’s since been dropped, the best example of this is PS/2 keyboard/mouse.
I have a feeling this was hastily posted. I am guilty as well, haha.
I vaguely remember hearing about emulating x86 real mode BIOS calls under protected mode to avoid thunking.
We don’t often think about it but the option ROMs on PCI hardware is typically hardcoded to x86, and by the miracle of emulation it can be supported on ARM.
Just as a bit of anecdotal evidence for your vga discussion.
I own a coreboot thinkpad X230 with the seavgabios and I couldnt install FreeBSD. The installer would only occupy a tiny corner of the screen and output distorted rubbish.
I am not sure what the status is now and I havent tried to update coreboot or latest freebsd (that was 2 years ago).
Also that same thinkpad boots qubes os and I get no text on the initial Xen load. Then after linux modesets, I get text and then plymouth.
So possibly something still is really missing there.
Shiunbird,
Yes, it would make sense if they had partial VGA hardware drivers only.
And… did you happen to check serial install? FreeBSD should install fine with a FTDI USB adapter.
That is now my QubesOS email/banking machine. I run FreeBSD on a W530 and a P1 Gen 4.