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