Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A wild bug: 1970s Intel 8271 disc chip ate my data

scarybeastsecurity.blogspot.com

Post reply on HN
Print view View original

11–20 of 20 posts

Re: A wild bug: 1970s Intel 8271 disc chip ate my data

#11

Post by rbanffy »

hyperman1 wrote: post #6

Pretty interesting behaviour, but I don't think you can claim this is a fault in the controller. The contract was being invalidated when he wrote invalid data to a register. After that, anything may happen. Today, most hardware has some protection against abuse, but in the days of the BBC micro it was common for hardware and os to completely trust the software. There were plenty of storys of damaged monitors because…

> The contract was being invalidated when he wrote invalid data to a register

This is similar to the "undocumented instructions" on many CPUs of the time. The Z-80 was famous for reacting to invalid opcodes in somewhat useful ways. The 6502 also reacted in weird ways to invalid opcodes, but I don't remember any useful behavior. When the 65C02 came out (//c and //e enhanced) all invalid opcodes mapped to NOPs.

Re: A wild bug: 1970s Intel 8271 disc chip ate my data

#12

Post by rbanffy »

csin wrote: post #5
rkagerer wrote: post #2

So that's how those Mission Impossible messages to James Bond would self destruct!

Forgive me for being pedantic. The agent's name in Mission Impossibles is Ethan Hunt.

Forgive me for being even more pedantic, but the person who received the self-destructing messages was Dan Briggs, who was replaced by Jim Phelps on season 2. Ethan Hunt only got the job on the first movie of the series.

Re: A wild bug: 1970s Intel 8271 disc chip ate my data

#13

Post by hyperman1 »

rbanffy wrote: post #11
hyperman1 wrote: post #6

Pretty interesting behaviour, but I don't think you can claim this is a fault in the controller. The contract was being invalidated when he wrote invalid data to a register. After that, anything may happen. Today, most hardware has some protection against abuse, but in the days of the BBC micro it was common for hardware and os to completely trust the software. There were plenty of storys of damaged monitors because…

> The contract was being invalidated when he wrote invalid data to a register This is similar to the "undocumented instructions" on many CPUs of the time. The Z-80 was famous for reacting to invalid opcodes in somewhat useful ways. The 6502 also reacted in weird ways to invalid opcodes, but I don't remember any useful behavior. When the 65C02 came out (//c and //e enhanced) all invalid opcodes mapped to NOPs.

x86 had a few undocumented opcodes. AAD and AAM have a second byte that should always be 10, but turns out to be an argument for base10 . There was salc.

A CPU, when it encounters bytes in its instruction stream, has to do something, whatever. If there is no interrupt for invalid instruction, it has to do something else. Common behaviour is shadowing legal insn's , but completely new behaviour is always possible

Re: A wild bug: 1970s Intel 8271 disc chip ate my data

#14

Post by 0xTJ »

nynyny7 wrote: post #7
hyperman1 wrote: post #6

Pretty interesting behaviour, but I don't think you can claim this is a fault in the controller. The contract was being invalidated when he wrote invalid data to a register. After that, anything may happen. Today, most hardware has some protection against abuse, but in the days of the BBC micro it was common for hardware and os to completely trust the software. There were plenty of storys of damaged monitors because…

At least the drive I accidentally tried the same had a mechanical stop. Although banging the head against it 170 times or so wasn't exactly beneficial for its alignment. Even today, one is better off not to write undocumented values to registers. True story: I had to investigate a SW bug report concerning a modern, fairly popular microcontroller. (I won't name which.) Sometimes data in RAM changed without our code wr…

I really wish it was common for manufacturers to fully document features like that. Even if they "DON'T USE THIS, IT WON'T DE WHAT YOU WANT, WE'RE NOT RESPONSIBLE FOR ANYTHING YOU DO!", it might open interesting opportunities. Even stuff like the Z180 test pin or the 68010 internal processor state that's pushed on address and bus exceptions, it would be interesting to know what those things do.

Re: A wild bug: 1970s Intel 8271 disc chip ate my data

#15

Post by dan_hawkins »

anilakar wrote: post #8
hyperman1 wrote: post #6

Pretty interesting behaviour, but I don't think you can claim this is a fault in the controller. The contract was being invalidated when he wrote invalid data to a register. After that, anything may happen. Today, most hardware has some protection against abuse, but in the days of the BBC micro it was common for hardware and os to completely trust the software. There were plenty of storys of damaged monitors because…

Before analog monitors got a builtin delay for changing the video mode, you could intentionally wreck the device by writing a few lines of code in QBasic, and by the time someone had already power cycled the poor machine while troubleshooting, the evidence was long gone.

Analog monitors didn't get delay for the protection. It's been a side effect of auto-sync feature when monitor spends some time analyzing input sync signals to automatically adjust its timings.

Re: A wild bug: 1970s Intel 8271 disc chip ate my data

#17

Post by rbanffy »

hyperman1 wrote: post #13
rbanffy wrote: post #11

Earlier quoted context omitted.

> The contract was being invalidated when he wrote invalid data to a register This is similar to the "undocumented instructions" on many CPUs of the time. The Z-80 was famous for reacting to invalid opcodes in somewhat useful ways. The 6502 also reacted in weird ways to invalid opcodes, but I don't remember any useful behavior. When the 65C02 came out (//c and //e enhanced) all invalid opcodes mapped to NOPs.

x86 had a few undocumented opcodes. AAD and AAM have a second byte that should always be 10, but turns out to be an argument for base10 . There was salc. A CPU, when it encounters bytes in its instruction stream, has to do something, whatever. If there is no interrupt for invalid instruction, it has to do something else. Common behaviour is shadowing legal insn's , but completely new behaviour is always possible

Actually doing something useful on invalid opcodes is cool, but a bad long-term idea - you'll end up having to support all the accidental behavior that ends up being used forever, or risk breaking backwards compatibility.

Re: A wild bug: 1970s Intel 8271 disc chip ate my data

#18

Post by rkagerer »

rbanffy wrote: post #12
csin wrote: post #5

Earlier quoted context omitted.

Forgive me for being pedantic. The agent's name in Mission Impossibles is Ethan Hunt.

Forgive me for being even more pedantic, but the person who received the self-destructing messages was Dan Briggs, who was replaced by Jim Phelps on season 2. Ethan Hunt only got the job on the first movie of the series.

Good catch. And yes, I intentionally conflated the two series, which might be unforgivable.

Re: A wild bug: 1970s Intel 8271 disc chip ate my data

#19

Post by joezydeco »

rbanffy wrote: post #11
hyperman1 wrote: post #6

Pretty interesting behaviour, but I don't think you can claim this is a fault in the controller. The contract was being invalidated when he wrote invalid data to a register. After that, anything may happen. Today, most hardware has some protection against abuse, but in the days of the BBC micro it was common for hardware and os to completely trust the software. There were plenty of storys of damaged monitors because…

> The contract was being invalidated when he wrote invalid data to a register This is similar to the "undocumented instructions" on many CPUs of the time. The Z-80 was famous for reacting to invalid opcodes in somewhat useful ways. The 6502 also reacted in weird ways to invalid opcodes, but I don't remember any useful behavior. When the 65C02 came out (//c and //e enhanced) all invalid opcodes mapped to NOPs.

The 6800's HCF (Halt and Catch Fire) opcode is another famous example.

https://x86.fr/investigating-the-halt-and-catch-fire-instruc...

Re: A wild bug: 1970s Intel 8271 disc chip ate my data

#20

Post by rbanffy »

rkagerer wrote: post #18
rbanffy wrote: post #12

Earlier quoted context omitted.

Forgive me for being even more pedantic, but the person who received the self-destructing messages was Dan Briggs, who was replaced by Jim Phelps on season 2. Ethan Hunt only got the job on the first movie of the series.

Good catch. And yes, I intentionally conflated the two series, which might be unforgivable.

The fastest way to get an answer on the internet is to post a wrong answer.
Post reply on HN