OSwhatever wrote:
I little bit a mistake by the x86 designers in my opinion
x86 was not designed, it grew over time. The 8086 had 16-bit segments to ease transition from the 8080, so every CPU in that line had to keep the 16-bit segments around. Then the 80286 was way over-engineered, and we're stuck with that design to this day. Then the 80386 gained an extra two segment registers, and they became useful only a few years down the line. And on and on.
OSwhatever wrote:
unless you can configure user processes to be allowed to write WRFSBASE/WRGSBASE.
These instructions, as I said, can be used from user space. If the CPU supports them, and the kernel enabled them. So whether you can use them is a dynamic property. User space applications would have to keep both the code to use the system call and the new instructions around, and decide between the paths at run time. Oh, and the kernel would need to signal support for the new instructions to user space somehow. All of that to save one very fast system call. Most applications will not bother.
OSwhatever wrote:
They should have provided a register that user space processes could just set.
They did! Sixteen of them, in fact. But no ABI could agree to just reserve one GPR for the thread pointer so now we're stuck with using the FS/GS base address.
OK, in 32-bit mode, you only have eight GPRs, and permanently loosing one of them would be very harsh indeed.
OSwhatever wrote:
My OS is using user space scheduling and having a register that user space processes can set without the kernel helps.
What's the point of user-space scheduling? You need kernel-space scheduling, anyway, so why not use it for threads as well?
OSwhatever wrote:
is it possible to load fs/gs in user space with an invalid descriptor?
You could set them to zero, I suppose. That would invalidate them. Of course, now you are trading a system call now for a trap later, not sure how that is beneficial. And the trap is "General Protection Fault", that exception that is invoked for almost everything, and yet it still does not tell you why it is running. It will be hard to identify this specific fault, is my point.