One question: they keep referring to the “Intel® 64” architecture. I’ve only ever seen this be called the “AMD 64” architecture (with the tag amd64), I believe that is because AMD is the one that came up with it (as Intel was pursuing Itanium, which failed). Am I missing something here? Are they referring to the same thing?
Intel 64 is what Intel eventually named their version of AMD’s “AMD64” architecture (since 2006, ~7 years after AMD published AMD64). Intel 64 and AMD64 are nearly the same thing, but there are various small differences plus vendor specific extensions.
Tagged with ‘api’ as this about an interface between software and hardware.
I have mixed feelings about this, mostly bad. I do think that efi was handled about as well as it possibly could have been, and that it succeeded in preserving many of the desirable features of the pc platform (which other platforms do not seem to have succeeded in replicating). But I don’t really see the value proposition, I don’t like the compatibility break in return for so little, and I fear microsoft will try the whole locked-down-secure-boot thing again.
I’m sure that if I made cpus, I would jump at the chance to rip out the legacy, though. But come on. There are far bigger problems you could solve with a ‘minor’ (admittedly still larger) compatibility break (crap encoding, strongly-ordered memory accesses, coherent i$ come to mind, plus a host of smaller ones like page size and dirty high half state).
Seems like you missed the idea completely. Removing legacy booting support has an impact on BIOS and a very small part of OS bring-up code (massively simplifying both) with no impact on userland at all. Changing the ISA or, god forbid, the memory model throws away everything IA has going for, all the legacy userland software.
My last sentence was a throwaway; no particular significance was meant to be attached to it.
Removing legacy booting support has an impact on BIOS and a very small part of OS bring-up code (massively simplifying both)
For an operating system which is already using efi, the changes required should be minimal or nil.
no impact on userland
It was pointed out to me that the removal of rings 1 and 2 and of i/o ports is likely to impact certain legacy drivers that were heretofore ‘portable’ (in that they relied on stable operating system interfaces). I would wager this is not too significant, but it is there. i/o ports can be emulated by trapping, though this is obviously pretty sucky.
Rings 1 and 2 don’t exist in Long Mode, so those legacy drivers haven’t worked on modern OSes in well over a decade if they ever existed in the first place (Linux didn’t use rings 1 and 2, and as far as I know neither did NT).
Looks like you are correct: the AMD systems programming manual chapter 2.2.3 says “Only the L (long), D (default size), and DPL (descriptor-privilege level) fields are used by the processor in 64-bit mode. All remaining attributes are ignored.” The DPL is “descriptor privilege level”, aka access control for ring 0-3, and I can’t find anything talking about their range of options being restricted in long mode.
However looking at Linux 6.3 code, comments in arch/x86 state that ring 1 and ring 2 are unused. Wikipedia handily cites this book (from 2005) stating that Windows does the same. So it seems pretty safe to say that any drivers that use ring 1 and 2 are almost certainly misbehaving anyway, not relying on stable operating system interfaces.
It turns out my understanding was wrong, and you are 100% correct. I checked the AMD system programming manual only to find that the DPL bit is not ignored for code segments (although it is for data segments; instead the DPL from CS is used). I’m not sure why I was under this impression, maybe I conflated it with paging only distinguishing between user/kernel (Rings 3 / Rings 0-2) rather than the full range of privilege levels.
One question: they keep referring to the “Intel® 64” architecture. I’ve only ever seen this be called the “AMD 64” architecture (with the tag
amd64), I believe that is because AMD is the one that came up with it (as Intel was pursuing Itanium, which failed). Am I missing something here? Are they referring to the same thing?Intel 64 is what Intel eventually named their version of AMD’s “AMD64” architecture (since 2006, ~7 years after AMD published AMD64). Intel 64 and AMD64 are nearly the same thing, but there are various small differences plus vendor specific extensions.
Tagged with ‘api’ as this about an interface between software and hardware.
I have mixed feelings about this, mostly bad. I do think that efi was handled about as well as it possibly could have been, and that it succeeded in preserving many of the desirable features of the pc platform (which other platforms do not seem to have succeeded in replicating). But I don’t really see the value proposition, I don’t like the compatibility break in return for so little, and I fear microsoft will try the whole locked-down-secure-boot thing again.
I’m sure that if I made cpus, I would jump at the chance to rip out the legacy, though. But come on. There are far bigger problems you could solve with a ‘minor’ (admittedly still larger) compatibility break (crap encoding, strongly-ordered memory accesses, coherent i$ come to mind, plus a host of smaller ones like page size and dirty high half state).
Seems like you missed the idea completely. Removing legacy booting support has an impact on BIOS and a very small part of OS bring-up code (massively simplifying both) with no impact on userland at all. Changing the ISA or, god forbid, the memory model throws away everything IA has going for, all the legacy userland software.
My last sentence was a throwaway; no particular significance was meant to be attached to it.
For an operating system which is already using efi, the changes required should be minimal or nil.
It was pointed out to me that the removal of rings 1 and 2 and of i/o ports is likely to impact certain legacy drivers that were heretofore ‘portable’ (in that they relied on stable operating system interfaces). I would wager this is not too significant, but it is there. i/o ports can be emulated by trapping, though this is obviously pretty sucky.
Rings 1 and 2 don’t exist in Long Mode, so those legacy drivers haven’t worked on modern OSes in well over a decade if they ever existed in the first place (Linux didn’t use rings 1 and 2, and as far as I know neither did NT).
Do you have a reference for that? It was not my understanding, and I can find no mention of it in vol 3, chap. 5 of the intel sdm.
Looks like you are correct: the AMD systems programming manual chapter 2.2.3 says “Only the L (long), D (default size), and DPL (descriptor-privilege level) fields are used by the processor in 64-bit mode. All remaining attributes are ignored.” The DPL is “descriptor privilege level”, aka access control for ring 0-3, and I can’t find anything talking about their range of options being restricted in long mode.
However looking at Linux 6.3 code, comments in
arch/x86state that ring 1 and ring 2 are unused. Wikipedia handily cites this book (from 2005) stating that Windows does the same. So it seems pretty safe to say that any drivers that use ring 1 and 2 are almost certainly misbehaving anyway, not relying on stable operating system interfaces.It turns out my understanding was wrong, and you are 100% correct. I checked the AMD system programming manual only to find that the DPL bit is not ignored for code segments (although it is for data segments; instead the DPL from CS is used). I’m not sure why I was under this impression, maybe I conflated it with paging only distinguishing between user/kernel (Rings 3 / Rings 0-2) rather than the full range of privilege levels.