linux-kernel - What exactly do 32-bit x86 exceptions push on the stack in the CS slot?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrUqdp=rEKX4gdSpJYder3q0g_yxdRE9APw8MgerXvnB=w@mail.gmail.com>
Date:   Sat, 19 Nov 2016 17:52:57 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     tedheadster@...il.com,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "H. Peter Anvin" <hpa@...or.com>, Brian Gerst <brgerst@...il.com>,
        George Spelvin <linux@...izon.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        X86 ML <x86@...nel.org>
Subject: What exactly do 32-bit x86 exceptions push on the stack in the CS slot?

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