Zoran, Vincenzo,
BIOS and UEFI have higher privilege in the system than the OS kernel, which has higher privilege than userland processes, which have higher privilege than the user.
Any component with higher privilege can override, circumvent or contradict parts of the system and users with lower privilege levels.
BIOS is x86-specific.
UEFI is arguably not technically superior to BIOS.
UEFI has sadly infected other platforms than x86.
Interrupt services were introduced with the BIOS, and will continue to always be available on x86 platforms, for compatibility. Compatibility is the only actual value of x86.
UEFI on x86 does not neccessarily have to, but in practice generally does include a CSM, which provides BIOS-compatible interrupt services also on systems with UEFI.
Regardless of whether that's a 32 or 64 bit UEFI, the CSM always provides the legacy 16 bit interface.
Vincenzo, if you are creating a secure system, you must first establish what is secure *enough* for your use case. Risk assessment and a threat model are essential, or you will never reach a working reliable system, because they define your goal.
Security issues can exist pretty much everywhere, so an "ideal" secure system is not very practical.
//Peter
Hello Peter,
This is the main point of x86 architecture, since this PC XT compatibility went too far. INTEL tried to get rid of it, introducing ITANIUM architecture, written from scratch (considering BSP), but as I know, this project did not succeed, in the sense that this initiation of BSP did not continue.
So, INTEL and the whole x86 architecture (do not forget, there are other companies producing their own x86 silicon beyond INTEL and AMD) fell back to this compatibility trap.
Contrary to your visions (my opinion differs regarding UEFI), UEFI is one very good attempt to get again rid of these legacy INT mechanisms in BIOS. YES, for the sake of compatibility and older platforms' maintability, Compatibility Support Mode still exists in modern UEFI. But, for example, I always pushed all INTEL consumers to start using UEFI. Since, I know that for UEFI vBIOS is out, INT 15H is out, and there is a replacement for vBIOS (which lives till system shutdown), which is GOP, which lives ONLY while UEFI lives. Then modern GFX (NOT based on legacy INT) is taking place.
*And you are correct: for the embedded creations, UEFI is not an option. I have no idea about Vincent's (Zimmer) latest minimalistic UEFI (since I am busy after all with many other things). Would be nice to have this one for INTEL silicons, which, maybe/hopefully, will push all this story beyond 16 bit compatibility crap, and end it forever! But FSP blobs, even in this case, will stay.*
For x86 technology in Embedded World (for now) I see no good BSP representative. since we know all about blobs (FSP), since INTEL will NOT release its own set of BSPs' IPs. This is my final conclusion. So, we are trapped with INTEL, somehow, Present Time!
The World Wide workaround, coming suddenly in the theaters near us is the End of Moore's Law era, which INTEL took most of the benefit for last 50 years. Now, we see that TSMC, Foundry and Samsung are working on 7nm technology, adopting litography machines to EUV(L). And... INTEL lost/is loosing tech advantage.
How future boot-loaders will look like, depends upon who will lead eWorld, and, to me seems that it'll be ARM. For mobile portable devices (mobile PCs, tablets)... The battle is on-going, with Coreboot (seems at least to me) clearly taking ARM side.
The only certainty for next 5 years is that server space will stay as is... If some company, ARM based, does not invent comparable silicons to INTEL Xeon families.
Well... IMHO.
Zoran
On Wed, Aug 30, 2017 at 2:54 PM, Peter Stuge peter@stuge.se wrote:
Zoran, Vincenzo,
BIOS and UEFI have higher privilege in the system than the OS kernel, which has higher privilege than userland processes, which have higher privilege than the user.
Any component with higher privilege can override, circumvent or contradict parts of the system and users with lower privilege levels.
BIOS is x86-specific.
UEFI is arguably not technically superior to BIOS.
UEFI has sadly infected other platforms than x86.
Interrupt services were introduced with the BIOS, and will continue to always be available on x86 platforms, for compatibility. Compatibility is the only actual value of x86.
UEFI on x86 does not neccessarily have to, but in practice generally does include a CSM, which provides BIOS-compatible interrupt services also on systems with UEFI.
Regardless of whether that's a 32 or 64 bit UEFI, the CSM always provides the legacy 16 bit interface.
Vincenzo, if you are creating a secure system, you must first establish what is secure *enough* for your use case. Risk assessment and a threat model are essential, or you will never reach a working reliable system, because they define your goal.
Security issues can exist pretty much everywhere, so an "ideal" secure system is not very practical.
//Peter
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
On 30.08.2017 14:54, Peter Stuge wrote:
Compatibility is the only actual value of x86.
Hi, I was often wondering why they don't at least try to get rid of the *very* old stuff when it's not possible to get rid of the middle-old stuff.
It's understandable that it's necessary to provide a 32-bit-compatibility mode on 64-bit systems. It *was* understandable that it was necessary to provide a 16-bit-compatbility-mode then the first 32-bit-CPUs appeared. As far as I understood the Intel Programmer's Manual the CPUs provide a 16-bit compatibility-mode in 64-bit-long-mode...
I don't see a reason why it should be impossible to abolish Real Mode, Segmentation and basically everything beside Long-Mode and virtual 32 Bit-mode. The Operating-System-Manufactures would need a bit of time to change their operating systems to be able to start without BIOS calls and remove the procedures to set up the flat segmentation.
Intel is powerful enough to make this change I believe. The question is if they benefit from changing x86, making it more modern.
By the way we shouldn't forget that behind the legacy-compatibility-stuff and the microcode a very strong, efficient and modern RISC-machine is alive.
P.
I don't see a reason why it should be impossible to abolish Real Mode,
Segmentation and basically everything beside Long-Mode
and virtual 32 Bit-mode.
This is why: https://en.wikipedia.org/wiki/Itanium
The Operating-System-Manufactures would need a bit of time to change
their operating systems to be able to start without BIOS
calls and remove the procedures to set up the flat segmentation.
This is why: https://en.wikipedia.org/wiki/Itanium#Software_support
Best Regards, Zoran
On Thu, Aug 31, 2017 at 10:30 AM, Philipp Stanner stanner@posteo.de wrote:
On 30.08.2017 14:54, Peter Stuge wrote:
Compatibility is the only actual value of x86.
Hi, I was often wondering why they don't at least try to get rid of the *very* old stuff when it's not possible to get rid of the middle-old stuff.
It's understandable that it's necessary to provide a 32-bit-compatibility mode on 64-bit systems. It *was* understandable that it was necessary to provide a 16-bit-compatbility-mode then the first 32-bit-CPUs appeared. As far as I understood the Intel Programmer's Manual the CPUs provide a 16-bit compatibility-mode in 64-bit-long-mode...
I don't see a reason why it should be impossible to abolish Real Mode, Segmentation and basically everything beside Long-Mode and virtual 32 Bit-mode. The Operating-System-Manufactures would need a bit of time to change their operating systems to be able to start without BIOS calls and remove the procedures to set up the flat segmentation.
Intel is powerful enough to make this change I believe. The question is if they benefit from changing x86, making it more modern.
By the way we shouldn't forget that behind the legacy-compatibility-stuff and the microcode a very strong, efficient and modern RISC-machine is alive.
P.
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Philipp Stanner wrote:
As far as I understood the Intel Programmer's Manual the CPUs provide a 16-bit compatibility-mode in 64-bit-long-mode...
Every new CPU comes out of reset in 16-bit mode, just like 8086.
I don't see a reason why it should be impossible to abolish Real Mode, Segmentation and basically everything beside Long-Mode and virtual 32 Bit-mode.
The reason is millions if not billions of MS-DOS systems.
The question is if they benefit from changing x86, making it more modern.
I made this point before:
Compatibility is the only actual value of x86.
So in a word: No.
It can only hurt, potentially making the whole architecture obsolete.
//Peter
-
Peter Stuge -
Philipp Stanner -
Zoran Stojsavljevic