[coreboot] REPLY: INT 13H

[Zoran Stojsavljevic]

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 at 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 at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170831/8a46a1a4/attachment-0001.html>