Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Patch for Linux 2.2.2 to Disable PIII PSN 87

Posted by CmdrTaco from the for-the-security-minded dept.
An anonymous reader wrote in to say that Phil Karn has posted a patch to Linux 2.2.2 that will disable the PSN. He says "I'm hoping that this patch (or equivalent) will soon make it into the standard Linux kernel so as to dissuade any application vendors who might be tempted to use the serial number misfeature."
This discussion has been archived. No new comments can be posted.

Patch for Linux 2.2.2 to Disable PIII PSN More

Patch for Linux 2.2.2 to Disable PIII PSN

Comments Filter:

  • Fools (Score:1)

    by Erich ( 151 )
    Having a cpuid ISN't all that bad. Most non-intellish CPU's have one. They're great for software companies that want to give you an expensive piece of software and don't want you to pirate it. It works. It doesn't automatically distribute your credit card number everywhere. It doesn't send personal infomation to people.


    I think that maybe having a top-notch UNIX (linux/freebsd) is great, but without a cpuid I think that many top-notch 3D, CAD, and hardware-simulation companies will be unwilling to port to Intel.


    Therefore, I say that having a cpuid is a good thing. Not good for the things Intel Marketing is wanting it to be used for (web/portal/sales stuff) but I think that it is good for companies that want to protect their software.

  • I don't think that Linux has to support spoofing or disabling of the cpuid. Well, I can see that disabling it might be good... but I don't think that it is necessary at all. I think that having programs not use the cpuid is probably the best move. If you don't want to have anything use the cpuid, don't run the program that reads it.

    Linux is developed for people to run Linux. Right. Need I remind you that Linux is just a kernel? what I choose to run under my kernel is entirely up to me. And being able to have a nifty kernel under my $10k piece of software. And I really laugh at your ``greedy software company.'' You must be one of those people that think that if a software company is charging $10k for a product that they don't need the extra 10 licenses that you and your friends would use. So you pirate it.

    Why has slashdot turned into a WaReZ kiddie hangout? Oh, I pine for the days in which slashdot folk talked about interesting things like pipelined cache access and number theory. Now it's John Katz writing silly articles, people flaming him for it, and stupid people complaining about how the big bad software company that makes specialized software and spends millions in research won't give them a copy for free. GROW UP! If I spend three million on research on hardware synthesis tools and then have five companies that are interested in the product, you can be darn sure that I'm not going to release it under an open source license, and you can be darn sure that I am not going to want people pirating it and stealing money from me.

    I hardly think that Linux is on the path for World Enlightenment. I think you're probably a tad delusional if you think that. It's currently one of the least-sucky OS's I've used. I currently use it on all my computers (except my NeXTStation) exclusively. But I think it's a good, inexpensive easy-to-use operating system. Not anything remotely relating to anything important, like God.

    But, yes, I think that more companies would port to Linux. And if you're using high-priced tools, You're going to get inferior forms of host identification, like dongles (requires user level access to parallel port), MAC addresses (what if you're not using ethernet?), or disk info (which may need user level access to hardware -- a *really* bad thing).

    So, I still say that the cpuid is a good thing for anti-piracy. I don't know if it's a real privacy concern, and I certainly think that if you only use software which you have the source to you can darn well compile out the necessity of having the cpuid even read.

  • But they don't have it in the processor, but on the motherboard, IIRC. So the number of CPUs is irrelevant. I'd guess that for PIII serial numbers you'll use processor 0.
  • Or at least not without running the whole program under emulation (OUCH!). The cpuid instruction isn't priviledged, so it won't fault to kernel mode when executed, thus it cannot be simulated automatically. You could start up the program in a debugger, set a breakpoint after the cpuid and tweak the registers.
  • After this patch is installed, no program, or maybe just userlevel program, can enable it again?
  • ...my root password. how the hell did he guess it?!
  • If the kernel can control the PSN switching, why not make it one of those settable kernel options? Set the default when compiling the kernel to whatever the user wants, and do one of those "echo 1 > /proc/sys//psn" things to enable it.
  • Most big software vendors have already ported to Intel (with NT). They'll use the CPUID if it's there, but they can't afford to ignore popular platforms that don't have it.


    The disturbing thing about Intel's CPUID is the way they expect it to be used. If Visa (for example) distributes electronic wallet software that requires the CPUID to function, and then makes it a requirement for all on-line Visa purchaces, what are you going to do? You can protest, but the clueless masses won't care. You'll either lose the ability to shop on-line or be forced to make your CPUID available.

  • Sigh (Score:1)

    by Eccles ( 932 )
    Forgive me as a less than expert Linux user, but is there utility in having a security level between root and the average user? It seems like one might want to run installers at such a level, with write access to /usr/local/bin or some such. Can this be reasonably duplicated for most installations with group permissions?

  • Sigh (Score:1)

    by Eccles ( 932 )
    Again, please forgive my ignorance, but is the installer (run as root) prevented from setting the SUID bit? If not, couldn't it just copy over some common executable with its own version, that behaves identically except for enabling the PSN?

  • All the patch does is, at bootup, send the CPU the instruction to turn the PSN off. I'm guessing that intercepting the CPU ID instruction would be a little harder. Note that I know very little about the structure of the x86 architecture. The lowest I can go is C.

    Someone mentioned above that the CPU ID can be turned back on without rebooting. Is this true? The patch seems to rely on the fact that this bug^H^H^Hfeature can only be altered at boot time.



    --Phil (One of these days, I'll get around to learning x86 assembly.)

  • Trapping an unprivileged instruction isn't possable. The CPU won't generate a fault.

    The best possability would be a program that scans the machine code starting from the entry point, and recurses through the branches until it finds the offending instruction. Now, patch in a subroutine call that provides a selected number rather than the real one. If necessary, overwrite several instructions and carry them out in the patch. The patch routine is just crammed onto the end of the code section.

    That'd be a real pain to write, but should work. Perhaps some of the game unprotect writers from the 80s should come out of retirement?

  • If it can run the program, it can parse it.

  • Why not have it to where a user-level program (or a /proc interface) with ROOT PRIVILEGES can make the adjustment as needed? If you're running untrusted programs or installing untrusted kernel modules as root, you're a moron and deserve what you get. Perhaps have the kernel print a line to the klog saying the ID mechanism was (en|dis)abled by program ____ user ____ so that it can NOT be done secretly?

  • Sigh (Score:1)

    by Fastolfe ( 1470 )
    Exactly.

    1. Never run untrusted programs as root. PGP signatures and the like are there for a reason. If you're habitually downloading and running stuff as root without any clear idea where the program came from or who wrote it, you're just asking for trouble.

    2. Any program that is discovered to exhibit this sort of behavior will be treated like any other trojan horse. The application will be reported to the various security lists and it will be removed from download.

    It seems like everyone is pointing out these "new" threats about how people can write malicious programs to retrieve your CPU ID, but really folks, this is nothing more than a trojan. One could just as easily write in a little bit of code that retrieves your e-mail address, passwords, etc. and mails them to a collection address. The threat of having a CPU ID is negligible when compared to this.

    Trust me, if you end up running trojaned software, the CPU ID will NOT be a primary target. Think about it, folks.
  • While you certainly have that option, it's not going to make the PIII go away, which means it'll still be used with Linux, which means Linux will still need a way to control it.

    The CPU ID's could actually serve a useful purpose in a NOC or privileged network where each and every machine needs to be accounted for and identified. Since Linux is popular in these settings, it only makes sense to have the ID available for use.
  • I was just saying to a co-worker: "Now that the PIII is released, I wonder how long it will take someone to release a [Linux] kernel patch that prevents the serial # from being accessed"...

    Good work.
    --
  • Heh... We could all pick the same s/n to emulate, sort of like logging in everywhere as cypherpunks...

    "Gee, Boss, this guy with s/n 1234567890 sure seems to be hitting our site pretty heavy!" :)
  • Considering Linus works for Transmeta, presumably an Intel competitor, I think your logic is faulty.
    --
    Aaron Gaudio
    "The fool finds ignorance all around him.
  • Just kidding... :-)
  • The hilarious part to me is that just YESTERDAY somebody was pasting me an excerpt from a news item saying something to the effect that "Other operating systems such as Novell or Linux will probably not disable the ID system..." suggesting that only Win95/98 would be able to.
  • What about trapping the serial number and changing it the moment the cpu sends it out.
    You see, you know your serial number and can thus make the kernel or any other deamon cactch that number and replace it with some other number or a blank.

    Monchi

    ps my spam email adress is just a mailbox which is scanned for usefull messages and dumped.

  • Hmm (Score:1)

    by Planetes ( 6649 )
    In case you haven't noticed, Linux is a patchwork quilt of enormous dimensions. Every change to the kernel was probably a patch at one point or another.
  • Don't you just *love* open-source?
  • I thought it was discovered the serial number could be turned back on without a reboot? Does this patch do anything to prevent this?
  • yeah, what the subject says.
    --
    ...Linux!

  • Sigh (Score:1)

    by scrytch ( 9198 )
    Doesn't autoconf have a "make installdirs" target that will make just the directories, that you can then chown, or am I just on crack?

    Anyhow, if you install to a root like /opt/packagename or /usr/local/packagename, it's trivially easy to make it such that it's not owned by root and doesn't even have to be installed by root. And on my work account, i'm installing things into $HOME/soft/packagename all the time...

    Installing software in superuser-owned places is a superuser thing, that's just all there is to it.
  • If the patch traps the CPU ID instruction, it's irrelevant whether the chip thinks it's turned on or not. All you have to do is stop that instruction from reaching the chip... Now, what I would like to see it a patch that returns a random serial number instead of simply blocking the CPU ID instruction.
  • go read http://www.bigbrotherinside.com/ [bigbrotherinside.com] for the answers to your questions
  • As I said a while ago. PIII is the best support for Linux and other OSS OSes to be ever released. Now it comes to the point: either use Linux/FreeBSD, etc or loose your privacy rights.

    Lovely...

    Intel has unintentionally screwed all M$ users. Beautyful...

    I am using AMD anyway ;-)
  • Here in California, caller ID can be set to be blocked by default... (blocked to all but police and 911 and such anyway)

    and NIC numbers can be changed (at least with some cards)

  • Fools (Score:1)

    by TA ( 14109 )
    You obviously haven't thought this through.
    People are replacing the CPU in their computer all
    the time these days. Even I have (I actually forgot that for a moment..),
    and I'm no "upgrade at all costs" guy.
    Can you imagine the hassle to get all your CPU-tied license
    servers for all your "top-notch 3D, CAD, and hardware-
    simulation" tools working again after a CPU change?
    TA
  • Which seems to imply that it should be a kernel compilation option, n'est ce pas?
  • How about a PIII s/n emulator... ie. a s/n spoofer... It might be nice to see if you could spoof the s/n and cause programs to go beserk. ^_^ Might also help in those sites Intel is planning....

  • This is a new processor instruction, right? Let's say I have an application that calls this instruction, and I try to run it on a PII or something; it will generate an illegal instruction fault, right?
    If so, then the kernel's handler could spoof the instruction instead of killing the application with SIGILL.

    So it seems to me that a PIII spoofer would be possible on an older Pentium system.

    Maybe I'm way out in left field, though...
  • Why is everyone so worked up about this? Every
    ethernet card has a unique id. Why is a CPU
    id worse than that? Is two unique ids per
    computer worse than one? Could someone please
    explain this to me.
  • So, on Sun systems, the ID does not come from the CPU, but from another part on the motherboard. Even if you switch processors, the number doesn't change. On an Intel P3 system, the ID is stored in the processor itself, so changing processors changes the ID.

    I can see how this would be a pain in the ass if you wanted to upgrade near the end of the year from a 450Mhz P3 to a 550Mhz P3. You'll have to reinstall all of the software that is dependant on that ID, or at least reregister the software.

    If Intel is trying to accomplish what Sun did with their ID numbers, they ought to rethink where the ID comes from on the computer. They could stick the ID number in the motherboard chipset, or in the BIOS.

    I don't care much about all of this, though. I'm an AMD user.

    SaDan
  • i couldn't think of a more appropriate feature to belong in the kernel. disabled, by default, but nevertheless there.


  • More ideas on spoofing:

    1) all use the same PSN as a protest.
    2) use PSN's of machines at Intel.
    3) echo back the PSN from the requesting machine.

    How is the serial number request negotiated? Is it encrypted?

    -D
  • The problem is not crypto at all. The system serial info (96 bits) is provided upon request by executing a CPUID instruction. This instruction is nonpriveleged so the kernel will have a hard time trapping it.

    Thus the problem centers around how to get the kernel to trap this request and emulate, fake, or mangle it.

    Does anyone know a work around?

    here's some URL's that Phil Karn provides in his patch:
    (AP-485) [intel.com], (AP-909) [intel.com], a href =
    "http://www.amd.com/K6/k6docs/pdf/20734j.pdf"> AMD K6

Slashdot Top Deals

The sooner all the animals are extinct, the sooner we'll find their money. - Ed Bluestone

Close