Re: [PATCH v2 00/13] Dynamic Kernel Stacks

[Andrew Cooper]

> However, I'd still like to work with you to understand what feasible
> path forward you see, hoping you can proactively steer us away from
> some of the bigger headaches.
>
> I think we are fine being forward-looking, and only supporting this
> for FRED (which is on our doorstep). That said, understanding the
> issues you foresee with the IST approach

For IST, read
https://docs.google.com/document/d/1hWejnyDkjRRAW-JEsRjA5c9CKLOPc6VKJQsuvODlQEI/edit?usp=sharing

This was written prior to the first public drafts of FRED and SEE specs,
and FRED evolved quite a lot from the first draft to where we are today.

>  would still be valuable, as
> it might save us internal trouble should we choose to carry it
> temporarily to bridge the gap with FRED.

A lot has been said about the invasiveness and tradeoffs.  I don't wish
to dwell on or rehash that.

There is one critical point which has not been made as far as I can tell:

In x86, if delivering an interrupt (NMI or INTR) causes an exception
(any exception, not just pagefault), the original interrupt is lost.

If you are aware of this, then in principle you can look at the LAPIC
state to figure out when an INTR was missed.  However there is no
ability at all to figure out when an NMI was missed.  Worse, it is both
vendor and IDT-vs-FRED specific as to whether NMIs are blocked following
a missed NMI, and that too is state you cannot recover.

If you wish to make dynamic stacks works, then you *must* find a
non-fault based approach on x86.

~Andrew