A x64 OS #1: UEFI
kazlauskas.me
kazlauskas.me
I was really surprised to learn that it requires PE executables and Windows' custom x64 calling convention. I know it's just a small technical detail for booting ... but it's kind of scary that Microsoft had so much sway in the design of how our future PCs will boot =(
typedef struct _WIN_CERTIFICATE {
DWORD dwLength;
WORD wRevision;
WORD wCertificateType;
BYTE bCertificate[ANYSIZE_ARRAY];
} WIN_CERTIFICATE, *PWIN_CERTIFICATE;
typedef struct _WIN_CERTIFICATE {
UINT32 dwLength;
UINT16 wRevision;
UINT16 wCertificateType;
//UINT8 bCertificate[ANYSIZE_ARRAY];
} WIN_CERTIFICATE;
[1] http://www.uefi.org/sites/default/files/resources/UEFI%20Spe...
> PE is a modified version of the Unix COFF (Common Object File Format). PE/COFF is an alternative term in Windows development.
However, there's little information on its license (it says it's a standard currently developed by Microsoft, but that's about it). And COFF is pretty much the same, but older and developed by AT&T[1].
Still, compared to other Microsoft "products of old"[2], there's a surprising ammount of documentation and analysis into the PE format.
[0] https://en.wikipedia.org/wiki/Portable_Executable
[1] https://en.wikipedia.org/wiki/COFF
[2] I don't compare it to the newer open source stuff because it'd be unfair.
[3] https://msdn.microsoft.com/en-us/library/ms809762.aspx -- I was going to link a few other articles (some from the References section of Wikipedia) but most seem to be broken now. Still, there are some interesting paperes from digital forensics people that analyze in-depth the PE format, mostly for malware scenarios.
But even then, segmentation is not an issue.
32 bit Windows 10 is 4GB smaller than the 64 bit version. This matters on cheap tablets and netbooks that come with <32gb of MMC storage. I've heard that 32 bit OEM licenses are also slightly cheaper, but I can't find confirmation of that.
https://blogs.intel.com/evangelists/2015/07/22/why-cheap-sys...
I intentionally leave off the 32-bit compatibility with my FreeBSD systems, and it's lovely. Of course, it's so much easier there with everything being open source.
https://msdn.microsoft.com/en-us/library/windows/desktop/dd3...
Additionally Nano server does not have it.
Not sure if it is yet possible to remove from the desktop yet, but I'm doubtful.
On the contrary, I think it's an indictment of the industry that we still put effort in hardware into running ancient software and continue to burden the most widespread architecture in the world with 1970s nonsense when virtualization is the obvious solution.
Plenty of people want to run games for the 6502 architecture on their PCs, yet Intel would be out of their mind if they added a 6502 to the die. Why do we not treat the Intel 8086 the same way?
For example, AFAIK there's still no emulator that can correctly run the 8088 mph demo.
(There's also the fact that the 8088 MPH demo is not a particularly compelling use case, even if the hardware were present.)
I think the idea is that long mode can be fused off. IIRC there's some MS requirement that boxes that have 64-bit CPUs must use 64-bit Windows, so keeping 32-bit firmware and adding a fuse works around it for users who care.
I saw an example of booting from UEFI in Rust: http://blog.theincredibleholk.org/blog/2013/11/18/booting-to...
[1] For example:
* `u16` would now be: `const u16` * `int` is no longer a type. * `slice::as_ptr` is now a method, so using transmute to extract the pointer from a slice is probably not ideal. * `core` is a crate that includes things like transmute so you don't need to manually include rust intrinsics etc.
Is it okay that I fantasize about that?
The bios loads your kernel, and then you get out and do your own thing. And that's the advantage of it.
Haha oh if only. I've probably worked around more UEFI bugs than any other single individual, and I've still had to deal with more non-UEFI BIOS bugs in my life. BIOS provides no kind of standardised interface to the OS, and so every vendor built their own and every vendor fucked up at some point. UEFI means there's much more shared code than before, and we're definitely benefiting from that.
Not even that! It loads the first 512-byte sector of your boot disk and jumps to it in 16-bit mode. Usually that bit of code loads in a few more sectors (using BIOS disk IO calls), enough to load a real bootloader's image (like GRUB), which subsequently understands your filesystem and loads the real kernel.
It's kind of a hack but I completely agree, much better to leave it in the hands of the systems developer -- firmware that tries to do too much often just gets in the way.
Unless it fits in 512 bytes this is not a "kernel" but is just instructions to jump to another address, where there is more small bootstrap code that loads another program, maybe a bootloader that loads another program, maybe a kernel.
Those who multiboot Windows with some other OS that uses disklabels may notice that Windows expects to always be the first OS. Any other bootstrap code put into that first sector will be overwritten by a Windows install.
http://appleinsider.com/articles/11/07/20/new_macbook_airs_m...
Does anyone know why the references to the original threads (through Google Groups) don't work anymore? Did Google Groups stop carrying the content or can't they search by Message-ID anymore?
If it is only used as a "BIOS" then is it unreasonably adding the surface area for bugs and attacks? Is it much larger and more complex than legacy BIOS?
Is this trade-off proportional to the benefits it provides: obviating need to for developers to understand backwards compatibility?
As much as people like to rag on it, UEFI provides a lot of benefits:
- UEFI graphics firmware improves compatibility, and makes things like PCI pass through of GPUs to virtual machines much easier/possible.
- UEFI allows for much faster boot times by cutting out a lot of 16-bit mode/32-bit mode transitions that BIOSes generally used.
- Every operating system doesn't need to fight over the master boot record of your drive, with UEFI they can live in relative peace.
- Things that were simply impossible with a lot of BIOS implementations (e.g. Booting off > 2TB hard drives) are now possible.
It's over-engineered, but so is ACPI (IMO To an even greater degree). Does anyone want to return to the old plug-and-play compatibility mess?
In my experience, those who like to rag on UEFI, for whatever problem they deem it to suffer from, are rarely interested in providing other options or solutions to the problems UEFI provenly solve.
They've got XML
But yeah, the solutions to a problem with a system don't come from the people who hate its guts and won't touch it: It comes from people who use it, need its functionality, and need those warts fixed.
It doesn't stop my processor from reliving the history of x86 every time it boots.
https://github.com/tianocore/tianocore.github.io/wiki/EDK_II...
Looks like seabios is (mostly) happy being a bios (with possible plans to be packaged as an "csm application" (I'm guessing that means being loaded from efi)). But, s far as I can tell, for a free/open uefi toolkit, tianocore is the project to look at.
I'm a little disappointed that I couldn't easily find a ready-to-run uefi space invader or tetris clone... ;)
[ed: eh, I see tfa links to tianocore's ovmf code for vms... Oh, well... ]
Right now it seems we get into a whole lot of problems because we have the OS sitting on the same RW space as user files and programs.
What would be the negatives to this approach?
I have been doing this for many years and have still not found any.
Currently I prefer RO space embedded in the kernel for the "core" OS and mfs/tmpfs overlay for a RW, larger "additional" OS.
If RW portion crashes, the system falls back to the RO portion.
But i was thinking about having the initial OS sit on an actual ROM chip with a flash chip next to it on the same board/die.
At least there is a valid, but hard to compile and deploy reference implementation.
It is funny that CSM mode is so much more polished and tested than pure UEFI one. And that so many cards still do not provide compatible firmware.
But since "huehuehue" sounds like a really crazy laughter to English speakers, when English internet culture clashes with Brazillian internet culture, this "huehuehue" really stands out to English speakers and seems hilariously overused.
As a result, English speakers have started jokingly immitating it and it turned into a meme of sorts.