The History of a Security Hole

Posted on August 31, 2018 by Michal Necasek

Warning: If you do not care for the finer points of x86 architecture, please stop reading right now—in the interest of your own sanity.

A while ago I was made aware of a strange problem causing a normal user process running on 32-bit i386 OpenBSD 6.3 to crash the OS (i386 only, not amd64). The problem turned out to be a security hole with history that goes back more than three decades.

The crashing code looked like it didn’t really have any business crashing, but the CPU was in a very odd state with inaccessible kernel stack and GDT (that’s extremely unhealthy because exceptions and interrupts cause triple faults and CPU shutdown).

After much head scratching, I noticed that the (virtual) CPU’s A20 gate was off. That’s a big no-no because when the CPU is in protected mode, turning the A20 gate off has very nasty, unpredictable, and system-specific consequences. It’s one of those Just Don’t Even Try That things. But could a user process really turn off the A20 gate? That makes no sense.

As it turns out, a user process really could do that on i386 OpenBSD 6.3 (again, i386 only, not amd64). A security hole allowed regular user processes to read and write many I/O ports, which is obviously very unhealthy. The chain of events that led to this is long, and probably the biggest player in it is Intel, with important contributions from NetBSD and OpenBSD developers. Thanks to the nature of open source, we can trace back exactly how it came to be, and perhaps even learn a thing or two from the mistakes. Continue reading →

Posted in 386, BSD, Bugs, Documentation, PC history | 44 Comments

A Sound Card Before Its Time

Posted on August 15, 2018 by Michal Necasek

A mysterious full-length sound card recently arrived at the OS/2 Museum. It was clearly manufactured by IBM in 1985, and sports a 20 MHz Texas Instrument TMS32010 DSP (the DSP is the large black DIP chip near the lower left corner, not the ceramic gold cap chip).

A curious 1985 IBM sound card

The card has a FCC ID sticker, which is usually a good way to identify hardware:

A suspicious FCC ID sticker

The FCC ID is ANO95A6450611… which apparently does not exist. However, ANO9SA6450611 does. It is hard to say whether the typo is on the IBM card or in the FCC database. Either way, it’s an IBM FCC ID… from 1988. On a card made in 1985. If we discount time travel, there must be some other explanation. Continue reading →

Posted in IBM, PC history, Sound | 20 Comments

Three Weeks

Posted on July 27, 2018 by Michal Necasek

I happen to own several old laptops, now about 10 years old, that had the misfortune of being delivered with a Windows Vista license and matching Windows Vista OEM installations on their recovery partitions/media. About a year ago, I noticed that updating Vista no longer worked. That is to say, trying to look for updates just took for ever and ever, eating CPU cycles but never coming up with any result. Nothing happened overnight, nothing happened after two or three days, Windows Update just kept wasting CPU cycles.

This problem started sometime in early 2017, and only affected Vista SP2. It was perfectly possible to update a Vista installation to SP1 and then SP2 through Windows Update, but not to the latest state, it would just get stuck. The same problem was visible on three laptops and in several VMs.

Over a month ago I decided to see what would happen if I just left one of those old laptops running. It was a circa 2008 Compaq Presario V3000 with an AMD Turion 64 X2 processor. I booted it up and left it chugging along in the basement. Every few days I’d check on it and the CPU fans were still spinning, with Windows Update keeping one CPU core more or less fully loaded. Then I went on vacation for over a week, and when I came back, the fans were still spinning, and Windows Update was still busy.

Then one day I checked on the laptop and it was silent. Not dead, just resting. I started wondering what happened and soon enough I discovered that lo and behold, Windows Update in fact installed a number of updates from 2017 and was finally done! And that is why the laptop could finally go to sleep.

I don’t know how long the process actually took, but I estimate that it was about three weeks, give or take a few days (more likely give than take).

Now, a fully updated Windows Vista laptop is only marginally more useful than one which keeps wasting CPU cycles by checking for updates. The experiment was however useful in highlighting that a) Windows Update is (or at least was) seriously out of control, and that b) even if it took several weeks, the update process eventually did finish, as surprising as that was.

This is a good example of software which is functional yet its performance is so awful that it might as well be completely broken. With no progress indication whatsoever, after a day or two users have absolutely no reason to expect that the update process might ever successfully complete and give up.

Posted in Bugs, Microsoft, Windows | 27 Comments

How Fast Is a PS/2 Keyboard?

Posted on July 23, 2018 by Michal Necasek

A few weeks ago, an interesting question cropped up: How fast is a PS/2 keyboard? That is to say, how quickly can it send scan codes (bytes) to the keyboard controller?

One might also ask, does it really matter? Sure enough, it does. As it turns out, the Borland Turbo Pascal 6.0 run-time, and probably a few related versions, handle keyboard input in a rather unorthodox way. The run-time installs its own INT 9/IRQ 1 handler (keyboard interrupt) which reads port 60h (keyboard data) and then chains to the original INT 9 handler… which reads port 60h again, expecting to read the same value.

That is a completely crazy approach, unless there is a solid guarantee that the keyboard can’t send a new byte of data before port 60h is read the second time. The two reads are done more or less back to back, with interrupts disabled, so much time cannot elapse between the two. But there will be some period of time where the keyboard might send further data. So, how quickly can a keyboard do that? Continue reading →

Posted in Borland, IBM, Keyboard, PC hardware | 14 Comments

OS/2 2.0, Spring ’91 Edition

Posted on July 10, 2018 by Michal Necasek

Thanks to a generous reader, a curiously nondescript box labeled “OS/2 32-Bit Pre-release” recently turned up at the OS/2 Museum. The box looks very much like retail IBM products from the early 1990s, but has no identifying description except for a mysterious “PR00001” label. There is no real part number, no version number, no date. Given the professional packaging, I assumed it to be perhaps OS/2 2.0 LA from late 1991, or some other beta version not far from the final March 1992 release.

A mysterious 32-bit box

After opening the box, I wasn’t much wiser. There were three loose sheets of paper constituting a “Getting Started” brochure. This included real gems such as “we believe the PS/2 Model 90 and the PS/2 Model 95 are supported at this time”. That does not exactly inspire a lot of confidence.

The Getting Started manual (all of it)

The floppy labels were no more illuminating, except for a tiny “4/91” inscription at the bottom of each label. That would make this one of the earliest IBM OS/2 2.0 betas, older than build level 6.149/6.605 from Summer 1991.

OS/2 32-bit Pre-release diskettes dated 4/91

After checking the floppy contents (all 13 were error-free), a clearer picture emerged. The printer driver floppies were from late March 1991, which makes sense for an April 1991 release. But the rest was slightly older… Continue reading →

Posted in IBM, Microsoft, OS/2, PC history, Pre-release | 35 Comments

ANOMALY: meaningless REX prefix used

Posted on June 20, 2018 by Michal Necasek

While trying to get work done, I was confronted by several disturbing messages printed on the console of a 64-bit Windows 7 system:

[0x7FEEFEFAAA0] ANOMALY: meaningless REX prefix used
[0x7FEEFEE48C0] ANOMALY: meaningless REX prefix used
[0x7FEEFEE54B0] ANOMALY: meaningless REX prefix used

This was disturbing because I pretty quickly established that the application I was running was not printing those messages. The expression “meaningless REX prefix” does actually convey comprehensible meaning to me, but I still don’t want to see it printed by some shadowy force, especially not without any clue as to why it might be printed.

A quick trip to a search engine only established the all-too familiar fact: there are lots of clueless people on the Internet. That includes people writing knowledge base articles. All in all, there are many avenues to ask the same question and get no useful answer.

There are all sorts of theories. It’s Windows 10. It’s anti-virus software. It’s Raptr. The winner is probably “my guess is that some non-Microsoft component (driver, software, utility) is installed and has “extended” the command processing environment with a REXX interpreter”. The old saying “better to remain silent and be thought a fool than to speak and to remove all doubt” certainly comes to mind.

Since I was not running Windows 10 or AVG, I could immediately dismiss some of those theories (and no, I didn’t take the REXX theory seriously for one second). But that didn’t help me much. So, where is that blasted message coming from? Continue reading →

Posted in Bugs, Debugging | 9 Comments

A Brief History of Unreal Mode

Posted on June 15, 2018 by Michal Necasek

After a run-in with a particularly crazy manifestation of unreal mode (Flat Assembler, or fasm), I decided to dig deeper into the history of this undocumented yet very widely used feature of 32-bit x86 processors.

For the purposes of this discussion, unreal mode is a variant of the x86 real mode with non-standard segment limits and/or attributes, different from the processor state at reset. To recap, real mode on the 286 and later CPUs has much more in common with protected mode than with the real (and only) mode of the 8086. Notably, undefined opcodes raise exceptions, segment limit overruns cause general protection or stack faults, and (on the 386 and later) 32-bit registers and 32-bit addressing can be used—subject to limit checks.

The origins of unreal mode are shrouded in the mists of time. But enough is known that certain outlines are quite clearly defined. Let’s present a rough timeline of unreal mode.

Continue reading →
Posted in 386, Corrections, Microsoft, PC history, Undocumented | 47 Comments

USB 0.9

Posted on June 2, 2018 by Michal Necasek

A couple of months ago I lamented the fact that historic USB documentation appears to have vanished from the face of the Earth. Today I finally found one such document, the USB 0.9 specification from April 13, 1995, published almost exactly nine months before the final USB 1.0 specification.

And where did I find the USB 0.9 specification, you may ask? Why of course, on my own hard drive. Not kidding. It’s been there the whole time. I really hate when that happens!

Anyway, back to USB. Back in December I complained that the Wikipedia article on USB claimed that USB 1.0 only specified the 1.5 Mbps low-speed transfer rate, and USB 1.1 added the 12 Mbps full-speed transfers. I also wrote that I had a vague memory of 12 Mbps being in fact defined first, and 1.5 Mbps added later, but I could find no evidence for that. Either way, USB 1.0 most certainly defined both speeds.

To recap, the March 20, 1995 issue of InfoWorld reported that “USB supports a 1.5MBps data transfer rate—compared to a standard serial port data transfer rate of approximately 400KBps”. A letter from the USB program manager at Intel published in the April 17, 1995 issue of InfoWorld stated that “USB supports a 12Mbps data transfer rate”. Note the capitalization.

In retrospect, it is apparent that InfoWorld simply screwed it up. When they wrote 1.5MBps for USB, they really meant 1.5 megabytes per second, which translates to 12 megabits per second. Except when they were talking about serial ports, they surely meant 400 kilobits per second.

After reviewing the USB 0.9 specification, I can say with certainty that the hints of low-speed USB transfers being a late addition are correct. The USB 0.9 specification defines only one transfer rate, 12 Mbps. There isn’t the slightest mention of any other transfer rate. That means the 1.5 Mbps low-speed transfers were probably added in the USB 0.99 specification in August 1995 (and yes, I checked, the USB 0.99 spec is not on my hard disk).

Posted in Documentation, PC history, USB | 30 Comments

Troubled Time

Posted on May 30, 2018 by Michal Necasek

This is not an article about current affairs

Over the last few weeks, I had several interesting run-ins with time, specifically how time is represented and processed by computers. Deep down it’s really all about a clash of human culture and history with physical reality.

At one extreme, there is local time, with noon exactly when the Sun is highest in the sky. Different depending on where you are, and exactly how humans worked with time throughout most of recorded history. That approach works very well as long as people and information can’t move much faster than about the speed of a horse. The 19th century introduced train travel and telegraph. If one sat on a train and started going eastwards or westwards, it didn’t take long for a pocket watch to get increasingly out of sync with local time. To solve that problem, and make it possible to maintain and publish usable schedules, time zones were introduced.

To solve a different problem, or perhaps cause more problems, the 20th century introduced daylight savings time. To cause maximum pain to computer scientists, daylight saving is not observed universally and is not constant. A real winner in this category is probably Egypt’s 2016 cancellation of daylight saving time three days before it was due to begin.

To communicate over longer distances, computers are forced to agree on a common definition of time. That is the other extreme: UTC, or Universal Coordinated Time, which conveniently doesn’t know any time zones or daylight saving and is the same everywhere on Earth (modulo relativity effects).

Sadly, computer users only care about local time, which means computers have to convert between local time and UTC all the time. That is merely complicated when that time is “now”, hideously difficult when the time is in the past, and impossible when the time is in the future. Continue reading →

Posted in Bugs, PC history, Random Thoughts | 18 Comments

A Word on the CALL 5 Spell

Posted on May 26, 2018 by Michal Necasek

After years of searching for some reasonably widespread DOS application which used the CP/M-style CALL 5 interface and coming up with absolutely nothing, Jeff Parsons of pcjs.org found one: None other than Microsoft Word, specifically the spell checker in the DOS-based versions of MS Word 2.x and 3.x. These versions were sold roughly from 1985 to 1987.

Microsoft Word spell checker

What’s significant is that Word 2.x/3.x was obviously Microsoft’s own product, and was sold and supported during the years when OS/2 was in development (and OS/2 needed to manipulate the A20 line) and high memory (HMA, managed by HIMEM.SYS) was on the drawing board. Much like EXEPACK, Microsoft Word 2.0 for DOS actually post-dates the IBM PC/AT with its A20 gate circuitry. It is highly probable that no one at Microsoft even realized the dependency of the MS Word 2.x/3.x spell checker on the A20 gate until years later. Continue reading →

Posted in DOS, Microsoft, PC history | 10 Comments