Slashdot Mirror
Patch for Linux 2.2.2 to Disable PIII PSN
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."
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.
-- Erich
Slashdot reader since 1997
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.
-- Erich
Slashdot reader since 1997
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.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
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?
Ooh, a sarcasm detector. Oh, that's a real useful invention.
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?
Ooh, a sarcasm detector. Oh, that's a real useful invention.
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.)
355/113 -- Not the famous irrational number PI, but an incredible simulation!
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?
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.
--
Matt. Want XML + Apache + Stylesheets? Get AxKit.
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!"
Shawn Asmussen
Considering Linus works for Transmeta, presumably an Intel competitor, I think your logic is faulty.
--
Aaron Gaudio
"The fool finds ignorance all around him.
"Every man is a mob, a chain gang of idiots." - Jonathan Nolan, Memento Mori
Just kidding... :-)
-------
Warning: Slashdot may contain traces of nuts.
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.
Nothing worth doing is worth doing today.
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.
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.
Planetes
"One World, One Web, One Program" - Microsoft Promo Ad
"Ein Volk, Ein Reich, Ein Fuhrer" - Adolf Hitl
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!
--
"You never know when some crazed rodent with cold feet might be running loose in your pants."
-Calvin
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?
/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...
Anyhow, if you install to a root like
Installing software in superuser-owned places is a superuser thing, that's just all there is to it.
I've finally had it: until slashdot gets article moderation, I am not coming back.
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.
0 1 - just my two bits
go read http://www.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
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
read Subj:
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
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)
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?
Weblogging Considered Harmful:
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) , (AP-909), a href =
"http://www.amd.com/K6/k6docs/pdf/20734j.pdf"> AMD K6