SoylentNews is people
SoylentNews
Back when Intel introduced the 80286, they didn't quite document everything right away. Errata were needed. Then the 80386 changed things. And then someone convinced them to add just one more feature at the last minute, which didn't get documented properly again.
The History of a Security Hole takes a look at the problems introduced by the I/O Permission Bitmap (IOPB) in the 80286, and how fallout from the implementation caused a security hole in all versions of OpenBSD up to 6.3 and NetBSD up to 4.4.
Conclusion? This programming thing is hard.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Either I'm dead or my watch has stopped.
-- Groucho Marx's last words
(Score: 2) by Pino P on Friday September 07 2018, @01:15PM (2 children)
In theory, you could use a block of static_assert tests on offsetof each member.
Wire protocols are more difficult to map effectively onto a struct than hardware registers because they're more likely to be opposite-endian than a piece of hardware designed to interact with your particular CPU.
(Score: 2) by Snotnose on Saturday September 08 2018, @01:01AM (1 child)
Not really. Keep in mind I'm still talking the 80s/90s. It was very common to do a project for a CPU with one endian, then a project for a CPU with another endian (remember, there's more to it than big/little endian. Some CPU makers were evil when deciding what byte belonged where. Not to mention if bit 0 was the LSB or MSB).
Change CPUs, you changed compilers. Different command line flags, different struct packing, different random stuff you never thought of.
Me? Late 80s/early 90s I was writing ethernet device drivers, and code networking code that used them. Not networking as in implementing sockets, but code that used sockets to do magic, then hit my ethernet driver, and back the other way. I was very familiar with mapping structs to both hardware and network layouts.
My closest claim to fame? Around 1990, an Intel Ethernet chip I had docs to, but the chip wasn't available. Wrote a driver using dummy code to emulate the chip. Finally got a chip, found a bug, did a workaround. Told Intel, it turned into an errata. 4 years later I discovered Linux, looked at the driver for that chip and my workaround was in the driver. I'm not saying Alan Cox stole my fix, but, well, one can hope.
Finally, when dealing with serial protocols (MP3, etc), when you parse them you tend to write things like int getbits(3), which returns the next 3 bits in the datastream. getbits() deals with endian issues, buffering, etc.
When the dust settled America realized it was saved by a porn star.
(Score: 2) by Snotnose on Saturday September 08 2018, @01:14AM
I should add, back then not even assembly languages were standardized. I worked for a company that had Kontron compilers, linkers, and, um, don't remember what they were called but they were essentially early JTAG ports. A cable went from the Kontron to the CPU socket, the Kontron debugger actually emulated the CPU (this crapped out mid 80s, CPUs got too fast for the signals to go through the cable).
Everything was written in 8086 assembly. Around '84 or so Kontron decided to switch to the Intel assembly format. Biggie was things like "mv a, b" turned into "mv b, a". And other various syntax "fixes" to match Intel.
I got tasked to convert our assembly codebase, which turned into about 100k executable code, into Intel format. That is how I turned into an awk expert. Took me 2-3 months, looking back it may have helped to learn yex/lacc, but that would have taken 2-3 months so I call it a wash.
When the dust settled America realized it was saved by a porn star.