OSDev.org

I noticed in this wiki article: https://wiki.osdev.org/Getting_to_Ring_3 that the DPL of the TSS descriptor in GDT is set to 3, which I'm not sure is a good idea given the following quote from the Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3, Section 7.2.2 (TSS Descriptor):

Intel wrote:In most systems, the DPLs of TSS descriptors are set to values less than 3, so that only privileged software can
perform task switching. However, in multitasking applications, DPLs for some TSS descriptors may be set to 3 to
allow task switching at the application (or user) privilege level.

It makes sense to me that most operating systems don't want i386 task switching to be triggered by user apps, without getting a #GPF. Is there some subtle detail I'm missing?

In theory, that is a big problem, but in practice, most modern OSes only use the kernel stack part of the TSS. This means that we don't have to worry about privilege escalation

But for good practice, I would change it to DPL=0

nexos wrote:In theory, that is a big problem, but in practice, most modern OSes only use the kernel stack part of the TSS.

That's exactly my case. I do the context switch in software.

nexos wrote:This means that we don't have to worry about privilege escalation

I'm not super worried about privilege escalation, but about a potential crash: the CPU doesn't know that we don't use hardware task switching, even if we have just one TSS. So, nothing will stop user apps to do a FAR jump or a FAR call using that TSS, if they want. And, if such call is performed, instead of getting immediately a #GPF the CPU might actually trying to switching to that TSS, using the (maybe) garbage data there. If the TSS is not properly zeroed and somehow TSS' EIP has an usable address (I admit, that's extremely unlikely), weird things will happen

I've never even tried using i386 hardware switching, so I wanted to check with you guys if my theory makes sense.

Hmm yeah that does make sense... And while the chance of it going to a garbage EIP is about as high as the chance of libgcc crashing when not compiled with -mno-red-zone on x86_64, it still is there.

I updated the wiki page, fixing TSS' DPL to 0 and the RPL to 0 when LTR is used. In addition, I quoted Intel's document.