Are MS-DOS and Windows 9x vulnerable to Meltdown?

Question

In an interesting crossover between current events and Retrocomputing, the vulnerability known as "Meltdown" was publicly disclosed on January 3rd 2018. The retro-computing tie-in is that this vulnerability is reported to impact all Intel microprocessors back to the 1995 release of the Pentium Pro (P6 micro-architecture).

In the late 1990s, the dominant OS's for Intel machines were MS-DOS, which was slowly being retired, and Windows 95 and 98, which were the replacements still underpinned by MS-DOS. Of course, Windows NT was also on the rise, but was most prevalent in enterprises. My question is which of these OS's were TECHNICALLY vulnerable to Meltdown, taking into account whether the OS offered any real attempt at memory protection?

My impression is that MS-DOS and Windows offered no such protection*. Therefore, it's arguable that they weren't actually vulnerable to Meltdown, by virtue of the fact that no such vulnerability needed to exist to allow a rogue process to access "private" data owned by other processes. If this is true, then what time-frame can we pinpoint when systems became vulnerable to Meltdown accounting for OS features that guaranteed memory protection?

*NOTE: I'm recalling dev tools for Windows, like Dr. Watson and Bounds Checker, that seemed to allow full access to process memory without any special privilege.

Answer 1

The Meltdown attack is about figuring out what's in protected memory (typically, kernel memory) by arranging for it to be speculatively read, and then looking for residual side effects after the speculative read is discarded.

MS-DOS is immune to Meltdown because it doesn't do memory protection. If you want to figure out what's in RAM, you can simply look.

Windows 9x has a userspace/kernelspace split with kernel protection (and some bugs: parts of kernel-critical memory were left user-writeable, so a userspace program could bring down the entire system). The kernelspace memory mapping includes all of physical RAM, which means a Meltdown-style attack can read everything, just like it could on an unpatched Linux system.

Answer 2

For the most part you're correct. Neither MS-DOS nor Windows 95/98/ME implemented a security model that would not be impacted by the Meltdown or Spectre vulnerabilities. MS-DOS didn't protect memory at all, Windows 9x's separation of user and "kernel" memory was just to protect against user processes accidentally from modifying memory outside of their process. An MS-DOS program can read whatever memory it wants and any Windows 9x program can load a device driver (VxD) that can read whatever memory it wants.

However there is one way that potentially these operating systems could be affected by these vulnerabilities, at least in theory, and that's through a JavaScript program running in an web browser. MS-DOS I would assume is safe from this in practice because I assume the are no web browsers for DOS that support JavaScript, but Windows 9x would be a different matter. A mitigating factor for Windows 9x is that web browsers that support these old operating systems would be old and so probably don't have the JavaScript features necessary for the exploit to work and probably have other JavaScript vulnerabilities that would be easier to exploit

Answer 3

This flaw does not affect MS-DOS because there is no kernel protection to subvert. It affects any protected mode Windows of any era that has a speculative CPU.

However, nothing before the Pentium Pro speculatively executed so a regular Pentium or below does not exhibit the bug. Therefore it is unlikely to affect a substantial number of real machines.

There are two observations underlying Meltdown:

• speculative execution can see memory even if accessing it should cause an access violation;
• speculative execution has a side effect, cache loading, that can be observed even when the speculative branch isn't taken.

So if you use one bit of a byte you don't have access to as an array index, multiplied by a suitable amount, you can test whether that bit was set or cleared by observing the timing effect of trying to access the array yourself. If the section indexed when the bit is a 1 is in the cache, the bit must have been a 1.

The fix is not to have kernel memory mapped at all when running user code. The mapping and unmapping cause a large performance hit.

No operating system would volunteer to apply that protection if it weren't necessary, so you should expect all protected mode operating systems to be affected.

Answer 4

Windows 95 is vulnerable to Meltdown. Spectre attack from JavaScript on 32 bit systems can turn into Meltdown if the processor is vulnerable to Meltdown. You probably don't care because where are you going to get a web browser for Windows 95 that supports JavaScript but doesn't have ridiculous security holes in it.

Java applets are in a worse state. The root construction can be built in Java code. It looks like this:

byte array[] = new byte[65536];
int z = targetbyte; /* plus some offset we can't know yet -- but kernel memory is high */
int accum = 0;
for (int b = 0; b < 8; ++b)
    for (int x = 0; x < 32; x++)
        for (int t = 0; t < 3; t++) {
            int s = 0;
            /* force array[4096] out of L1 cache */
            for (int y = 8192; y < 65536; ++y) s |= array[y];
            int y = (x == 31) ? z : 1;
            long time1 = System.nanoTime();
            if (y < 16) { /* branch predictor is trained for true */
                do {
                    /* s = array[1] during normal execution;
                       reads out-of-range memory during speculative execution
                       expression is jmpless array[array[y] ? 0 : 4096] */
                    s = array[(array[y] & (1 << b)) >> (1 >> b) << 12];
                } while (s == 0 && y < 16); /* loops only during speculative execution */
            }
            s = array[4096];
            long time2 = System.nanoTime();
            if (x == 31 && (time2 - time1) < some_constant_unique_per_cpu)
                accum |= (1 << b);
         }

This is the unified sequence that attacks both Spectre and Meltdown and targets the small cache liens on Pentium II and III processors (adjust to bigger lines for a VM guest). Pentium I isn't vulnerable. The internal if protecting array bounds is also trained to true by the same code so it won't hose us.

Any Java applet running in the web browser can read all memory on the system (int wraps around in 32 bit) so if by some miracle you have a fully patched web browser and Java implementation you still get smacked.

Windows 95 memory mapping is so poor that a Spectre attack is the equivalent of a Meltdown attack. (And MS-DOS uses a 1-1 mapping when running 32 bit DOS programs.) All memory is mapped above 3GB in all processes.

If you are running this in a VM guest on a 32 bit host vulnerable to Meltdown it will read all host memory. If your host is 64 bit the host is protected by the fact the guest can't generate 64 bit read offsets and so can't read kernel memory.

I haven't been able to fully check this, but the following should be correct: If your host machine is vulnerable to rowhammer (~doesn't have ECC memory), than you really are in trouble. Emulators tend to allocate the guest VM in one swoop, which tends in turn to allocate host memory in one swoop. This makes guessing adjacent memory easy, and the Spectre attacks on jitting emulators and true VMs able to bust out of the emulator by flipping bits in the jitted code (we remember true VMs have to JIT the guest kernel in some cases--once we have full control of the guest we can arrange them) and thereby get control of the VM process in the host machine. Please not the Spectre attack doesn't "know" it's in a VM and will read outside the VM bounds into the host process. Rowhammer is difficult to exploit. Rowhammer when you know the memory layout is not. If the host is vulnerable to Meltdown we can then repeat the process and take over the kernel. If not, we have the emulator process, which probably isn't running as its own user. (I think VirtualBox processes run as root; and the user probably started qemu as himself--either way is really bad.)

Answer 5

mainly I'm trying to dispute the claim that computers have been vulnerable to Meltdown since 1995.

The claim was never that all computers since 1995 were vulnerable, just some. Also not that all PPro-using computers were vulnerable (as a whole system), but just that those CPUs were vulnerable.

Microsoft was not the only OS vendor for Pentium Pro CPUs in 1995, there were x86 OSes that did full memory protection.

---

Update: It turns out PPro / PII is not strictly vulnerable to Meltdown, instead leaking various microachitectural data but not cache/mem contents. Henry Wong ran some detailed tests of forbidden loads that were present or not in L1d cache (and various cases of TLB state) on a range of microarchitectures from P5 to Haswell, and Atom, K6, K8, Bulldozer, and Via. With results in an interesting table. The Microarchitecture Behind Meltdown

P4 Prescott is vulnerable, as are Core 2 and later Intel. (He didn't test PIII, Pentium M, or Core Solo so we don't know if Core2 is the first vulnerable uarch.) The AMD and Via uarches aren't vulnerable.

Pentium Pro, Pentium II
The Pentium Pro takes the “load value is a don’t-care” quite literally. For all of the forbidden loads, the load unit completes and produces a value, and that value appears to be various values taken from various parts of the processor. The value varies and can be non-deterministic. None of the returned values appear to be the memory data, so the Pentium Pro does not appear to be vulnerable to Meltdown. The recognizable values include the PTE for the load (which, at least in recent years, is itself considered privileged information), the 12th-most-recent stored value (the store queue has 12 entries), and rarely, a segment descriptor from somewhere.

The Pentium II (Klamath) has the same behaviour as the Pentium Pro.

So it's not Meltdown; instead it's more like the general RIDL (Rogue In-flight Data Load) vulnerability, and other MDS (Microarchitectural Data Sampling). e.g. you might possibly be able to get some data the kernel stored before returning to user-space.

(The other not-vulnerable uarches, AMD, VIA, and Intel Atom, either don't produce a value at all, or produce zero. So there's no microarchitectural data leakage there.)

---

(The rest of this was written assuming the statement about PPro meltdown vulnerability was true. Systems existed in 1995 that used x86 memory protection, and PPro wasn't widely used in Win95 boxes until later PII / PIII.)

Linux in 1995 (when PPro was released) had many real users and full working memory protection between separate userspace processes. So did other Unix implementations on 386, like 386BSD, and some non-free Unix implementations for 386 which predated Linux.

Microsoft's crufty Win9x OS family being widely used at the time meant that most people didn't have an OS with full privilege separation for multiple users (or unprivileged processes), or to protect the kernel from applications. Win9x used virtual memory to stop processes from accidentally crashing each other, not for security. See Ross's answer, and another question: Even Win9x did run processes in separate address spaces from each other, but its security model allowed any process to load a driver (VxD) and bypass that.

---

Also note that Pentium Pro was not widely used in home computers. Pentium II in May 1997 was what really replaced Pentium MMX. Even the consumer-targeted PII was expensive at first: My first PC (in early 1998, IIRC) was a P-MMX running Linux.

The workstations / servers that used PPro were probably mostly not running Win9x. Some were probably running Linux or other Unix, many probably running Windows NT as mentioned in comments.

---

The claim that Intel CPUs dating back to 1995 were vulnerable to Meltdown is based on the fact that all of Intel's out-of-order CPUs (other than Pentium 4 (netburst microarchitecture)) can trace their lineage back to the first generation of P6 (Pentium Pro), and use the same fault-handling strategy for under-privileged TLB hits on kernel-only mappings: let the load continue microarchitecturally, and only flag it to fault on retirement, after potentially making other changes to micro-architectural state that depend on the loaded "secret" data, specifically the cache. This is the Meltdown design flaw.

(But it turns out that there have been changes over the years, and first-gen P6-family didn't expose cache contents. The above reasoning for the claim made sense, but turned out to be wrong.)

Sandybridge-family is a new microarchitecture family, but it did evolve from P6-family (Nehalem being the last generation). SnB incorporates some ideas from Netburst, but in a different form. (E.g. the decoded-uop cache instead of the trace cache.)

Most Intel-based computers in 1995 were either using in-order CPUs, and/or running OSes that didn't try to enforce process isolation. Some old 586 and 486 CPUs stayed in service for many years... (But since some software at the time had a security model that's defeated by Meltdown, it makes sense to say computer, not just CPU.)