
Double Faults - octosphere
https://os.phil-opp.com/double-fault-exceptions/
======
userbinator
_However, hardware context switching is no longer supported in 64-bit mode and
the format of the TSS changed completely._

Quite unfortunate, especially with the large state sizes of processors now
with all their vector registers and such; it would've been great to simply ask
the hardware how much it needs, allocate a TSS of the appropriate size, and it
would automatically manage the state save/restore as necessary.

Fun fact: in the days of the 286, which could not switch out of protected mode
without a reset, the fastest way was to triple-fault:

[https://blogs.msdn.microsoft.com/larryosterman/2005/02/08/fa...](https://blogs.msdn.microsoft.com/larryosterman/2005/02/08/faster-
syscall-trap-redux/)

~~~
bogomipz
Wasn't the issue that TSS/hardware switching had too much overhead which is
why Linux uses/used software based switching?

~~~
zaarn
Hardware context switching is quite fast and overhead free.

The problem is that commonly the hardware based switch will not save all
registers and with software based switching you can be much more selective
about what you do and eek out a bit more performance that way.

~~~
bogomipz
>Hardware context switching is quite fast and overhead free."

Everything I have read on hardware switching has indicated otherwise:

From:

[https://wiki.osdev.org/Context_Switching#Hardware_Context_Sw...](https://wiki.osdev.org/Context_Switching#Hardware_Context_Switching)

>"Performance Considerations

Because the hardware mechanism saves almost all of the CPU state it can be
slower than is necessary. For example, when the CPU loads new segment
registers it does all of the access and permission checks that are involved.
As most modern operating systems don't use segmentation, loading the segment
registers during context switches may be not be required, so for performance
reasons these operating systems tend not to use the hardware context switching
mechanism. Due to it not being used as much CPU manufacturers don't optimize
CPUs for this method anymore (AFAIK). In addition the new 64 bit CPU's do not
support hardware context switches when in 64 bit/long mode."

~~~
zaarn
I mentioned this in my comment, with software ctxs you can save a bit of time
if you don't need to save and restore everything.

Outside that, hw ctxs is faster.

------
amluto
> Thus, we are able to catch all double faults, including kernel stack
> overflows:

“All” is a strong word. If you implement page table isolation, and you goof
the page table switch, your double fault handler may not work either.

~~~
bonzini
In general, an infinite stream of page faults is not that uncommon if you mess
up the page tables. The IST won't help you there...

That's an advantage of the POWER feature where you can define a small number
of (typically very large, but that doesn't have to be the case) linear
mappings that bypass the page tables. It's typically used to speed up TLB
misses, but you could for example add one for the double fault IST if x86 had
a similar thing.

------
johnramsden
Interesting article about how multiple faults can be handled.

Name should probably be "Double Faults", the website is "Writing an OS in Rust
", but the post is about double faults.

