On Wed, Oct 07, 2020 at 10:39:23AM +0300, Jarkko Sakkinen wrote: > On Tue, Oct 06, 2020 at 09:34:19PM -0700, Sean Christopherson wrote: > > > Even if that was in place, you'd need to separate normal and interrupt. > > > Tristate is useless here. > > > > Huh? You mean like adding SGX_INTERRUPT_EXIT and SGX_EXCEPTION_EXIT? > > OK, so I'll throw something. > > 1. "normal" is either exception from either EENTER or ERESUME, > or just EEXIT. > 2. "interrupt" is something where you want to tailor AEP path. Manipulating the behavior of the vDSO, as in #2, would be done via an input flag. It may be related to the exit reason, e.g. the flag may also opt-in to a new exit reason, but that has no bearing on whether or not a dedicated exit reason is valuable. > > I'm not arguing that any of the above is even remotely likely. I just don't > > understand why we'd want an API that at best requires heuristics in userspace > > to determine why the enclave stopped running, and at worst will saddle us with > > an ugly mess in the future. All to save 4 bytes that no one cares about (they > > literally cost nothing), and a single MOV in a flow that is hundreds, if not > > thousands, of cycles. > > I don't care as much as saving bytes as defining API, which has zero > ambiguous state variables. How is exit_reason ambiguous?
