Usefulness of UEFI

[Gigasoft]

I don't see any reason they would remove real mode just to cater to people arguing that it is outdated and unnecessary. It will not make CPUs faster or cheaper but is surely going to cause a lot of negative press resulting from older operating systems no longer working. The logic required to implement real mode is such a small part of the chip design that it is just not going to save them any money.

Removing other "outdated" parts of the architecture, such as the x87 instructions, is even less likely as it will break a very large number of applications.

[mid]

I very much disagree. How exactly is segmented memory superior to paging? (Also, x86 may only have 48-bit to 57-bit memory addresses, but other architectures like RISC-V do not have that limitation but employ paging.) If segmented memory was so superior as you claim, every other architecture would use it. Clearly, that isn't the case at all.

Segmentation is a fantastic concept because it provides automatic runtime relocation that is transparent to the userspace program, along with bounds checking done by the hardware. x86 got it horribly wrong by only supporting 6 segment registers, not allowing immediate segments and making segment loads slow. It is x86's abuse that tainted the image of segmentation.

The runtime relocation is emulated sometimes today through what are called "handles" (implemented as double pointers usually), but as far as I'm aware no hardware optimizes these access patterns.

[bzt]

You'll be overriding the page tables anyway so there's no reason for them to discuss it in depth.

Yes there is a reason to discuss them, because you must use the UEFI provided paging tables in your loader before you call ExitBootServices.

Yes, it doesn't boot the APs in long mode because that would most likely break all the OSes out there that use SMP, so that's entirely unsurprising. The spec is not "badly designed" with SMP.

Incorrect! UEFI can boot up the APs into long mode, but you have to stop the APs before you call ExitBootServices. So what's the point of having MP Services? And what do you mean by "likely break all the OSes"? Explain! For existing OSes MP Services not needed, not initialized, no compatibility issues. New OSes could rely on MP Services if it weren't a boot service, again, no compatibility issues here either.

If we have to do this ourselves, then how exactly is UEFI helpful?...

What? No. No one said that.

Is there something wrong with your reading capabilities? This isn't the first time in this thread that you try to deny the existence of a post...

UEFI switches the BSP to protected or long mode for you where the BIOS doesn't. So UEFI being helpful here is a design flaw?

And I said yes, because it's not well-defined, so you have set up everything yourself any way, meaning it isn't helpful at all.

Funny how everyone but you manages it perfectly, then.

Funny that you can't comprehend what you read. I've said and I quote:

I've already did that, I know exactly how much work that means.
...
Writing a PIC kernel loader IS NOT EASY. 300-400 SLoC at a minimum, compared to that 8 SLoC that tutorial has right now. If you think 300 and 8 are the same magnitude, then I really can't help you.

Sorry, and no offense, but after it happened third time in a row, I must ask: is comprehending what you read really beyond your capabilities? Do you have some issues with reading? The only other explanation is that you're trolling, but let's not assume the worst.

Cheers,
bzt

[Gigasoft]

Oh, look, the troll asks if I'm trolling, how ironic.

While one can certainly consider the fact that applications start in protected or long mode as helpful and a welcome improvement over BIOS, your assumption that UEFI should therefore set up your page tables for you based on magical guesses does not follow and is completely unrelated to the post you quoted.

Writing a PIC kernel loader IS NOT EASY. 300-400 SLoC at a minimum, compared to that 8 SLoC that tutorial has right now. If you think 300 and 8 are the same magnitude, then I really can't help you.

Obviously, by position independent I don't mean the GCC -fPIC option, but I mean writing a function that does not reference any absolute symbols so that there is no need for any relocations at all. This is not rocket science.

[Ethin]

Yes there is a reason to discuss them, because you must use the UEFI provided paging tables in your loader before you call ExitBootServices.

Why? How exactly will that do you any good? Like I said, your going to replace them anyway, so there's no point. I strongly doubt that you'd need to know where your kernel is loaded. Because you really don't... And if yo usay that you do for APs, that's nonsense because you can literally create a static volatile global variable and, in your assembly routine, add a parameter to pass a pointer to that variable. Knowing where yoru kernel is loaded is only a luxury; you don't need to know where it is.

Incorrect! UEFI can boot up the APs into long mode, but you have to stop the APs before you call ExitBootServices. So what's the point of having MP Services? And what do you mean by "likely break all the OSes"? Explain! For existing OSes MP Services not needed, not initialized, no compatibility issues. New OSes could rely on MP Services if it weren't a boot service, again, no compatibility issues here either.

Now this is funny. What do you think I mean by "all existing OSes"? I mean just what I say! If UEFI booted all the APs into long mode, it would need to then return them to real mode when you called ExitBootServices(). And that just doesn't make much sense! (To be honest, I don't really see why you even have SMP in UEFI -- I can't really imagine where that would be useful unless you decided to write a web browser for it.)

Sorry, and no offense, but after it happened third time in a row, I must ask: is comprehending what you read really beyond your capabilities? Do you have some issues with reading? The only other explanation is that you're trolling, but let's not assume the worst.

Okay, this was just hilarious. You say that Gigasoft is trolling yet its you who's trolling. In case you've forgotten, to troll is to "make a deliberately offensive or provocative online post with the aim of upsetting someone or eliciting an angry response from them." Very, very few posts you've made on this thread don't fall under that heading. Judging by how you write, I imagine that English is not your native language, and that's okay; I don't judge yo ufor that. But you came in here and, as you do in every topic where UEFI is mensioned, started your little campaign to discredit it as much as possible and throwing out all sorts of misinformation, and when asked to prove it, you either acted as though the rest of us were idiots or little schoolchildren, and you talked down to us as though you were somehow our better, or you posted supposed "evidence" that wasn't actually evidence at all. And when that was pointed out to you, you deflected the question. So its no surprise that the majority of us are irritated with you, and that's all on you. Every time we try to explain something to you, you troll or you deflect our explanation and come up with more fud or tripe to justify your reaction. I'm no religious individual or anything, but by God, please, please either take your pointless campaign elsewhere, or provide us actual proof to your claims and actually contribute to the discussion at hand. And if your so much smarter than us, how about you go write your own firmware and sell it to us.
@rdos: What do you mean by separating parts of the kernel from one another? Do you mean something like separating kernel modules from one another? If so, you can technically do that by giving each module its own address space (or, if you want to do something unique, you could always write your kernel mods in a scripting language or web assembly and then execute them that way.) Yes, paging is different from segmentation, but there's a good reason its not used anymore. Its not just C compiler mis-design; I don't think blaming it on that makes any sense because the compiler isn't normally ever going to write to the segment registers (at least, I've never seen one do so). You'd need to blame every compiler for that. Segmentation is nice if it weren't for the fact that (1) it only works in PM and RM and (2) PM and RM can only address 4 GiB and 1 MiB of RAM, respectively. Memory addresses might be 32-bit for the majority of the time, but if you boot an OS on a computer with more tahn 4 GiB of RAM (like my laptop) your going to have larger addresses (for example, my computer can use up to about 35 bits). Plus, paging does have the advantage of not only allowing you to maintain multiple page tables if you want to, but isolating processes from one another. I imagine that would be harder in segmentation.

[kzinti]

Bzt is the king of trolls. I should have seen it before. He is sometimes capable of rational discussion as can be seen on some other threads. But here? Just pure trolling.

[Ethin]

Bzt is the king of trolls. I should have seen it before. He is sometimes capable of rational discussion as can be seen on some other threads. But here? Just pure trolling.

Yeah, definitely. To be honest I'm sad that this topic devolved into this. Oh sure, there's some useful discussion... But this topic could've been a lot more productive. Instead, we've got the king of trolls coming in here and trying to turn this topic into another place to spread his hatred and tripe. (Yeah, I call it hatred because I think that calling it anything less just doesn't cut it.)

[bzt]

Hahaha, really trying to paint me as the troll is your best? Don't embarrass yourself any more, why don't you answer my technical questions instead?

Prove that you aren't the trolls just by answering a few simple questions (if you can ):
@Gigasoft:

Obviously, by position independent I don't mean the GCC -fPIC option, but I mean writing a function that does not reference any absolute symbols

How do you plan to use LIDT and LGDT instructions then? Or load a new CR3? Or jump back to the loader code (or to the kernel code) from the AP trampoline when initialization finished?

@Ethin:

And you haven't answered the question at all, how could ExitBootServices detect where's the kernel code segment loaded into memory. Let's say it's loaded in an allocated memory region with type EfiLoaderData. It still only contains the raw segment, without any magic bytes, and you don't know it's actual VMA where it's going to be mapped.

I'm still waiting for your answer to that...

@kzinti:

That means UEFI does more for you than the BIOS does. UEFI switches the BSP to protected or long mode for you where the BIOS doesn't. So UEFI being helpful here is a design flaw?

How is it exactly helpful when you have to do all of that again anyway?

There is absolutely no relation whatsoever between starting up APs and the firmware.

What is MP Services then?

These are really simple questions, should be a no brainer for anybody with a little OSDev experience.

Cheers,
bzt

[kzinti]

This last reply of yours is an excellent example of trolling.

[bzt]

This last reply of yours is an excellent example of trolling.

So you admit that you can't answer to the technical questions, you're just posting personal insults instead.

Have a nice day,
bzt

[Ethin]

No, BZT, we're not admitting to being unable to answer your technical questions, we're just letting you dig your grave even deeper than it already is (your probably six feet deep already). I won't answer your technical questions because there's no point because you'll just try to be all superior on me. Your trolling. Pure and simple. How about you answer our technical questions first, hmmmm? I'm still waiting on that security certificate you don't have... And your proof for your security claims earlier in this thread...

[Gigasoft]

How do you plan to use LIDT and LGDT instructions then? Or load a new CR3? Or jump back to the loader code (or to the kernel code) from the AP trampoline when initialization finished?

Why are you making this out to be a problem at all? I quote from my OS startup code:

Code: Select all

mov ax,cs
movzx eax,ax
shl eax,4
add eax,offset _BSPGDT-0c0000008h
push eax
push 23
lgdt fword ptr [esp]
add sp,6
; [...] do various things, enter PM. Or, if loaded by UEFI, this is roughly the point where it begins.
push offset _BSPIDT
push small 2ffh
; [...] allocate pages for page tables and kernel, for example by asking UEFI
lidt fword ptr [esp]
add esp,6
; [...] setup page tables
mov cr3,ebx ; This address was dynamically allocated.
mov eax,80000021h
mov cr0,eax
mov edi,0c0000000h
mov edx,esi
mov ecx,[edx+12]
rep movsb ; move kernel to new location
add edi,4095
and edi,-4096
mov ecx,[edx+16]
rep movsb ; runtime library
mov ecx,[edx+20]
xor eax,eax
rep stosb ; uninitialized data
; [...] do more things
push offset _BSPGDT-8
push small 77h
lgdt fword ptr [esp]
add esp,6
; [...] do even more things
mov eax,offset _SystemEntry
jmp eax

There is nothing magical happening here. Although this happens to be written in assembler, it could just as well have been written in C++ with intrinsics for setting various control registers. At no point are relocations applied to any instruction.

AP trampoline:

Code: Select all

APParams struc
Lock dw ?
APGDTR dw ?,?,?
APCR3 dd ?
APIDTR dw ?,?,?
APESP dd ?
APParams ends

_APCodeStart:
mov bx,_APCodeEnd
assume bx:ptr APParams
mov ax,cs
mov ds,ax
apwait:
lock bts [bx].Lock,0
pause
jb apwait
mov esp, [bx].APESP
lgdt fword ptr [bx].APGDTR
lidt fword ptr [bx].APIDTR
mov cr3, [bx].APCR3
mov eax,80000021h
mov cr0,eax
jmp $+2
mov al,10h
mov ds,ax
mov es,ax
mov ss,ax
mov al,20h
mov fs,ax
xor ax,ax
mov gs,ax
mov al,30h
ltr ax
db 66h, 0eah
dd _APEntry
dw 8
align 2
_APCodeEnd equ $-_APCodeStart

[kzinti]

Why are you making this out to be a problem at all? I quote from my OS startup code

He's trolling, pure and simple. He is smart enough to understand this, but he will keep arguing because he needs the attention.

So you admit that you can't answer to the technical questions, you're just posting personal insults instead.

... and more trolling. It's not so much an insult as it is a fact. You continue posting evidence of it over and over. Everyone can see this for themselves.

[linguofreak]

I very much disagree. How exactly is segmented memory superior to paging? (Also, x86 may only have 48-bit to 57-bit memory addresses, but other architectures like RISC-V do not have that limitation but employ paging.) If segmented memory was so superior as you claim, every other architecture would use it. Clearly, that isn't the case at all.

It's C compilers that cannot handle segmentation properly, something that goes back to poorly designed memory models in the days of 16-bit code.

I think it has more to do with C itself than any specific compiler. C was simply designed on the assumption of a flat memory model (with the exception of the fact that it can handle separate code and data spaces).

Segmentation is superior since with a good design you can protect different parts of the kernel from each other, something that is impossible with flat memory models unless you go microkernel, and then you have huge inter-process communication delays instead.

Segmentation, as implemented on Intel, isn't flexible enough to allow microkernel-like isolation between parts of the kernel without performance penalties. You'd need either a reentrant version of the TSS mechanism, or some means of automatically switching between descriptor tables on a segment load.

Paging, in the absence of process isolation, doesn't solve the problems with flat memory models. Paging has too poor granularity and is per process, not per memory object as segmentation is. In a typical monolithic kernel, per-process means per-system since kernel memory is mapped in every process.

As segmentation is implemented on Intel, you're not going to get good enough granularity to do per-object isolation, there simply aren't enough descriptor table entries. And every architecture I've ever heard of that did try to support per-object isolation ended up being woefully underperformant. Not to mention that shifting and masking, as on a paging system, is a much faster way of doing virtual address lookups than adding your offset to your segment base and subtracting it from your segment limit. But I *am* of the opinion that we could do better than per-process isolation, and that we would benefit from a paging system that did not use a flat memory model. Modern processors tend to support Address Space IDs to allow switching between paged address spaces without needing to do a complete TLB flush, and you could simply have each segment register contain an ASID for a paged address space rather than a segment selector.

[rdos]

As segmentation is implemented on Intel, you're not going to get good enough granularity to do per-object isolation, there simply aren't enough descriptor table entries.

That's true. You need to compromise here to some degree. I typically have a code & data selector per driver, and so per driver data is protected from external access but not from internal missuse (except for exceeding the limit). Although, I do typically allocate descriptors for objects that are accessible through handles in user space. I recently added a block-based allocator that can be used for allocating schedule entries for PCI memmapped devices. These are protected with descriptors, and allow for fast physical to linear translation (and the reverse). There is also a problem with file system caches that also cannot be mapped to distinct descriptors, but by isolating these in their own address spaces, a reasonable solution can be achieved with few flat memory accesses in kernel space.