A local root vulnerability in glibc [LWN.net]

A local root vulnerability in glibc

Posted Oct 5, 2023 22:46 UTC (Thu) by shemminger (subscriber, #5739)
In reply to: A local root vulnerability in glibc by joib
Parent article: A local root vulnerability in glibc

Intel tried building an OS with capabilities and HW support back in the 1990's.
In addition to biting off to big a task, what did run was incredibly slow an never made it out to the public. They invested lots of money at the time.

to post comments

A local root vulnerability in glibc

Posted Oct 6, 2023 8:39 UTC (Fri) by geert (subscriber, #98403) [Link] (2 responses)

Which does not mean it is not feasible now, only that it was not feasible in the nineties.

During development, Intel simulated the 80386 at the gate level on an IBM mainframe, which was rumoured to take one week to boot DOS. Nowadays we boot simulated Linux-on-LiteX-VexRiscv using Verilator on our desktops in minutes.

A local root vulnerability in glibc

Posted Oct 6, 2023 14:46 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

> simulated the 80386 at the gate level on an IBM mainframe, which was rumoured to take one week to boot DOS.

Bear in mind the architecture differences between a micro-processor and a mainframe. Mainframe CPUs were (maybe still are) slow even by their contemporary standards. The whole point of a mainframe is that the machine is mostly co-processors, which do most of the work.

I remember the days when they attempted to port Pr1mos to Intel - so the story goes it was a disaster. The 50-series CPU relied on the segmented virtual memory architecture, and the 80386 (I think that was the chip) was hopeless.

So no, I don't believe it wasn't feasible in the 90s. It was just that the x86 architecture was sweeping everything else away (thanks to the IBM PC), and all the awful design decisions that went into it effectively hindered and hamstrung a lot of far more superior work. As usual, "cheap but crap" won the battle, but cost us the dear.

Cheers,
Wol

A local root vulnerability in glibc

Posted Oct 6, 2023 17:11 UTC (Fri) by mpr22 (subscriber, #60784) [Link]

IBM have, in recent years, been more than happy to boast that their mainframe CPU cores, of themselves, are the fastest microprocessors in the business :)

Intel iAPX432

Posted Oct 8, 2023 8:05 UTC (Sun) by CChittleborough (subscriber, #60775) [Link] (4 responses)

If you mean the Intel iAPX432, it was created in the 1980s. It was a fairly vertical microprogram with enormous amounts (for the day) of microcode on chip. That microcode provided an ISA which was a superset of what Ada needed: a multitasking operating system with capabilities and concurrent garbage collection in Silicon. One of the superset features was that a called procedure could survive returning to the caller, like call/cc in Lisp. To do this, the microcode had to allocate the frame for each called procedure on the stack. When they got it running, they found that it could do 50 procedure calls per second: a bare procedure call took an average of 20 ms.

Wikipedia has a relatively decent article on this, though it leaves out the 50 calls/sec bit (which I heard in a talk by Prof Ed Gehringer).

Intel iAPX432

Posted Oct 8, 2023 8:07 UTC (Sun) by CChittleborough (subscriber, #60775) [Link]

Err, the point I meant to make is that I do not think the capability addressing was the main problem with the 432.

Intel iAPX432

Posted Oct 8, 2023 14:03 UTC (Sun) by jem (subscriber, #24231) [Link] (1 responses)

To be precise, the project was started in 1976, and the product was launched in 1981. Meanwhile, to defend against competitors like Motorola and Zilog, Intel introduced the 8086 as a stopgap solution. We all know what happened after that.

From the Wikipedia article: "The iAPX 432 instructions have variable length, between 6 and 321 bits." Maybe partially as a reaction to this madness, something else was emerging from Berkeley: RISC. Roughly at the same time, in popular music, psychedelic progressive rock was replaced by punk rock.

Intel iAPX432

Posted Oct 9, 2023 2:17 UTC (Mon) by CChittleborough (subscriber, #60775) [Link]

Thanks for correcting me about the dates. Thanks also for the memorable, amusing and insightful analogy between RISC and punk rock!

Intel iAPX432

Posted Oct 9, 2023 9:02 UTC (Mon) by james (guest, #1325) [Link]

There is a fascinating oral history interview with Bob Colwell, senior architect on the Pentium Pro and the Pentium 4. He says (PDF, sorry) that in 1984:

...we went up to this bar where I struck up a conversation with some random guy I didn't know sitting next to me. He asked me what I was doing at Intel for the summer. I said "I'm a grad student doing some research on the 432." "Really? What kinds of things are you finding?" I said "Well, I'm finding that there's a huge disconnect between the software and the hardware. I mean the hardware should be capable of doing a procedure call much quicker than it's actually doing, for instance, it's taking many hundreds of clock cycles. And in other places, I'm seeing all kind of wastage from the compiler just setting variables that never get used, classic stuff you just don't do." And the guy said "Really? I mean tell me more about that part."
Eventually, I said "Okay, who are you? You know way too much about this technology." He tells me "I'm the leader of the compiler team." And I said "In that case I probably just fatally offended you." He said "No, not at all because I know we generate bad code and I don't care." He said "We don't like the 432 hardware team." And I thought "Oh my God, there is no hope that this project is going to work when you have the two main casts killing each other." He said "That hardware team never listened to us compiler folks At some point we decided that we'd live up to the letter of the contract but beyond that? No."

and

Well somewhere along the way, they threw away a little bit too much performance, and if they had been paying attention to that aspect of it, I think that they could have fixed those pieces, and if they made peace with the compiler guys they could have fixed that part of it too. They could have actually got within shouting distance of a competitive part. But, as it was, there were so many mistakes that there was no way to recover from them all.

It's a fascinating read.