True, but isn't this really an argument for a large-scale nuclear power plant construction program? We hear that nuclear plants take decades to build... and yet, as you say, it could be done much faster than that, if the orders for construction came from the very top.
What's more, I'd think it would be easier to use this sort of government power to build nuclear plants, because much less land would be required, there would probably be a lower environmental impact from doing it, and the power output would be greater and more reliable.
I didn't think it was necessary to mention viruses and malware because any serious replacement for system calls and the user/kernel space barrier must deal with those issues. There has to be some mechanism to stop a rogue or malicious process trashing everything. The point is that the mechanism doesn't need to be system calls and memory protection. There are other options.
The argument here is not about security, but performance. The possibility of being able to "optimise out" an entire API, even across the system call barrier, is (I think) an interesting one, and that's what I was commenting on.
The thing is that hardware security does not actually come for free - there is a time cost, and the implication of the article we're commenting on here is that the time cost is significant.
You are of course right that VMs have not always been particularly secure. But you must be aware that kernels share the same problem. Privilege escalation bugs have been plentiful, not only in Windows and Linux but also on games consoles with their relatively simple hypervisors. In all of these cases the MMU may be relatively simple, but the supporting code is not. So I'm not entirely convinced by your line of argument, which amounts to "managed code can never be secure", because it seems altogether too similar to "kernels can never be secure".
Superb idea! Why do something quickly in hardware, when you can do it slowly in software?
I don't think you understand what I am getting at. I am not saying that memory protection and privilege levels should be enforced by software - that is not what Singularity does. The whole point of managed code is that memory protection does not need to be enforced at all. The result is that you can run everything in ring 0, in the same memory space. No matter how fast your hardware already is, removing these overheads makes it faster.
It certainly wasn't intended that way and I can't imagine why you would think that.
One of the great things about the Singularity approach is that the overhead of system calls is reduced to almost nothing. I'd have thought that the benefits for high-end graphics would be obvious.
This is a very good point, the overhead of API calls can be a significant bottleneck.
I'd suggest that a good solution is to move applications to entirely managed code (e.g. C#), so that there is no need for any hardware-enforced barrier between the kernel and the applications (c.f. Singularity). In the best case, you may end up with a situation in which a JIT compiler inlines parts of the kernel's graphics driver directly into the application code, effectively run-time specialising the application for the available hardware. We already see hints of this happening, for instance the use of LLVM bit code in Apple's OpenGL stack.
It couldn't be an SMP machine though, not with so many cores.
My bet would be that each of the 120 nodes actually is a complete computer with 4 cores and its own memory - linked to the other 119 only via Ethernet. In this arrangement the 32-bit memory limit is not such a big issue. Each individual machine will not be particularly powerful anyway.
Thanks, that's very informative. I wonder what is involved in validation, and what restrictions are imposed to ensure the code is actually safe? Sounds like a tricky problem - difficult enough that it's previously only been solved by (1) restricted languages like Java and C#, or (2) in hardware, with protected memory and access to the OS only via system calls. To do it with arbitrary x86 code is certainly interesting. I wonder if this could be useful not just for browsers, but even entire OSes where memory protection is not necessary because all incoming code is fully validated.
Sounds likely, but if that's the approach, then why use native code at all? If you are going to effectively do JIT compilation on x86 code, turning it into more x86 code with extra safety checks, then why not instead do the JIT compilation on something intended to be JIT-compiled? For instance you could serve up some intermediate representation of the program, like LLVM bitcode. But that just sounds like Java or C#...
"I have the inalienable right to anything nature allows me, for as long as I don't overstep some other individual's inalienable rights."
Thing is, that's a circular definition. I might assert that I have the inalienable right to not have my software duplicated by you. So then we just end up arguing over whether that right is inalienable or not and we get nowhere. It's not like God is going to make a personal appearance and set the record straight.
This is clearly a subject you care very much about. But I think you are missing something. IP rights are actually socially useful, just like physical property rights. There are useful businesses that just could not exist without IP rights, i.e. businesses that benefit everyone. Yes, we can do without movies, games and musicians who don't tour if we have to; they may be entertaining but they're hardly essential.
But IP rights also protect things which are useful. Some software could simply never be written on the "free as in freedom" model. I'm thinking particularly about specialised tools, such as the EDA software used to design chips, or the simulation software used to model and analyse biological processes, or the CAD software used to design and manufacture physical objects.
These are a few examples of programs that take thousands of man-years to develop. They are engineering projects on a vast scale, which require huge investment but produce something useful that could not be produced any other way.
If not for IP rights, we would not be able to benefit from this sort of software, because it would be sold once and then pirated forever. Any investment would be worthless. The software would never be made, and therefore, whatever it enabled would also never be made. Technological progress would stagnate.
Thus, I think there is a pretty strong argument for governments enforcing IP rights like they enforce physical property rights. Just as physical property rights allow businesses such as shops to exist, IP rights enable the investment in highly specialised projects to be recouped. And that is valuable to everyone, not just the people making a profit from those investments. The ability to watch big-budget movies and play non-trivial games is just a nice side-effect.
No, it isn't just obfuscation. You can build a secure online update mechanism on top of a platform that is "wide open". It isn't even difficult. See Windows Update, or APT in Linux. These do not rely on obfuscation to keep the secret keys secret, because the secret keys never need to be released. Nothing prevents Sony building a similar system on top of the existing PS3 software.
Which means that any firmware update can be decrypted, unpacked, and analyzed to obtain any authentication secrets that might be hidden within the update
Naturally. But this does not help. Let me start again with my explanation. There's two separate things here.
Firstly, authentication for the back door.
Secondly, authentication for the PS3 system in general.
The second sort of authentication has to use the old key pair, because as you rightly say, that can't be changed. It's in hardware, and code won't run on the PS3 without it.
But the first sort can use any key at all. Sony can generate an entirely new key pair, then distribute the new public key in the firmware update. That way, the back door is only useful to people with the new private key. Although fake "updates" might pass the second sort of authentication, they won't get through the first.
The point I am making is that the back door is not necessarily insecure just because the root key is compromised, because it can use new, independent keys for authentication. Thus it is incorrect to say "Sony has access to this backdoor but SO DOES EVERYONE ELSE." A well-designed back door would not have this problem, because its authentication keys would not be derived from the compromised ones.
The only way to stop online cheating is if all the crucial game decisions are validated by the game server.
That's only applicable to certain sorts of game. In particular, it doesn't prevent aimbotting, or modifying the game resources so that the walls are transparent.
It's certainly true that you can write an aimbot that modifies packets enroute. But still, it is possible to do things about that. For instance, Blizzard seems to encrypt the headers of the packets used by WoW with message authentication codes (MACs), making it difficult to change the packets unless you know the current encryption key. To get the key, you'd need something running on the client PC - and that something could be detected by Warden at any time, leading to banhammer.
Yes, but how do you catch the cheaters? Answer - you use something like Warden, VAC, or Punkbuster. Then, having detected them, you ban them from online play at some future point.
My point is that Sony are not really doing anything strange or especially frightening. Rather, they are adopting a long-established approach to detect cheats on the PC, hitherto unnecessary on consoles due to the secure execution environment, but made necessary now because of the jailbreak.
The topic here is remote exploits, not local exploits performed by the PS3 owner. Quoting: "Sony has access to this backdoor but SO DOES EVERYONE ELSE." (great grandparent).
If you want to compromise other people's PS3s, the backdoor is no use to you, provided it's correctly implemented. You can potentially MITM the firmware update that installs it, perhaps by DNS or IP spoofing, but once a correct firmware update has been received by the PS3, then it can check all future downloaded updates of any sort, using public key cryptography implemented in software with new keys downloaded as part of the update. Much like Windows Update or APT - neither of which rely on keys stored in hardware, and both of which are about as secure as these things ever could be.
You should pay more attention before you wade in to tell someone else they are wrong.
That's incorrect. Nothing forces Sony to reuse the compromised system keys for their back door. They could (should) generate and use entirely new keys, which will be used to validate all downloaded code. The new private key would remain secret. And if they get the cryptography algorithms right this time, this measure shouldn't create any security risk for PS3 owners.
On the PC, where there was never any hardware security to prevent cheating, publishers have been using the same technique for many years. Consider Blizzard Warden, Punkbuster, and Valve Anti Cheat. All of these allow the publisher - or their authorised agents - to download and run code on your machine when you connect to the online service.
Now Sony's platform is thoroughly broken, Sony has to adopt Punkbuster/VAC/Warden-style technology. It's either that, or suffer a mass exodus of players to other platforms which will be free of cheats.
Sure, there is driver signing, and maybe one day the Windows kernel used on desktop machines will have a big security overhaul. But that's nothing to do with the grandparent's hypotheses, which are In 5 years the PCs from the big vendors will have locked firmware to "protect the user experience" and In 10 years the only way you'll be able to run FOSS software will be to buy an unlocked "corporate" PC for an absurd amount of money. Both of which are absurd.
They remind me a little of that old "Final Ultimate Solution to the Spam Problem" (FUSSP) response, posted on this site whenever someone suggested a way to stop spam. In general any FUSSP fails because it blocks some legitimate use of email as well, which would be intolerable. Equally any "Final Ultimate Solution for Locking Down PCs and Eliminating Free Software" fails because it blocks legitimate uses of a PC - uses which cannot be prevented without incurring a significant, intolerable cost. A manufacturer making locked down PCs is merely exposing itself to a large loss, effectively handing its business to its competitors.
But customer knowledge is not protecting your freedom anyway. It never has. You have not "lost" because I bought a Bluray player and a HDMI cable, which I bought knowing about the restrictions, and not caring.
On your PC, your freedom is protected by the economic impossibility of removing it. It's totally impractical to lock down PCs in the way you suggest, for many reasons.
For just one, consider the vast amount of software that already exists for PCs - it would all have to be re-released with the digital signatures necessary to run on the new system, because nothing else would work. How could this ever be acceptable to users and businesses? The sorts of places that still use IE6 because they need some old ActiveX control... the sorts of places that can't use Windows 7 64-bit because they still need some 16-bit Windows app from 1992.
While this code exists, and is common, your "four software freedoms" are protected. But in Stallman's world, everything is absolute: black or white, free or non-free. The idea of non-free software protecting freedom as a side effect of legacy compatibility does not compute.
Doesn't this require with a huge number of support libraries, though? I'm thinking of all those files beginning with "libk" and "libqt". When you add all of those together, the bloat is probably quite similar to acroread.
Sounds like you need a real-time JVM. These do garbage collection continuously, without creating large latency spikes. You could look at the Jamaica VM from Aicas - it has real-time garbage collection and should be a more reliable platform for your server application.
No. Capitalism requires the rule of law - i.e., a completely fair system to enforce everyone's right to their own property.
Without that, you just have gangsterism: property is (literally) theft. That's Somalia.
Libertarians who say "no government" actually mean "no government, except for law enforcement". Unfortunately libertarians often fall into the trap of believing their ideas are self-evident and obvious, which is no longer true. Consequently they don't always state exactly what they mean.
Slashdot Mirror
True, but isn't this really an argument for a large-scale nuclear power plant construction program? We hear that nuclear plants take decades to build... and yet, as you say, it could be done much faster than that, if the orders for construction came from the very top.
What's more, I'd think it would be easier to use this sort of government power to build nuclear plants, because much less land would be required, there would probably be a lower environmental impact from doing it, and the power output would be greater and more reliable.
I didn't think it was necessary to mention viruses and malware because any serious replacement for system calls and the user/kernel space barrier must deal with those issues. There has to be some mechanism to stop a rogue or malicious process trashing everything. The point is that the mechanism doesn't need to be system calls and memory protection. There are other options.
Don't remember anything like this ever being in NT. Are you sure you're not thinking of something else?
Thanks for clarifying.
The argument here is not about security, but performance. The possibility of being able to "optimise out" an entire API, even across the system call barrier, is (I think) an interesting one, and that's what I was commenting on.
The thing is that hardware security does not actually come for free - there is a time cost, and the implication of the article we're commenting on here is that the time cost is significant.
You are of course right that VMs have not always been particularly secure. But you must be aware that kernels share the same problem. Privilege escalation bugs have been plentiful, not only in Windows and Linux but also on games consoles with their relatively simple hypervisors. In all of these cases the MMU may be relatively simple, but the supporting code is not. So I'm not entirely convinced by your line of argument, which amounts to "managed code can never be secure", because it seems altogether too similar to "kernels can never be secure".
Superb idea! Why do something quickly in hardware, when you can do it slowly in software?
I don't think you understand what I am getting at. I am not saying that memory protection and privilege levels should be enforced by software - that is not what Singularity does. The whole point of managed code is that memory protection does not need to be enforced at all. The result is that you can run everything in ring 0, in the same memory space. No matter how fast your hardware already is, removing these overheads makes it faster.
It certainly wasn't intended that way and I can't imagine why you would think that.
One of the great things about the Singularity approach is that the overhead of system calls is reduced to almost nothing. I'd have thought that the benefits for high-end graphics would be obvious.
This is a very good point, the overhead of API calls can be a significant bottleneck.
I'd suggest that a good solution is to move applications to entirely managed code (e.g. C#), so that there is no need for any hardware-enforced barrier between the kernel and the applications (c.f. Singularity). In the best case, you may end up with a situation in which a JIT compiler inlines parts of the kernel's graphics driver directly into the application code, effectively run-time specialising the application for the available hardware. We already see hints of this happening, for instance the use of LLVM bit code in Apple's OpenGL stack.
It couldn't be an SMP machine though, not with so many cores.
My bet would be that each of the 120 nodes actually is a complete computer with 4 cores and its own memory - linked to the other 119 only via Ethernet. In this arrangement the 32-bit memory limit is not such a big issue. Each individual machine will not be particularly powerful anyway.
Thanks, that's very informative. I wonder what is involved in validation, and what restrictions are imposed to ensure the code is actually safe? Sounds like a tricky problem - difficult enough that it's previously only been solved by (1) restricted languages like Java and C#, or (2) in hardware, with protected memory and access to the OS only via system calls. To do it with arbitrary x86 code is certainly interesting. I wonder if this could be useful not just for browsers, but even entire OSes where memory protection is not necessary because all incoming code is fully validated.
Sounds likely, but if that's the approach, then why use native code at all? If you are going to effectively do JIT compilation on x86 code, turning it into more x86 code with extra safety checks, then why not instead do the JIT compilation on something intended to be JIT-compiled? For instance you could serve up some intermediate representation of the program, like LLVM bitcode. But that just sounds like Java or C#...
"I have the inalienable right to anything nature allows me, for as long as I don't overstep some other individual's inalienable rights."
Thing is, that's a circular definition. I might assert that I have the inalienable right to not have my software duplicated by you. So then we just end up arguing over whether that right is inalienable or not and we get nowhere. It's not like God is going to make a personal appearance and set the record straight.
This is clearly a subject you care very much about. But I think you are missing something. IP rights are actually socially useful, just like physical property rights. There are useful businesses that just could not exist without IP rights, i.e. businesses that benefit everyone. Yes, we can do without movies, games and musicians who don't tour if we have to; they may be entertaining but they're hardly essential.
But IP rights also protect things which are useful. Some software could simply never be written on the "free as in freedom" model. I'm thinking particularly about specialised tools, such as the EDA software used to design chips, or the simulation software used to model and analyse biological processes, or the CAD software used to design and manufacture physical objects.
These are a few examples of programs that take thousands of man-years to develop. They are engineering projects on a vast scale, which require huge investment but produce something useful that could not be produced any other way.
If not for IP rights, we would not be able to benefit from this sort of software, because it would be sold once and then pirated forever. Any investment would be worthless. The software would never be made, and therefore, whatever it enabled would also never be made. Technological progress would stagnate.
Thus, I think there is a pretty strong argument for governments enforcing IP rights like they enforce physical property rights. Just as physical property rights allow businesses such as shops to exist, IP rights enable the investment in highly specialised projects to be recouped. And that is valuable to everyone, not just the people making a profit from those investments. The ability to watch big-budget movies and play non-trivial games is just a nice side-effect.
No, it isn't just obfuscation. You can build a secure online update mechanism on top of a platform that is "wide open". It isn't even difficult. See Windows Update, or APT in Linux. These do not rely on obfuscation to keep the secret keys secret, because the secret keys never need to be released. Nothing prevents Sony building a similar system on top of the existing PS3 software.
Which means that any firmware update can be decrypted, unpacked, and analyzed to obtain any authentication secrets that might be hidden within the update
Naturally. But this does not help. Let me start again with my explanation. There's two separate things here.
Firstly, authentication for the back door.
Secondly, authentication for the PS3 system in general.
The second sort of authentication has to use the old key pair, because as you rightly say, that can't be changed. It's in hardware, and code won't run on the PS3 without it.
But the first sort can use any key at all. Sony can generate an entirely new key pair, then distribute the new public key in the firmware update. That way, the back door is only useful to people with the new private key. Although fake "updates" might pass the second sort of authentication, they won't get through the first.
The point I am making is that the back door is not necessarily insecure just because the root key is compromised, because it can use new, independent keys for authentication. Thus it is incorrect to say "Sony has access to this backdoor but SO DOES EVERYONE ELSE." A well-designed back door would not have this problem, because its authentication keys would not be derived from the compromised ones.
The only way to stop online cheating is if all the crucial game decisions are validated by the game server.
That's only applicable to certain sorts of game. In particular, it doesn't prevent aimbotting, or modifying the game resources so that the walls are transparent.
It's certainly true that you can write an aimbot that modifies packets enroute. But still, it is possible to do things about that. For instance, Blizzard seems to encrypt the headers of the packets used by WoW with message authentication codes (MACs), making it difficult to change the packets unless you know the current encryption key. To get the key, you'd need something running on the client PC - and that something could be detected by Warden at any time, leading to banhammer.
Yes, but how do you catch the cheaters? Answer - you use something like Warden, VAC, or Punkbuster. Then, having detected them, you ban them from online play at some future point.
My point is that Sony are not really doing anything strange or especially frightening. Rather, they are adopting a long-established approach to detect cheats on the PC, hitherto unnecessary on consoles due to the secure execution environment, but made necessary now because of the jailbreak.
Thanks for that. I am still right.
The topic here is remote exploits, not local exploits performed by the PS3 owner. Quoting: "Sony has access to this backdoor but SO DOES EVERYONE ELSE." (great grandparent).
If you want to compromise other people's PS3s, the backdoor is no use to you, provided it's correctly implemented. You can potentially MITM the firmware update that installs it, perhaps by DNS or IP spoofing, but once a correct firmware update has been received by the PS3, then it can check all future downloaded updates of any sort, using public key cryptography implemented in software with new keys downloaded as part of the update. Much like Windows Update or APT - neither of which rely on keys stored in hardware, and both of which are about as secure as these things ever could be.
You should pay more attention before you wade in to tell someone else they are wrong.
That's incorrect. Nothing forces Sony to reuse the compromised system keys for their back door. They could (should) generate and use entirely new keys, which will be used to validate all downloaded code. The new private key would remain secret. And if they get the cryptography algorithms right this time, this measure shouldn't create any security risk for PS3 owners.
In the absence of effective hardware security, this is the only way to stop people cheating in online games. This has become a big problem on the PS3 since the jailbreak enabled it.
On the PC, where there was never any hardware security to prevent cheating, publishers have been using the same technique for many years. Consider Blizzard Warden, Punkbuster, and Valve Anti Cheat. All of these allow the publisher - or their authorised agents - to download and run code on your machine when you connect to the online service.
Now Sony's platform is thoroughly broken, Sony has to adopt Punkbuster/VAC/Warden-style technology. It's either that, or suffer a mass exodus of players to other platforms which will be free of cheats.
Sure, there is driver signing, and maybe one day the Windows kernel used on desktop machines will have a big security overhaul. But that's nothing to do with the grandparent's hypotheses, which are In 5 years the PCs from the big vendors will have locked firmware to "protect the user experience" and In 10 years the only way you'll be able to run FOSS software will be to buy an unlocked "corporate" PC for an absurd amount of money. Both of which are absurd.
They remind me a little of that old "Final Ultimate Solution to the Spam Problem" (FUSSP) response, posted on this site whenever someone suggested a way to stop spam. In general any FUSSP fails because it blocks some legitimate use of email as well, which would be intolerable. Equally any "Final Ultimate Solution for Locking Down PCs and Eliminating Free Software" fails because it blocks legitimate uses of a PC - uses which cannot be prevented without incurring a significant, intolerable cost. A manufacturer making locked down PCs is merely exposing itself to a large loss, effectively handing its business to its competitors.
But customer knowledge is not protecting your freedom anyway. It never has. You have not "lost" because I bought a Bluray player and a HDMI cable, which I bought knowing about the restrictions, and not caring. On your PC, your freedom is protected by the economic impossibility of removing it. It's totally impractical to lock down PCs in the way you suggest, for many reasons. For just one, consider the vast amount of software that already exists for PCs - it would all have to be re-released with the digital signatures necessary to run on the new system, because nothing else would work. How could this ever be acceptable to users and businesses? The sorts of places that still use IE6 because they need some old ActiveX control... the sorts of places that can't use Windows 7 64-bit because they still need some 16-bit Windows app from 1992. While this code exists, and is common, your "four software freedoms" are protected. But in Stallman's world, everything is absolute: black or white, free or non-free. The idea of non-free software protecting freedom as a side effect of legacy compatibility does not compute.
Doesn't this require with a huge number of support libraries, though? I'm thinking of all those files beginning with "libk" and "libqt". When you add all of those together, the bloat is probably quite similar to acroread.
Right. I'd say real-time GC would be essential for any Java application on a mobile device.
Sounds like you need a real-time JVM. These do garbage collection continuously, without creating large latency spikes. You could look at the Jamaica VM from Aicas - it has real-time garbage collection and should be a more reliable platform for your server application.
No. Capitalism requires the rule of law - i.e., a completely fair system to enforce everyone's right to their own property.
Without that, you just have gangsterism: property is (literally) theft. That's Somalia.
Libertarians who say "no government" actually mean "no government, except for law enforcement". Unfortunately libertarians often fall into the trap of believing their ideas are self-evident and obvious, which is no longer true. Consequently they don't always state exactly what they mean.
Internet Watch Foundation?