• tchize (cs)

    I've got to like this :)

  • Zac (unregistered)

    And... cue the buffer overflow

  • PiisAWheeL (cs)

    Awesome Comment Enabled!

  • Larry (unregistered)

    Wow! Third! I am so fucking awesome! This never happened to me before in my life. The gods are finally smiling on me. Everyone will have to read my comment.

    Hmm.

    Now if only I had something to say.

  • DonaldK (unregistered) in reply to Larry
    Larry:
    Wow! Third!

    Third? Your counter must be zero-based.

  • the beholder (unregistered)

    We all know that if your app is going slow the obvious solution is to throw more hardware at it. We just never knew what to do if you can't do or exhaust that option. Now we know!

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered)
    static char *tdwtfname = "HyperTurbo 256-bit, AwesomeAkismet enabled";
    Oh boy, now we'll be back to five a week!
  • Doctor_of_Ineptitude (unregistered)

    A WTH (What The Huhh) framework app running off a 256-bit HyperTurbo CPU with AwesomeCache enabled, what possibly could have slowed it down.

    On the other hand, the WTH frame does suffer from Relative syndrome. Now if only the CPU honoured the UNCLE flag.

  • John Doe (unregistered)

    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!

    My second attempt was much more successful. I went over to the DecWriter (a hardcopy terminal) Bill had recently used, tore off the last several pages, and flipped back to where he had logged in. There was a button you could push to turn off echoing while you entered your password, but nobody bothered, because as soon as you hit Return the system would print asterisks and hashes etc. over your password rendering it unreadable.

    Or not.

    It wasn't hard to see that his password was "Jeni", his wife's name.

    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!

  • Tasty (unregistered) in reply to Doctor_of_Ineptitude
    Doctor_of_Ineptitude:
    A WTH (What The Huhh) framework app running off a 256-bit HyperTurbo CPU with AwesomeCache enabled, what possibly could have slowed it down.

    On the other hand, the WTH frame does suffer from Relative syndrome. Now if only the CPU honoured the UNCLE flag.

    The CPU was saying uncle!

  • Nagesh (unregistered)

    This ain't being good solution. If unemploymented, modole is ain't making sence to casual observer, yet is having fer reaching efects for entire system.

  • Se (unregistered) in reply to Zac
    Zac:
    And... cue the buffer overflow
    From arch/x86/include/asm/processor.h: char x86_model_id[64];

    So there's no buffer overflow here :)

  • squidfood (unregistered)

    It's good practice. Every optimization should include a placebo.

  • chooks (cs)

    It's been a while since my C days, so...the real WTF is not using strncpy?

  • PiisAWheeL (cs) in reply to chooks
    chooks:
    It's been a while since my C days, so...the real WTF is not using strncpy?
    Objection: Asked and answered your honor.
    squidfood:
    It's good practice. Every optimization should include a placebo.
  • Dave-Sir (unregistered) in reply to chooks
    chooks:
    It's been a while since my C days, so...the real WTF is not using strncpy?
    TRWTF is strncpy. Hint: It doesn't terminate the string when you would most want it to.
  • Gazzonyx (cs) in reply to John Doe
    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?

  • JimboJones (unregistered)

    I gotta ask - was that really the CPU ID string used in the solution, or is it an anonymized string used to avoid vendor unhappiness with this site? I just find it a little hard to believe that the Chief Developer could identify an "inferior, off-brand" CPU, but let a completely fictitious CPU slide.

    I think I would have been tempted to request documentary evidence of the performance increase from the Chief Developer, and then revealed the CPU ID switch with an aim to discredit him.

  • TheCPUWizard (cs) in reply to John Doe
    ...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.

  • Nagesh (cs)

    This sound like made up fake story to me.

  • F (unregistered) in reply to TheCPUWizard
    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.

    He didn't say the DECWriter was connected to the mainframe, only that Bill had just been using it. The likelihood of someone using the same password for both his VAX account and his mainframe account, back then, would have been close to 100%. Especially someone who didn't turn off echo when typing his password.

  • F (unregistered) in reply to Nagesh
    Nagesh:
    This sound like made up fake story to me.

    If you're going to have a fake story, it might as well be a made-up one.

  • Matt (unregistered)

    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!

  • n_slash_a (unregistered)

    TRWTF is using loff_t i; instead of int i;

  • synp (unregistered) in reply to John Doe
    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

  • Jim Rees (unregistered) in reply to TheCPUWizard

    We had large numbers of ascii terminals connected to our System 360 running MTS at University of Michigan, through a device called a Data Concentrator, which was a pdp-11 with a bunch of rs232 line cards. The ascii terminals included ASR33 teletypes, DECwriters, Tektronix 4014s, Silent 700s, etc. This was a common configuration at the time.

    Also, the DEC-10 was often considered a mainframe, although it was tiny compared to the 360.

  • fizzbuzz (unregistered) in reply to Nagesh
    Nagesh:
    This ain't being good solution.

    "Ain't?"

    Nagesh is from South Carolina now? Mississippi, perhaps?

  • Anon (unregistered) in reply to JimboJones
    JimboJones:
    I gotta ask - was that really the CPU ID string used in the solution, or is it an anonymized string used to avoid vendor unhappiness with this site? I just find it a little hard to believe that the Chief Developer could identify an "inferior, off-brand" CPU, but let a completely fictitious CPU slide.

    I think I would have been tempted to request documentary evidence of the performance increase from the Chief Developer, and then revealed the CPU ID switch with an aim to discredit him.

    I think you'll find the replacement id was annoymized for comic effect. The original was probably AMD (which must of had a 40% market share at some point in the past).

  • Nickster (unregistered) in reply to 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...

    I used to use a DECWriter attached to a Harris 400 on campus, which is evidently classified as a "supermini." My guess is the OP was referring to a large, installed, non-portable computer with a beefy OS as the "mainframe" even if it was technically a mini or supermini. It didn't take long for these small (read: refrigerator-sized) computers to surpass the mainframes of yesteryear in computing power. The operating systems they used worked pretty much like mainframe OSes anyway.

  • Jack (unregistered) in reply to fizzbuzz
    fizzbuzz:
    Nagesh:
    This ain't being good solution.

    "Ain't?"

    Nagesh is from South Carolina now? Mississippi, perhaps?

    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.

  • Nagesh (unregistered) in reply to Jack
    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.

  • titanofold (unregistered) in reply to chooks

    Nope, it's that it didn't follow the GNU style guidelines.

    acsi: I'm no' gonna acsi agun...pick up your room!

  • Nagesh (unregistered) in reply to fizzbuzz
    fizzbuzz:
    Nagesh:
    This ain't being good solution.

    "Ain't?"

    Nagesh is from South Carolina now? Mississippi, perhaps?

    I am Indian only from Hyderabad.

  • Gibbon1 (unregistered) in reply to fizzbuzz
    fizzbuzz:
    "Ain't?"

    Nagesh is from South Carolina now? Mississippi, perhaps?

    Nagesh learned English at the Baptist run Gen Lee Missionary School in Hyderabad.

  • vt_mruhlin (unregistered)

    Call me crazy, but shouldn't you have just bought 1 HyperTurbo CPU and installed it in a test machine, then ran your load tests to prove that performance still sucked with the new CPU?

    That would be a lot easier and more ethical than lying to your boss, and would carry the added benefit of maybe actually getting the problem fixed.

  • Hexadecima (unregistered) in reply to TheCPUWizard

    PDP-10s, PDP-11s, and VAXen were all considered mainframes by the late eighties, when the term no longer meant "the CPU cabinet is the size of a refrigerator" and meant instead "that big box that everyone dials into." This was especially prominent once the microcomputer era began.

    Also, there were still lots of big non-IBM mainframes around when the DECwriter was introduced in the early seventies. :)

  • herby (cs) in reply to Doctor_of_Ineptitude
    Doctor_of_Ineptitude:
    A WTH (What The Huhh) framework app running off a 256-bit HyperTurbo CPU with AwesomeCache enabled, what possibly could have slowed it down.

    On the other hand, the WTH frame does suffer from Relative syndrome. Now if only the CPU honoured the UNCLE flag.

    Maybe using the UNCLE flag opened up channel D. You never know.

  • Ken B. (unregistered) in reply to TheCPUWizard
    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.

    What would you consider a KL-10 to be? That's what the DecWriters at my college were connected to back in 19(mumble-mumble). Given that it took up numerous cabinets in the computer room (behind the locked sets of doors, but visible through the pane-glass windows), I think "mini" doesn't fit. Sounds like "mainframe" to me.

  • The Great Lobachevsky (cs) in reply to Ken B.

    KL-10 was a variety of PDP-10

    http://en.wikipedia.org/wiki/PDP-10#KI10_and_KL10

  • AGray (unregistered)

    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?

    CAPTCHA: Transverbero - A word that becomes movement...

  • Mcoder (cs) in reply to AGray
    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.

  • Anonymous (unregistered) in reply to Matt
    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.
  • Anonymous (unregistered) in reply to Anonymous
    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.
    I also edit hosts file to redirect bing.com to google.com
  • facilisis (unregistered) in reply to Jack
    Jack:
    fizzbuzz:
    Nagesh:
    This ain't being good solution.

    "Ain't?"

    Nagesh is from South Carolina now? Mississippi, perhaps?

    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.
    Yes, he's quite old now. Unfortunately even if he dies of old age, he'll probably be reincarnated as an even bigger wtf than he is already.

  • Vanders (cs) in reply to fizzbuzz
    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.

  • Norman Diamond (unregistered) in reply to TheCPUWizard
    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.

    OK, since you're involved in historical computing, you need to acquire some historic IBM manuals. For the 360 and 370, which must be considered mainframes even by yourself, an IBM manual explained the absurd manner in which ASCII values would be transfered from ASCII terminals to the computer's core memory. The parity bit was preserved, affecting the value visible by the user. Each byte had its 8 bits reversed, including 7 bits of ASCII value and 1 bit of parity. The TR instruction didn't care how absurd the translation table was, so it happily converted the input to EBCDIC or converted back to IBMSCII for output.

    Terminals made by IBM used other weird character sets. The 2741 came in two varieties which needed different translation tables. However, the 2741 was good for security. I removed the typeball before typing my password and then put the typeball back on afterwards.

    I don't remember what I did on ASR33 teletypes. Maybe I ripped out the part of the paper where my password had been partly covered up.

  • Friedrice the Great (unregistered) in reply to Jack
    Jack:
    fizzbuzz:
    Nagesh:
    This ain't being good solution.

    "Ain't?"

    Nagesh is from South Carolina now? Mississippi, perhaps?

    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.

    Old enough to retire yet? Please?

  • Coyne (cs) in reply to Norman Diamond
    Norman Diamond:
    For the 360 and 370, which must be considered mainframes even by yourself, an IBM manual explained the absurd manner in which ASCII values would be transfered from ASCII terminals to the computer's core memory. The parity bit was preserved, affecting the value visible by the user. Each byte had its 8 bits reversed, including 7 bits of ASCII value and 1 bit of parity. The TR instruction didn't care how absurd the translation table was, so it happily converted the input to EBCDIC or converted back to IBMSCII for output.

    The reversal of bits was a requirement of RS-232, which transmits bits in LSB-first order, by standard. So a "C" character, normally considered 0100 0011 in ASCII was sent with a start bit of 0 and a stop bit of 1, as 0 1100 0010 1. (An idle line was normally mark or 1 and so if you could consider the idle line as a series of ones, a single C would be sent as ...111110<span style="color:red;">11000010</span>11111111...)

    For ASCII, the parity bit was normally in the MSB position of the 8 bits, because the ASCII code assignments in that era actually used only the lower 7 bits (of 8). Parity would not typically be visible on the terminal (though it might indicate an error if the parity was wrong). But, yes, one would be able to TR ASCII-with-parity into normal EBCDIC characters or vice-versa, since both were 8 bits.

    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.

  • Computer Clown (unregistered) in reply to Gazzonyx

    It smells suspiciously like Honeywell GCOS, which allowed such tomfoolery. Back in the day, you could do some very (nasty|cool) things, like deliberately cause a system program to fail, and specify the file that the coredump went to. Ok, it involved rumaging through the object code, but you could patch it, and send it on it's way, altered to your specification.

  • Computer Clown (unregistered) in reply to John Doe
    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!

    My second attempt was much more successful. I went over to the DecWriter (a hardcopy terminal) Bill had recently used, tore off the last several pages, and flipped back to where he had logged in. There was a button you could push to turn off echoing while you entered your password, but nobody bothered, because as soon as you hit Return the system would print asterisks and hashes etc. over your password rendering it unreadable.

    Or not.

    It wasn't hard to see that his password was "Jeni", his wife's name.

    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!

    It smells suspiciously like Honeywell GCOS, which allowed such tomfoolery. Back in the day, you could do some very (nasty|cool) things, like deliberately cause a system program to fail, and specify the file that the coredump went to. Ok, it involved rumaging through the object code, but you could patch it, and send it on it's way, altered to your specification.

Leave a comment on “Confessions: The Soft CPU Upgrade”

Log In or post as a guest

Replying to comment #:

« Return to Article