MIME-Version: 1.0
From: Andy Lutomirski <luto@kernel.org>
Date: Sat, 19 Nov 2016 17:52:57 -0800
Message-ID: <CALCETrUqdp=rEKX4gdSpJYder3q0g_yxdRE9APw8MgerXvnB=w@mail.gmail.com>
Subject: What exactly do 32-bit x86 exceptions push on the stack in the CS slot?
To: tedheadster@gmail.com, Linus Torvalds <torvalds@linux-foundation.org>,
        "H. Peter Anvin" <hpa@zytor.com>, Brian Gerst <brgerst@gmail.com>,
        George Spelvin <linux@horizon.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        X86 ML <x86@kernel.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1038
Lines: 24

This is a question for the old-timers here, since I can't find
anything resembling an answer in the SDM.

Suppose an exception happens (#UD in this case, but I assume it
doesn't really matter).  We're not in long mode, and the IDT is set up
to deliver to a normal 32-bit kernel code segment.  We're running in
that very same code segment when the exception hits, so no CPL change
occurs and the TSS doesn't particularly matter.

The CPU will push EFLAGS, CS, and RIP.  Here's the question: what
happens to the high word of CS on the stack?

The SDM appears to say nothing at all about this.  Modern systems
(e.g. my laptop running in 32-bit legacy mode under KVM) appear to
zero-extend CS.  But Matthew's 486DX appears to put garbage in the
high bits (or maybe just leave whatever was already on the stack in
place).

Do any of you happen to know what's going on and when the behavior
changed?  I'd like to know just how big of a problem this is.  Because
if lots of CPUs work like Matthew's, we have lots of subtle bugs on
them.

--Andy