Re: [coreboot] REPLY: INT 13H

[Peter Stuge]

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

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  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

REPLY: INT 13H

[Philipp Stanner]

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.

REPLY: INT 13H

[Zoran Stojsavljevic]

> 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  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.

REPLY: INT 13H

[Peter Stuge]

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