Comment On Confessions: The Soft CPU Upgrade

Mcoder:

It is not vapour. Placebo effect is quite real.

I prefer the darker explanation -- that somewhere deep in the operating system, Intel had paid to have this logic inserted:

if (cpu_id != genuine_intel) run_everything_50_percent_slower();

Anonymous:

Matt:

Kinda like the time I installed Firefox on a user's PC, put a shortcut on the desktop, renamed the shortcut "Internet Explorer," and give it IE's icon. Whatever gets the job done!

I usually replace iexplore.exe with firefox.exe and get the IE theme just in case.

Ralph, to whom target="_blank" represents an evil rivaled only perhaps by the Holocaust itself, will be along shortly to conduct your reeducation.

Strncpy isn't much safer than strcpy in reality. It won't write more than N characters, but if your source exceeds N it won't null terminate you target either. It's not intended be a safer strcpy, just another strcpy.

John Doe:

Unfortunately when I tried to write to that memory location I discovered a little feature called hardware enforced access control. It was a read-only address for my process. Drat!

You obviously didn't try hard enough. Read "The Adolescence of P-1."

Nagesh:

This sound like made up fake story to me.

It ain't

synp:

John Doe:

Fast forward a couple decades and attacking the system is still a waste of time when it is so easy to hack the user. How little we've learned!

That's because we're getting new and better systems all the time, but we've been using the same model user for millenia

Me find fire cook bear

Nagesh:

Jack:

Last week he "learned" the phrase "If it ain't broke, don't fix it." Ever since then, he's been using "ain't" in every post. It's getting pretty old. But then, the fake Nagesh has been getting old for a long time.

We're all getting old.

Granted, some of us have been at it for longer than others.

Birthdays maybe good for you. Studies show those who have the most die the oldest. Some scientists claim the opposite, citing the clear corelation between how many you have left at any time in your life and your proximity to death, however these claims have generally been disimissed as scaremongering.

Coyne:

Rumor had it that the exact translation table from ASCII to EBCDIC was an IBM trade secret that was actually kept on paper in a vault for safekeeping. And one would guess it still is since I have seen (and been frustrated) by multiple, but slightly different, translation tables.

Well, there are EBCDIC-based codepages just like there are ASCII-based codepages. This link lists several dozens of them:
http://www-03.ibm.com/systems/i/software/globalization/codepages.html

Jeremy Friesner:

Mcoder:

It is not vapour. Placebo effect is quite real.

I prefer the darker explanation -- that somewhere deep in the operating system, Intel had paid to have this logic inserted:

if (cpu_id != genuine_intel) run_everything_50_percent_slower();

Hey that looks like the Intel C compiler !

OOLCAY ITAY:

John Doe:

Unfortunately when I tried to write to that memory location I discovered a little feature called hardware enforced access control. It was a read-only address for my process. Drat!

You obviously didn't try hard enough. Read "The Adolescence of P-1."

Call Gregory?

TheCPUWizard:

...multi-user mainframe....DecWriter (sic)

It is DECwriter...made by...wait for it...DEC [Digital Equipment Corp]. The vast majority of these were used for PDP-11 and VAX computers, both of which were considered Mini computers and not mainframes...

Given that nearly evry mainframe of that time period was EBCDIC based, and the DECwriter was ASCII, it would be extremely suprising to see that combination.

Since I am involved in historical computing (and a member of a number of Musuems and Rescue organizations), I would be very interested in getting more information about this extremely suprising configuration.

Go back and study your history a bit more, then.

I clearly recall logging in to MTS running on an IBM 3081D (dual processor machine, commonly referred to as "Sybil") via a VT-100 (also an ASCII terminal, and from DEC) on the RPI campus back in 1985...

the real wtf is not using const char* for string constants

wtf:

the real wtf is not using const char* for string constants

That's because the value might change in a newer version to an even newer CPU system! Tss... that was not so hard.

AGray:

So, lemme get this straight.

WTF #1: Writing a fictional hardware type to the operating system (provides no performance impact, but prevents insidious ID-10T Runtime errors.) I can buy that.

WTF #2: The 'improvement' in performance. Was it entirely vapor, or did some refactoring take place behind the scenes?

Saving face. Chief Developer claims that the performance problem isn't due to his WTF software architecture but to subpar hardware. When presented with evidence that the hardware has been upgraded, and lacking the necessary knowledge to even suspect that it's a fraud, he can either admit that his architecture is a WTF or claim that the performance problem is now fixed.

Just because the snippet uses strcpy instead of strncpy, that doesn't mean there's a buffer overflow. It's copying a static, compiled-in string, which is automatically zero-terminated by the compiler... not some user-provided input.

TheCPUWizard:

...multi-user mainframe....DecWriter (sic)

It is DECwriter...made by...wait for it...DEC [Digital Equipment Corp]. The vast majority of these were used for PDP-11 and VAX computers, both of which were considered Mini computers and not mainframes...

Given that nearly evry mainframe of that time period was EBCDIC based, and the DECwriter was ASCII, it would be extremely suprising to see that combination.

Since I am involved in historical computing (and a member of a number of Musuems and Rescue organizations), I would be very interested in getting more information about this extremely suprising configuration.

At UMASS/Amherst, in the late 70s, we had a CDC Cyber 74 mainframe. It had, IIRC, a "Tempo" minicomputer (based on a Perkin-Elmer mini?), which was used as a front end processor. Along with multiplexing all the terminal lines, it was also used to convert ASCII to EBCDIC (or whatever 6-bit code CDC used). We had Teletypes, Selectrics, Diablo daisywheels, DECwriters and an assortment of CRTs, all hooked to the mainframe (via the Tempo) through dial-up and hardwire. Everything but the Selectrics used ASCII, and the Selectrics identified themselves by you pressing a different key after dialing in and getting a carrier.

Vanders:

fizzbuzz:

Nagesh:

This ain't being good solution.

"Ain't?"

Nagesh is from South Carolina now? Mississippi, perhaps?

Nagesh almost becomes funny again if you read every comment in a hick Southern accent.

It would be really funny if it turned out that fake Nagesh was really from Mississippi and that was really how he talked.

Peter:

At UMASS/Amherst, in the late 70s, we had a CDC Cyber 74 mainframe. It had, IIRC, a "Tempo" minicomputer (based on a Perkin-Elmer mini?), which was used as a front end processor. Along with multiplexing all the terminal lines, it was also used to convert ASCII to EBCDIC (or whatever 6-bit code CDC used). We had Teletypes, Selectrics, Diablo daisywheels, DECwriters and an assortment of CRTs, all hooked to the mainframe (via the Tempo) through dial-up and hardwire. Everything but the Selectrics used ASCII, and the Selectrics identified themselves by you pressing a different key after dialing in and getting a carrier.

The 6-bit code was CDC Display Code (yes, you could abbreviate it as CDCDC, I suppose). It had the oddity of not having lower case letters, and a related oddity: '\000' == ':' was true.

EBCDIC is an 8 bit code (Extended BCDIC) that was baked into the System/360 (well, S/370 certainly) instruction set. (Seriously - the EDIT instruction formatted a 32-bit int into an EBCDIC character field.)

Pedantry: there were various versions of EBCDIC, but all of them shared an interesting feature: a for-loop from 'A' to 'Z' was more than 26 iterations, because the letters were in three separate ranges. I'd like to think that the origins of this are lost in the mists of time, but the clue is "punch cards"...

PedanticCurmudgeon:

Vanders:

fizzbuzz:

Nagesh:

This ain't being good solution.

"Ain't?"

Nagesh is from South Carolina now? Mississippi, perhaps?

Nagesh almost becomes funny again if you read every comment in a hick Southern accent.

It would be really funny if it turned out that fake Nagesh was really from Mississippi and that was really how he talked.

I think he's from "Missippibad", it's in South India. Built up around the Ganges Delta, they're famous for their Curry Creole in those parts.

Mcoder:

AGray:

So, lemme get this straight.

WTF #2: The 'improvement' in performance. Was it entirely vapor, or did some refactoring take place behind the scenes?

It is not vapour. Placebo effect is quite real.

Either that, or the "chief developer" saw no improvement, yet claimed his tests showed there was, in order to protect his own claim that it was the "inferior, off-brand" CPU which was the cause.

Friedrice the Great:

Jack:

The fake Nagesh has been getting old for a long time.

Old enough to retire yet? Please?

I think he's funny. Even the "real Nagesh"/"fake Nagesh" thing has its moments.

Hard and fast rules are stupid. There is no need to use strncpy to move a string that is constant you yourself just created. You know for sure its terminated and you know how many bytes it is.

The never ever ever use strcpy crowd is mindless.

Jeremy Friesner:

Mcoder:

It is not vapour. Placebo effect is quite real.

I prefer the darker explanation -- that somewhere deep in the operating system, Intel had paid to have this logic inserted:

if (cpu_id != genuine_intel) run_everything_50_percent_slower();

It's not at the operating system level.

Quite a while ago, I had some purchased programs that used the Intel compiler and libraries.

The Intel compiler generated code to check the CPU string, and if it's not 'genuineintel' then it runs the slowest version of many algorithms. (Maybe it doesn't do that any more?)

So I patched the application's libraries to search for "authenticamd" instead of "genuineintel" and poof, they started running faster! What a coincidence that both of those strings have the exact same number of characters.

http://www.agner.org/optimize/blog/read.php?i=49#49


True story!

Steve The Cynic:

there were various versions of EBCDIC, but all of them shared an interesting feature: a for-loop from 'A' to 'Z' was more than 26 iterations, because the letters were in three separate ranges. I'd like to think that the origins of this are lost in the mists of time, but the clue is "punch cards"...

Indeed.

EBCDIC was perhaps the original WTF, or certainly a contender. If you sort a bunch of stuff (not just alpha chars) it would end up something like a, b, c, d, e, f, g, h, i, a bunch of weird garbage, j, k, l... so you had to add code to set the crap to one side and gather the alphabet together. And this was back in the day when your penis size was basically 100 minus the number of bytes in your compiled code, so adding code for silly reasons was Not Good.

I hate model-view-controller. Not because it's bad architecture, which for the intended use case it isn't.
I hate it because it's easy to remember and the name rolls of the tongue (even though it's wrong, it should be view-controller-model) and this makes a certain class of programmer think ‘model-view-controller’ no matter what.
I've seen someone stack a model-view-controller on top of a component that was designed to take the burden of writing it off your shoulders. And then later use (a proxy for) the view as the model in another model-view-controller layer somewhere else in the code.
You get greeted by a seemingly endless tower of stacked model-view-controllers, that do essentially nothing but waste CPU time. And programmer time when something goes wrong and it's time to debug the bloody contraption.

Wouldn't the CTO have to approve the purchase of new equipment ?
I'm guessing that it would have been a significant cost that could not have been overlooked.

John Doe:

When I found it, I tried to overwrite that string with "bill", reasoning I would thereby become bill as far as the system knew. Sorta like a soft CPU upgrade, you see?

Meh. It was easier to just rummage through the wastebasket looking for discarded username/password cards.

TheCPUWizard:

...multi-user mainframe....DecWriter (sic)

It is DECwriter...made by...wait for it...DEC [Digital Equipment Corp]. The vast majority of these were used for PDP-11 and VAX computers, both of which were considered Mini computers and not mainframes...

Given that nearly evry mainframe of that time period was EBCDIC based, and the DECwriter was ASCII, it would be extremely suprising to see that combination.

Since I am involved in historical computing (and a member of a number of Musuems and Rescue organizations), I would be very interested in getting more information about this extremely suprising configuration.

"extremely surprising" doesn't sound right to me. In that time period, it was not remarkable to interface equipment that used different character encodings.

The ALGOL 60 compiler on the DECSystem 10 could support strings of 6, 7, 8 or 9 bit bytes, all in the same program. They were automatically converted from one size/encoding to another, or not, depending what you were doing. I suppose there must have been 5 bit characters too (for teletypes that use BAUDOT), and of course there was the RADIX-50 encoding used to store file names on the PDP-11 node controllers. I don't think I ever saw EBCDIC on a DEC-10 -- it had a card reader, but I don't know if the mainframe received EBCDIC, ASCII, or just 12 bit Hollerith codes when it was reading cards. It was ASCII by the time it got to my program.

The Burroughs mainframes used EBCDIC internally, but I only ever used ASCII terminals (including a DECWriter) and punched cards to talk to it. (Unless you count the printing terminal attached to the RJE station, but it could only list the job queue.)

You could buy a box that would make an IBM 370 think that your ASCII serial terminals were 3270s. You couldn't run XEDIT on a printing terminal, but I seem to remember some sort of hacky way you could do simple things like directory listings. I was working computer support at the time, so I must have used it -- on a DECWriter, because those were the only printing terminals we had.

static const *char, and what about checking boundaries of x86_model_id?

I've got some bad news guys.

My friend and lover, Alex, has suddenly and unexpectedly passed, and we are currently trying to evaluate how this site is going to operate in his absence. I know that during his tenure, he has never failed to post an article, and I'm sorry that we have to break that perfect streak. To be honest, I don't even know if we are going to keep this sight going knowing where he is right now.

Keep him and me in your prayers for sure.

Remy Martin:

I've got some bad news guys.

My friend and lover, Alex, has suddenly and unexpectedly passed, and we are currently trying to evaluate how this site is going to operate in his absence.

Probably undetectable difference from how it was before.

Remy Martin:

I don't even know if we are going to keep this sight going

It isn't a sight, it is a site! Site! SITE!!! Puh-leease.

Kindly follow Alex off whatever cliff he dove. Thank you.

[quote user="TheCPUWizard"]
It is DECwriter...made by...wait for it...DEC [Digital Equipment Corp]. The vast majority of these were used for PDP-11 and VAX computers, both of which were considered Mini computers and not mainframes...
[/quote]

The majority of women are under 5' 10". Therefore, if someone tells you that a woman he knows is 5' 11", he must be lying. Umm, no. If there is one exception in the world, then the person may be referring to that exception. I question if it's even true that the "vast majority" of DecWriters were connected to PDP-11s and VAXes. I used DecWriters with PDP-10s and PDP-20s back then. Which, by the way, I think would be called mainframes. At least, they were big boxes that served a large number of users.

[quote user="TheCPUWizard"]
Given that nearly evry mainframe of that time period was EBCDIC based ...[/quote]

I have heard rumors that there used to be companies other than IBM. Remember Sperry, Univac, Burroughs? Okay, Amdahl used EBCDIC.
[/quote]

Anonymous:

static const *char, and what about checking boundaries of x86_model_id?

You can check the boundaries yourself. It's open source.

arch/x86/include/asm/processor.h:
char x86_model_id[64];

It fits.

Then you bitch about not having enough budget to make the app work properly. Just like the gov't set out to do something that everyone else thinks will fail, then when it fails, say it's because you didn't have enough money/power, then increase budget and repeat.

(Deleting this comment failed for some reason)

TRWTF is the use of (&foo)->bar instead of foo.bar

(&cpu_data(i))->x86_model_id

He's Dead Jim:

Steve The Cynic:

there were various versions of EBCDIC, but all of them shared an interesting feature: a for-loop from 'A' to 'Z' was more than 26 iterations, because the letters were in three separate ranges.

EBCDIC was perhaps the original WTF, or certainly a contender. If you sort a bunch of stuff (not just alpha chars) it would end up something like a, b, c, d, e, f, g, h, i, a bunch of weird garbage, j, k, l... so you had to add code to set the crap to one side and gather the alphabet together.

Just like today, where letters like Á, b, ç, Z, ï, ñ, ß, and æ have to be gathered together.

Oops wait, I just remembered, there's only one country in the world. Well, that country has ñ and á.

The never ever ever use strcpy crowd is mindless.

Yep. You have to know the rules before you break them. The whole point is to be in control of your code. If you're defining the string constant yourself, you're in control of it. Know why the rule exists.

For n00bs who don't know the strcpy/strncpy issue, here's the lowdown:

* if you use strcpy with a null-terminated source string and the it is longer than your destination buffer (or worse, isn't actually null-terminated at all) you will overrun your buffer because strcpy will happily keep copying from the source to the destination 'til the cows come home.

* If you know the size of your destination buffer (you should), it doesn't matter whether the source string terminates before the end of the buffer, because you can specify you want to copy n bytes into a buffer of size n. Then set the last byte of the buffer to null, and you're done. Safe as houses!

Gazzonyx:

What OS was this? You'd think the OS would segfault when you tried to write to memory outside of your process' allocated memory. Isn't that the usual thing to do?

Thank you Captain Tautological, Defender of the Infinitely Likely Truth!

Nickster:

The never ever ever use strcpy crowd is mindless.

Yep. You have to know the rules before you break them. The whole point is to be in control of your code. If you're defining the string constant yourself, you're in control of it. Know why the rule exists.

For n00bs who don't know the strcpy/strncpy issue, here's the lowdown:

Stick with PHP.

FTFY.

Gazzonyx:

john doe:

This reminds me of one of my first hacking attempts. It was a multi-user mainframe, and as a student my user ID didn't have what I considered sufficient access rights. But I knew one of the admins, let's say "bill", did. So I wrote a fortran program to deliberately overflow its array boundaries and go tromping through "core" looking for the address where my user ID was stored. When I found it, I tried to overwrite that string with "bill", reasoning I would thereby become bill as far as the system knew. Sorta like a soft CPU upgrade, you see?

Unfortunately when I tried to write to that memory location I discovered a little feature called hardware enforced access control. It was a read-only address for my process. Drat!

What OS was this? You'd think the OS would segfault when you tried to write to memory outside of your process' allocated memory. Isn't that the usual thing to do?

Older computers/OS do not have this ridiculous security protections. Its your computer, your OS, your software, if you want to "POKE 47196, 201", that's your business.

Incidentally, I've actually used the first hacking approach mentioned by john doe on a BBC Micro/Econet network to change the network address of my computer to that of the administrator, which allowed me to access quota related commands to up my shared disk quota to a whole 48k. You had to keep the administrator occupied and away from their desk, Econet didn't play very well with two machines declaring the same id, which kind of gave the game away.

Remy Martin:

I've got some bad news guys.

My friend and lover, Alex, has suddenly and unexpectedly passed, and we are currently trying to evaluate how this site is going to operate in his absence. I know that during his tenure, he has never failed to post an article, and I'm sorry that we have to break that perfect streak. To be honest, I don't even know if we are going to keep this sight going knowing where he is right now.

Keep him and me in your prayers for sure.

I hope you guys are in Massachusetts. Otherwise, good luck collecting on your inheritance.

Norman Diamond:

This junk has a long history. Even Charles Babbage was vilified for trying to remove bugs from tables of logarithms.

It was well known in his time that these tables contained errors, and he did want to fix them, but to the best of my knowledge he wasn't vilified for that. However, he did make an interesting find: the same errors showed up in almost all tables, proving that almost everyone had been copying Vlacq.

TRWTF is that it doesn't compile on Linux. Of course no specific version was specified, so I tried RHEL 5.4 and SLES 9, which were the most convenient test boxes that I had access to.

[root@testbox2][/root]# cc -c wtf.c

wtf.c:1:26: error: linux/module.h: No such file or  directory

wtf.c:3:23: error: linux/smp.h: No such file or directory

wtf.c: In function 'init_module':

wtf.c:9: error: 'loff_t' undeclared (first use in this function)

wtf.c:9: error: (Each undeclared identifier is reported only once

wtf.c:9: error: for each function it appears in.)

wtf.c:9: error: expected ';' before 'i'

wtf.c:11: error: 'i' undeclared (first use in this function)

wtf.c:11: error: 'nr_cpu_ids' undeclared (first use in this function)

wtf.c:12: warning: incompatible implicit declaration of built-in function 'strcpy'

wtf.c:12: error: invalid lvalue in unary '&'

Meep:

Nickster:

For n00bs who don't know the strcpy/strncpy issue, here's the lowdown:

Stick with PHP.

FTFY.

Right... because you knew everything on your first day of learning C, right?

Shinobu:

Norman Diamond:

This junk has a long history. Even Charles Babbage was vilified for trying to remove bugs from tables of logarithms.

It was well known in his time that these tables contained errors, and he did want to fix them, but to the best of my knowledge he wasn't vilified for that. However, he did make an interesting find: the same errors showed up in almost all tables, proving that almost everyone had been copying Vlacq.

How did that get here? Oh I know. These threads must have got mixed up when they stomped on each other's memory.

The Science Museum, London, had an exhibit on Charles Babbage in 1999. That's where I read that he was vilified for trying to fix bugs in tables of logarithms.

bad_management:

TRWTF is that it doesn't compile on Linux. Of course no specific version was specified, so I tried RHEL 5.4 and SLES 9, which were the most convenient test boxes that I had access to.

[root@testbox2][/root]# cc -c wtf.c

wtf.c:1:26: error: linux/module.h: No such file or  directory

wtf.c:3:23: error: linux/smp.h: No such file or directory

wtf.c: In function 'init_module':

wtf.c:9: error: 'loff_t' undeclared (first use in this function)

wtf.c:9: error: (Each undeclared identifier is reported only once

wtf.c:9: error: for each function it appears in.)

wtf.c:9: error: expected ';' before 'i'

wtf.c:11: error: 'i' undeclared (first use in this function)

wtf.c:11: error: 'nr_cpu_ids' undeclared (first use in this function)

wtf.c:12: warning: incompatible implicit declaration of built-in function 'strcpy'

wtf.c:12: error: invalid lvalue in unary '&'

It doesn't take that much massaging to make it compile. I did it at work today on my Fedora box.

Google for 'linux kernel module example' and it's pretty clear that adding about 5 lines and creating a simple Makefile will do it.

TRWTF is that it doesn't compile on Linux. Of course no specific version was specified, so I tried RHEL 5.4 and SLES 9, which were the most convenient test boxes that I had access to.

Looks like there's a dependency on kernel headers (which would normally be in the makefile, but it isn't part of the submission). Compiling a kernel module isn't quite the same as compiling a user-space application. (And I'd be very surprised if this trick were possible outside the kernel…)

TheCPUWizard:

...multi-user mainframe....DecWriter (sic)

Given that nearly evry mainframe of that time period was EBCDIC based, and the DECwriter was ASCII, it would be extremely suprising to see that combination.

If you're truly interested in historical configurations, I'm not the original poster but at the school I went to (1984-1988), we had IBM mainframes, a DEC VAX running BSD, and some other timesharing systems. In addition to 3270 terminals scattered around campus, we had ASCII terminals including decwriters, ADM 3a's, PCs with terminal emulation, etc. The ASCII side of the house was mostly connected to a Gandalf PACX, which let you choose which computer you connected to. The IBM mainframe included a front end (once a 7171, I think, but upgraded while I was there) that made the mainframe think you were coming from a 3270 terminal when in fact you were using an ascii terminal.

I know I'm late to the party with this comment, but I used to travel to Temple University in Philadelphia with a few friends after high school let out for the day to hack their CDC 6600 mainframe. Though it accepted puch card jobs (handed to an operator as well as submitted remotely via CDC 200 User Terminals via dedicated lines using a primitive 9600 baud modem), there were a few DECwriters hooked up, as well. I think that CDC definitely qualifies as a mainframe.