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.
sillema sillema nika su
(Score: 4, Informative) by Snotnose on Thursday September 06 2018, @04:31PM (10 children)
In the 80s I was doing embedded system programing for various CPUs, including x86 family. One of the first things I learned was that when mapping a struct to hardware you always:
a) Added a comment indicating the struct had to match hardware, and indicating where the hardware was documented; and
b) Always pack your structs.
When the dust settled America realized it was saved by a porn star.
(Score: 2) by DannyB on Thursday September 06 2018, @04:43PM (8 children)
What if different compilers pack your structs differently?
(TSA would not approve)
Or was there some standard I was not aware of which compilers conformed to?
I was using Pascal in the 80's but had similar issues with packed record. Mostly with matching wire protocols rather than hardware.
The lower I set my standards the more accomplishments I have.
(Score: 3, Interesting) by Anonymous Coward on Thursday September 06 2018, @05:11PM (1 child)
Well, the C standard is clear: leaving aside bit-fields which have different rules, implementations are free to add any amount of padding after any member of a structure.
However the C standard is not the only document that matters when implementing a C compiler. In reality most platforms have an ABI specification that details exactly how C structures should be represented in memory, and C compilers for a particular platform will normally follow that specification by default. Such a specification is essential for libraries built using one C compiler to interoperate with code using a different compiler.
(Score: 2) by DannyB on Thursday September 06 2018, @05:51PM
Dang! That would frustrate cross platform compatibility.
Too bad they didn't think of having a standard switch to specify packing to either Platform ABI conventions, or C Language Standard conventions. (And then actually have a language standard spec.)
Then the software author could specify which packing convention was intended. A cross platform packing convention might be good for wire protocols and such. While platform standards might be good for interoperability between libraries, multiple compilers whose code is linked together, and possibly even hardware on that platform. An OS could specify structs and all compilers would understand it the same way. A wire protocol could specify a struct and all compilers could understand it the same way.
Then someone could come along and say:
#define struct union
To achieve maximal efficient packing.
The lower I set my standards the more accomplishments I have.
(Score: 2) by sjames on Thursday September 06 2018, @06:29PM
That was the point of packing. When you specify packed, you leave the compiler no discretion to add padding for alignment purposes. The fields are laid out exactly as you specify without padding.
(Score: 3, Informative) by Snotnose on Thursday September 06 2018, @06:34PM
They did. Keep in mind this was before ANSI C, and the people adopting C were assembly language programmers. We were quite capable of looking at the compiler output to ensure our structs lined up like they should.
When the dust settled America realized it was saved by a porn star.
(Score: 2) by driverless on Thursday September 06 2018, @07:23PM
Should be OK, as long as there are no liquid elements, or folding struct members longer than 2.36 inches.
(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.
(Score: 3, Interesting) by DavePolaschek on Thursday September 06 2018, @05:52PM
If you followed Intel's initial 386 PRM (from 1986), the padding byte wasn't documented at all. The April 1986 datasheet documented it correctly, but differently. The 1989 386 SX PRM finally documented it all correctly, three years late. And then a slew of technical books came out in the early 90s (also covered in TFA) which got it wrong in various ways.
Fun!