For password hashing, that is correct. However, cryptographic hash functions are not designed for such use (and yes, all the websites and services out there using plain hashes for passwords are Doing It Wrong, even if they are using a salt). You can build a good password hashing scheme out of a cryptographic hash function (for example, PBKDF2), but plain hash functions are not suitable (precisely because they are too fast).
Fast cryptographically secure hash functions are a Good Thing, so you can hash a given block of data (and thus compute its digest and e.g. verify its digital signature) as fast as possible. This speeds up things like GPG, SSL, Git*, good old sha1sum checksums, etc. If you then want to use such a hash function as the core of a password hashing scheme, you can compensate for the extra speed by simply increasing the number of iterations. Making a hash function slower is always easy.
*Git is pretty much stuck with SHA-1 for now, but future incompatible versions of the repo format could conceivably switch to a faster hash function if it made sense.
Wrong. You shouldn't be using port 25 to submit mail to the SMTP server of your e-mail provider these days. You should be using port 587 (mail submission). Works just fine with smtp.gmail.com.
Which means the Optimus solution isn't actually all that bad. I have the opposite viewpoint: I bought an Optimus laptop assuming the nvidia wouldn't work, simply for the other specs and the Intel video. When it turned out that bumblebee worked fairly painlessly and I was able to use the nvidia to accelerate 3D while the Intel drove my displays, I was pleasantly surprised. The solution is a bit of a hack, but honestly, I don't really have anything bad to say about it. It's the best of both worlds: open Intel drivers which are stable and support modern interfaces like XRandR 1.3 and KMS driving the displays, and the clunky proprietary but fast nvidia driver sandboxed in its own backgrond X server doing 3D acceleration only.
It is true that the law grants the copyright owner the right to restrict the creation of copies, but It can be reasonably argued that by posting the code on GitHub you've implicitly given consent to the mere creation of a copy (as would automatically happen if you view the code or download it). For most practical purposes, the limitation on distribution is what matters.
You can take any code which you find and put it into your project, or even combine bits of code with incompatible licenses. What you can't do is distribute the result. Distribution is where copyright law kicks in.
How did you measure the power usage? If you used a cheap power meter that does not have accurate power factor measurement, then your measurements are completely useless. Idle switching power supplies have very low power usage, but a very low power factor, because they act as capacitive loads. This means that a naive current meter will measure all of that out-of-phase current and you'll end up with a grossly inflated power figure. A proper power meter measures both instantaneous voltage and current many times during each AC power cycle, and can therefore report both real power and apparent power. If you measure an idle switching wall wart with such a meter, you will see a low W (real power) figure and a high VA (apparent power) figure. Residential customers are usually charged for real power only.
That isn't caused by overcharging, it's caused by the battery simply being at 100% charge. Li-ion batteries like to be stored at 40% charge, and degrade much faster at 100%.
The technical solution to this problem is a trivial firmware change to the charging controller to only charge the battery to 40%. However, I suspect nobody has done it because nobody has figured out how to get the users to switch to "40% maintenance charge mode" when always plugged in, without pissing them off when they run off and discover that their device is only 40% charged. The fundamental problem is being able to predict when the user will need to actually use the battery, and only fully charge it immediately prior.
It's successful itself, but not that successful for its users, though. One of the chronic problems of Arduino is that many people become mentally attached to it and exhibit extreme reluctance to ever move beyond it, learn how it really works, or (gasp) build a project that isn't an Arduino shield. When they find a problem that the Arduino isn't great at, they go to great lengths to solve it while keeping the Arduino (using e.g. more external logic, more than one Arduino, or, in extreme cases, throwing an FPGA on top of the Arduino - and implementing a coprocessor on it that is more powerful than the Arduino itself).
Very often, these problems can be solved much more efficiently by building your own hardware from a bare microcontroller, which is actually a very easy task - the Arduino is little more than a breakout board. Alas, while some Arduino users do realize this (and use bare AVRs, both the ones on Arduinos and other models, or even other brands, to great effect), most do not. Now that Arduino is moving to ARM, this will get marginally worse - if people aren't taking the plunge and figuring out how to use a bare AVR (which is completely trivial to bring up on a breadboard), moving to a surface-mount part that has slightly more complex requirements is not going to make things better.
The same thing happens, to a different extent, on the software side. I've seen many projects that are coded as a humongous unreadable Arduino sketch, when by that point the authors really ought to have learned how to modularize their code (and format it properly, too). It doesn't help that the Arduino IDE isn't a particularly great text editor.
The Arduino is a great learning platform, but it does the "make it easy" experience so well that people are very afraid of moving beyond it, and this ends up creating an artificial learning curve further down the line that is hard to get past. If you're forced to experience bring-up of a micro on a breadboard from the first day, you quickly figure it out (it's really easy), but if you've been comfy in Arduino land for months/years, it feels a lot scarier than it really is. (What do you mean I have to provide my own regulated power supply? And the pins, they don't have labels! Where is the USB connector?). I don't even blame the authors of Arduino; for example, they do include code that can program a bare AVR using an Arduino as a programmer (with visual wiring diagrams even, IIRC), which is exactly the kind of thing that you want to help people bootstrap themselves, but people still just aren't doing it.
This. I came here to say the same thing, but you already had. Every single modern graphics card is very efficient at scaling textures, and in fact, LCD scaling these days most often ends up happening on the GPU anyway. Don't touch my screen resolution. Ever. If the goal is to get better performance by rendering at a lower resolution, then render at a lower-resolution offscreen buffer and scale that up to the screen resolution.
I wish Wine had a mode that did this for Windows games that expect to change the screen resolution and don't play well with Xinerama. These days I end up using the "virtual desktop" wine mode with per-game settings and KDE's window override support to put it on the right display head and remove the borders, but it's a suboptimal manual solution. The Linux game situation is slightly better (they tend to be configurable to respect the current resolution and usually get the display head right), but still don't have scaling support.
Need inspiration? Do what video players (particularly mplayer) do. That is how fullscreen games should work.
I've checked the code, and this is in fact the case. All it does is marshal the function arguments into a buffer and send them off into the GPU core, for every OpenGL function.
For the people who want open drivers because of e.g. linking problems, the ability to rebuild them, ABI issues, etc, this is good. For the people who want open drivers to improve them, fix bugs, see how they work, add new APIs, etc., this is useless. It certainly isn't an "open source driver"; it's just "open source ARM libraries". Broadcom is just as closed as always, they're just getting better at making that closedness play nicer with open source folks.
Personally, I would be happier with a platform that implements graphics like this than with a platform where the userspace blob is where the fun is and will never get open sourced (like most other embedded Linux platforms), but I still won't be buying a Pi. There's something about booting via the GPU blob that still disgusts me - I shouldn't have to use their proprietary firmware to just boot Linux. If only they hadn't made the boneheaded decision to design an SoC that boots from the GPU core, and instead booted using the ARM CPU like everyone else, then we could just throw their GPU "firmware" in/lib/firmware like everything other device driver does and I'd be perfectly happy.
Nevermind, I just checked. They are indeed the bootldr keys (I was able to decrypt an lv0 with them). Consider this confirmation that the story is not fake.
Oh, one more thing. I'm assuming that these keys actually should be called the bootldr keys (as in the keys that bootldr uses to verify lv0), and that the name "lv0" is just a misnomer (because lv0 is, itself, signed using these keys).
If this keyset is just what Sony introduced in lv0 after the original hack, and they are used to sign everything *under* lv0 and that is loaded *by* lv0, then this whole thing is not newsworthy and none of what I said applies. It just means that all firmwares *to date* can be decrypted. Sony will replace this keyset and update lv0 and everything will be back at step 1 again. lv0 is updatable, unlike bootldr, and is most definitely not a fixed root of trust (unlike metldr, which was, until the architecture hack/change wrapped everything in lv0). If this is the case, color me unimpressed.
The name is presumably wrong - they would be the bootldr keys, as the keyset is considered to "belong" to the entity that uses those keys to check and decrypt the next thing down the chain - just like the metldr keys are the keys metldr uses to decrypt and verify other *ldrs, the bootldr keys are the keys bootldr uses to decrypt and verify lv0.
Anyway, you're confusing secrecy with trust. These keys let you decrypt any future firmware; as you say, if they were to "fix" that, that would mean new updates would not work on older machines. However, decrypting firmware doesn't imply that you can run homebrew or anything else. It just means you can see the firmware, not actually exploit it if you're running it.
The only trust that is broken by this keyset (assuming they are the bootldr keys) is the trust in lv0, the first upgradable component in the boot process (and both it and bootldr are definitely software, not hardware, but bootldr is not upgradable/replaceable so this cannot be fixed). This means that you can use them to sign lv0. Period. Nothing more, nothing less. The only things that these keys let you modify is lv0. In order to modify anything else, you have to modify everything between it and lv0 first. This means that these keys are only useful if you have write access to lv0, which means a hardware flasher, or an already exploited console, or a system exploit that lets you do so.
No. The keys are used for two purposes: chain of trust and chain of secrecy. The compromise of the keys fully compromises the secrecy of the PS3 platform permanently, as you can just follow the links down the chain (off-line, on a PC) and decrypt any past, current, or future firmware version. Current consoles must be able to use any future firmware update, and we now have access to 100% of the common key material of current PS3s, so it follows that any future firmware decryptable by current PS3s is also decryptable by anyone on a PC.
However, the chain of trust can be re-established at any point along the line that can be updated. The chain of trust is safely rooted in hardware that is near impossible to modify (i.e. the CPU's ROM and eFuse key). The next link down the chain has been compromised (bootldr), and this link cannot be updated as it is specific to each console, so the chain of trust now has a permanent weak second link. However, the third link, lv0, can be updated as it is located in flash memory and signed using public key crypto. This allows Sony to secure the entire chain from there onwards. Unless you find a vulnerability in these updated links, you will not be able to attack them directly (applications, e.g. homebrew software, are verified much further down the chain). The only guaranteed way to break the chain is to attack the weak link directly, which means using a flash writer to overwrite lv0. Once you do so, the entire chain collapses (well, you still need to do some work to modify every subsequent link to turn off security, but that is easy). If you have old firmware, you have at least some other weak links that, when compromised, allow you direct access to break the bootldr link (replacing lv0), but if you run up to date firmware you're out of luck unless you can find a weakness or you use hardware.
Old PS3s are now in the same boat as an old Wii, and in fact we can draw a direct comparison of the boot process. On an old Wii, boot0 (the on-die ROM) securely loads boot1 from flash, which is securely checked against an eFuse hash, and boot1 loads boot2 but insecurely checks its signature. On an old PS3, the Cell boot ROM securely loads bootldr from flash, which is securely decrypted and checked using an eFuse key, and then bootldr loads lv0 but checks its signature against a hardcoded public key whose private counterpart is now known. In both cases, the system can be persistently compromised if you can write to flash, or if you already have code execution in system context (which lets you write to flash). However, in both cases, you need to use some kind of high-level exploit to break into the firmware initially, particularly if you have up-to-date firmware. It just happens that this is trivial on the Wii because there is no game patch system and Nintendo seems to have stopped caring, while this is significantly harder on the PS3 because the system software has more security layers and there is a game patch system.
The first-stage bootloader is in ROM and has a per-console key which is effectively in tamper-resistant silicon. The second-stage bootloader (bootldr) is encrypted with the per-console key, but is not upgradable and is the same for all consoles (other than the encryption wrapper around it). This second-stage bootloader verifies lv0. Sony signed lv0 using the same broken process that they used for everything else, which leaks their private key. This means that the lv0 private key was doomed from the start, ever since we demonstrated the screwup at the Chaos Communication Congress two years ago.
However, because lv0 is also encrypted, including its signature block, we need that decryption key (which is part of bootldr) before we can decrypt the signature and apply the algorithm to derive the private key. We did this for several later-stage loaders by using an exploit to dump them, and Geohot did it for metldr (the "second root" in the PS3's bizarre boot process) using a different exploit (we replicated this, although our exploit might be different). At the time, this was enough to break the security of all released firmware to date, since everything that mattered was rooted in metldr (which is bootldr's brother and is also decrypted by the per-console key). However, Sony took a last ditch effort after that hack and wrapped everything after metldr into lv0, effectively using the only security they had left (bootldr and lv0) to attempt to re-secure their platform.
Bootldr suffers from the same exploit as metldr, so it was also doomed. However, because bootldr is designed to run from a cold boot, it cannot be loaded into a "sandboxed" SPU like metldr can from the comfort of OS-mode code execution (which we had via the USB lv2 exploit), so the exploit is harder to pull off because you don't have control over the rest of the software. For the exploit that we knew about, it would've required hardware assistance to repeatedly reboot the PS3 and some kind of flash emulator to set up the exploit with varying parameters each boot, and it probably would've taken several hours or days of automated attempts to hit the right combination (basically the exploit would work by executing random garbage as code, and hoping that it jumps to somewhere within a segment that we control - the probabilities are high enough that it would work out within a reasonable timeframe). We never bothered to do this after the whole lawsuit episode.
Presumably, 18 months later, some other group has finally figured this out and either used our exploit and the hardware assistance, or some other equivalent trick/exploit, to dump bootldr. Once the lv0 decryption key is known, the signing private key can be computed (thanks to Sony's epic failure).
The effect of this is essentially the same that the metldr key release had: all existing and future firmwares can be decrypted, except Sony no longer has the lv0 trick up their sleeve. What this means is that there is no way for Sony to wrap future firmware to hide it from anyone, because old PS3s must be able to use all future firmware (assuming Sony doesn't just decide to brick them all...), and those old PS3s now have no remaining seeds of security that aren't known. This means that all future firmwares and all future games are decryptable, and this time around they really can't do anything about it. By extension, this means that given the usual cat-and-mouse game of analyzing and patching firmware, every current user of vulnerable or hacked firmware should be able to maintain that state through all future updates, as all future firmwares can be decrypted and patched and resigned for old PS3s. From the homebrew side, it means that it should be possible to have hombrew/linux and current games at the same time. From the piracy side, it means that all future games can be pirated. Note that this doesn't mean that these things will be easy (Sony can obfuscate things to annoy people as much as their want), but from the fundamental security standpoint, Sony doesn't have any security leg to stand on
What you're missing is that chip layout is NP-complete. For anything beyond very trivial chips, no computer algorithm can yield the optimal solution in a reasonable time.
As I understand it, automated layout algorithms are still, when you get down to it, largely quite dumb. I'm sure this is oversimplifying and someone who writes place-and-route software will probably want to kill me, but the algorithm is closer to "throw stuff together, measure performance, tweak things randomly, measure performance, keep the change if it got better" than to anything likely to yield an optimal solution. Eventually, you'll converge on a decent layout, sure, but not an optimal one.
It's pretty much guaranteed that this chip wasn't completely hand-crafted (modern chips are much too complicated to do that). Instead, most likely, engineers guided the placement of major blocks and data paths, and let the automated place-and-route software choose the rest. By constraining the design based on intelligent decisions, you can guide the automated process to converge on a better solution.
What would replace the helium atoms? If the case is rigid, and the pressure inside is equal to atmospheric pressure, and air can't diffuse back in since O2 and N2 molecules are larger, I expect that pressure alone will heep the helium from leaking significantly.
White LEDs are blue LEDs with a phosphor that converts part of the blue light to yellow light. There's still a large portion of the output that is unconverted blue. Therefore, all you need to do is have a blue filter in front of your receiver, since that portion of the output spectrum will not be bandwidth-constrained by the phosphor.
More realistically, 4096 * 3072 * 60 Hz * 20 bits (That's 10-bit 4:2:2 YCbCr, like HD-SDI today) = 14 Gbit/s. You could push 6 of those streams over 100GbE.
Slashdot Mirror
For password hashing, that is correct. However, cryptographic hash functions are not designed for such use (and yes, all the websites and services out there using plain hashes for passwords are Doing It Wrong, even if they are using a salt). You can build a good password hashing scheme out of a cryptographic hash function (for example, PBKDF2), but plain hash functions are not suitable (precisely because they are too fast).
Fast cryptographically secure hash functions are a Good Thing, so you can hash a given block of data (and thus compute its digest and e.g. verify its digital signature) as fast as possible. This speeds up things like GPG, SSL, Git*, good old sha1sum checksums, etc. If you then want to use such a hash function as the core of a password hashing scheme, you can compensate for the extra speed by simply increasing the number of iterations. Making a hash function slower is always easy.
*Git is pretty much stuck with SHA-1 for now, but future incompatible versions of the repo format could conceivably switch to a faster hash function if it made sense.
Wrong. You shouldn't be using port 25 to submit mail to the SMTP server of your e-mail provider these days. You should be using port 587 (mail submission). Works just fine with smtp.gmail.com.
Which means the Optimus solution isn't actually all that bad. I have the opposite viewpoint: I bought an Optimus laptop assuming the nvidia wouldn't work, simply for the other specs and the Intel video. When it turned out that bumblebee worked fairly painlessly and I was able to use the nvidia to accelerate 3D while the Intel drove my displays, I was pleasantly surprised. The solution is a bit of a hack, but honestly, I don't really have anything bad to say about it. It's the best of both worlds: open Intel drivers which are stable and support modern interfaces like XRandR 1.3 and KMS driving the displays, and the clunky proprietary but fast nvidia driver sandboxed in its own backgrond X server doing 3D acceleration only.
It is true that the law grants the copyright owner the right to restrict the creation of copies, but It can be reasonably argued that by posting the code on GitHub you've implicitly given consent to the mere creation of a copy (as would automatically happen if you view the code or download it). For most practical purposes, the limitation on distribution is what matters.
You can take any code which you find and put it into your project, or even combine bits of code with incompatible licenses. What you can't do is distribute the result. Distribution is where copyright law kicks in.
Ah, one of those stupid Windows-only features. Sigh.
There seems to be a reverse-engineered driver for Linux but support is sketchy for the X220. I guess I'll try it and see.
How did you measure the power usage? If you used a cheap power meter that does not have accurate power factor measurement, then your measurements are completely useless. Idle switching power supplies have very low power usage, but a very low power factor, because they act as capacitive loads. This means that a naive current meter will measure all of that out-of-phase current and you'll end up with a grossly inflated power figure. A proper power meter measures both instantaneous voltage and current many times during each AC power cycle, and can therefore report both real power and apparent power. If you measure an idle switching wall wart with such a meter, you will see a low W (real power) figure and a high VA (apparent power) figure. Residential customers are usually charged for real power only.
Now you've left me wondering. Where is this setting? I certainly can't find it on the BIOS setup menu (ThinkPad X220).
That isn't caused by overcharging, it's caused by the battery simply being at 100% charge. Li-ion batteries like to be stored at 40% charge, and degrade much faster at 100%.
The technical solution to this problem is a trivial firmware change to the charging controller to only charge the battery to 40%. However, I suspect nobody has done it because nobody has figured out how to get the users to switch to "40% maintenance charge mode" when always plugged in, without pissing them off when they run off and discover that their device is only 40% charged. The fundamental problem is being able to predict when the user will need to actually use the battery, and only fully charge it immediately prior.
It's successful itself, but not that successful for its users, though. One of the chronic problems of Arduino is that many people become mentally attached to it and exhibit extreme reluctance to ever move beyond it, learn how it really works, or (gasp) build a project that isn't an Arduino shield. When they find a problem that the Arduino isn't great at, they go to great lengths to solve it while keeping the Arduino (using e.g. more external logic, more than one Arduino, or, in extreme cases, throwing an FPGA on top of the Arduino - and implementing a coprocessor on it that is more powerful than the Arduino itself).
Very often, these problems can be solved much more efficiently by building your own hardware from a bare microcontroller, which is actually a very easy task - the Arduino is little more than a breakout board. Alas, while some Arduino users do realize this (and use bare AVRs, both the ones on Arduinos and other models, or even other brands, to great effect), most do not. Now that Arduino is moving to ARM, this will get marginally worse - if people aren't taking the plunge and figuring out how to use a bare AVR (which is completely trivial to bring up on a breadboard), moving to a surface-mount part that has slightly more complex requirements is not going to make things better.
The same thing happens, to a different extent, on the software side. I've seen many projects that are coded as a humongous unreadable Arduino sketch, when by that point the authors really ought to have learned how to modularize their code (and format it properly, too). It doesn't help that the Arduino IDE isn't a particularly great text editor.
The Arduino is a great learning platform, but it does the "make it easy" experience so well that people are very afraid of moving beyond it, and this ends up creating an artificial learning curve further down the line that is hard to get past. If you're forced to experience bring-up of a micro on a breadboard from the first day, you quickly figure it out (it's really easy), but if you've been comfy in Arduino land for months/years, it feels a lot scarier than it really is. (What do you mean I have to provide my own regulated power supply? And the pins, they don't have labels! Where is the USB connector?). I don't even blame the authors of Arduino; for example, they do include code that can program a bare AVR using an Arduino as a programmer (with visual wiring diagrams even, IIRC), which is exactly the kind of thing that you want to help people bootstrap themselves, but people still just aren't doing it.
This. I came here to say the same thing, but you already had. Every single modern graphics card is very efficient at scaling textures, and in fact, LCD scaling these days most often ends up happening on the GPU anyway. Don't touch my screen resolution. Ever. If the goal is to get better performance by rendering at a lower resolution, then render at a lower-resolution offscreen buffer and scale that up to the screen resolution.
I wish Wine had a mode that did this for Windows games that expect to change the screen resolution and don't play well with Xinerama. These days I end up using the "virtual desktop" wine mode with per-game settings and KDE's window override support to put it on the right display head and remove the borders, but it's a suboptimal manual solution. The Linux game situation is slightly better (they tend to be configurable to respect the current resolution and usually get the display head right), but still don't have scaling support.
Need inspiration? Do what video players (particularly mplayer) do. That is how fullscreen games should work.
I've checked the code, and this is in fact the case. All it does is marshal the function arguments into a buffer and send them off into the GPU core, for every OpenGL function.
For the people who want open drivers because of e.g. linking problems, the ability to rebuild them, ABI issues, etc, this is good. For the people who want open drivers to improve them, fix bugs, see how they work, add new APIs, etc., this is useless. It certainly isn't an "open source driver"; it's just "open source ARM libraries". Broadcom is just as closed as always, they're just getting better at making that closedness play nicer with open source folks.
Personally, I would be happier with a platform that implements graphics like this than with a platform where the userspace blob is where the fun is and will never get open sourced (like most other embedded Linux platforms), but I still won't be buying a Pi. There's something about booting via the GPU blob that still disgusts me - I shouldn't have to use their proprietary firmware to just boot Linux. If only they hadn't made the boneheaded decision to design an SoC that boots from the GPU core, and instead booted using the ARM CPU like everyone else, then we could just throw their GPU "firmware" in /lib/firmware like everything other device driver does and I'd be perfectly happy.
I'm afraid you've got the wrong endianness. Next time try programming for the 6800 instead ;)
Nevermind, I just checked. They are indeed the bootldr keys (I was able to decrypt an lv0 with them). Consider this confirmation that the story is not fake.
Oh, one more thing. I'm assuming that these keys actually should be called the bootldr keys (as in the keys that bootldr uses to verify lv0), and that the name "lv0" is just a misnomer (because lv0 is, itself, signed using these keys).
If this keyset is just what Sony introduced in lv0 after the original hack, and they are used to sign everything *under* lv0 and that is loaded *by* lv0, then this whole thing is not newsworthy and none of what I said applies. It just means that all firmwares *to date* can be decrypted. Sony will replace this keyset and update lv0 and everything will be back at step 1 again. lv0 is updatable, unlike bootldr, and is most definitely not a fixed root of trust (unlike metldr, which was, until the architecture hack/change wrapped everything in lv0). If this is the case, color me unimpressed.
The name is presumably wrong - they would be the bootldr keys, as the keyset is considered to "belong" to the entity that uses those keys to check and decrypt the next thing down the chain - just like the metldr keys are the keys metldr uses to decrypt and verify other *ldrs, the bootldr keys are the keys bootldr uses to decrypt and verify lv0.
Anyway, you're confusing secrecy with trust. These keys let you decrypt any future firmware; as you say, if they were to "fix" that, that would mean new updates would not work on older machines. However, decrypting firmware doesn't imply that you can run homebrew or anything else. It just means you can see the firmware, not actually exploit it if you're running it.
The only trust that is broken by this keyset (assuming they are the bootldr keys) is the trust in lv0, the first upgradable component in the boot process (and both it and bootldr are definitely software, not hardware, but bootldr is not upgradable/replaceable so this cannot be fixed). This means that you can use them to sign lv0. Period. Nothing more, nothing less. The only things that these keys let you modify is lv0. In order to modify anything else, you have to modify everything between it and lv0 first. This means that these keys are only useful if you have write access to lv0, which means a hardware flasher, or an already exploited console, or a system exploit that lets you do so.
No. The keys are used for two purposes: chain of trust and chain of secrecy. The compromise of the keys fully compromises the secrecy of the PS3 platform permanently, as you can just follow the links down the chain (off-line, on a PC) and decrypt any past, current, or future firmware version. Current consoles must be able to use any future firmware update, and we now have access to 100% of the common key material of current PS3s, so it follows that any future firmware decryptable by current PS3s is also decryptable by anyone on a PC.
However, the chain of trust can be re-established at any point along the line that can be updated. The chain of trust is safely rooted in hardware that is near impossible to modify (i.e. the CPU's ROM and eFuse key). The next link down the chain has been compromised (bootldr), and this link cannot be updated as it is specific to each console, so the chain of trust now has a permanent weak second link. However, the third link, lv0, can be updated as it is located in flash memory and signed using public key crypto. This allows Sony to secure the entire chain from there onwards. Unless you find a vulnerability in these updated links, you will not be able to attack them directly (applications, e.g. homebrew software, are verified much further down the chain). The only guaranteed way to break the chain is to attack the weak link directly, which means using a flash writer to overwrite lv0. Once you do so, the entire chain collapses (well, you still need to do some work to modify every subsequent link to turn off security, but that is easy). If you have old firmware, you have at least some other weak links that, when compromised, allow you direct access to break the bootldr link (replacing lv0), but if you run up to date firmware you're out of luck unless you can find a weakness or you use hardware.
Old PS3s are now in the same boat as an old Wii, and in fact we can draw a direct comparison of the boot process. On an old Wii, boot0 (the on-die ROM) securely loads boot1 from flash, which is securely checked against an eFuse hash, and boot1 loads boot2 but insecurely checks its signature. On an old PS3, the Cell boot ROM securely loads bootldr from flash, which is securely decrypted and checked using an eFuse key, and then bootldr loads lv0 but checks its signature against a hardcoded public key whose private counterpart is now known. In both cases, the system can be persistently compromised if you can write to flash, or if you already have code execution in system context (which lets you write to flash). However, in both cases, you need to use some kind of high-level exploit to break into the firmware initially, particularly if you have up-to-date firmware. It just happens that this is trivial on the Wii because there is no game patch system and Nintendo seems to have stopped caring, while this is significantly harder on the PS3 because the system software has more security layers and there is a game patch system.
The first-stage bootloader is in ROM and has a per-console key which is effectively in tamper-resistant silicon. The second-stage bootloader (bootldr) is encrypted with the per-console key, but is not upgradable and is the same for all consoles (other than the encryption wrapper around it). This second-stage bootloader verifies lv0. Sony signed lv0 using the same broken process that they used for everything else, which leaks their private key. This means that the lv0 private key was doomed from the start, ever since we demonstrated the screwup at the Chaos Communication Congress two years ago.
However, because lv0 is also encrypted, including its signature block, we need that decryption key (which is part of bootldr) before we can decrypt the signature and apply the algorithm to derive the private key. We did this for several later-stage loaders by using an exploit to dump them, and Geohot did it for metldr (the "second root" in the PS3's bizarre boot process) using a different exploit (we replicated this, although our exploit might be different). At the time, this was enough to break the security of all released firmware to date, since everything that mattered was rooted in metldr (which is bootldr's brother and is also decrypted by the per-console key). However, Sony took a last ditch effort after that hack and wrapped everything after metldr into lv0, effectively using the only security they had left (bootldr and lv0) to attempt to re-secure their platform.
Bootldr suffers from the same exploit as metldr, so it was also doomed. However, because bootldr is designed to run from a cold boot, it cannot be loaded into a "sandboxed" SPU like metldr can from the comfort of OS-mode code execution (which we had via the USB lv2 exploit), so the exploit is harder to pull off because you don't have control over the rest of the software. For the exploit that we knew about, it would've required hardware assistance to repeatedly reboot the PS3 and some kind of flash emulator to set up the exploit with varying parameters each boot, and it probably would've taken several hours or days of automated attempts to hit the right combination (basically the exploit would work by executing random garbage as code, and hoping that it jumps to somewhere within a segment that we control - the probabilities are high enough that it would work out within a reasonable timeframe). We never bothered to do this after the whole lawsuit episode.
Presumably, 18 months later, some other group has finally figured this out and either used our exploit and the hardware assistance, or some other equivalent trick/exploit, to dump bootldr. Once the lv0 decryption key is known, the signing private key can be computed (thanks to Sony's epic failure).
The effect of this is essentially the same that the metldr key release had: all existing and future firmwares can be decrypted, except Sony no longer has the lv0 trick up their sleeve. What this means is that there is no way for Sony to wrap future firmware to hide it from anyone, because old PS3s must be able to use all future firmware (assuming Sony doesn't just decide to brick them all...), and those old PS3s now have no remaining seeds of security that aren't known. This means that all future firmwares and all future games are decryptable, and this time around they really can't do anything about it. By extension, this means that given the usual cat-and-mouse game of analyzing and patching firmware, every current user of vulnerable or hacked firmware should be able to maintain that state through all future updates, as all future firmwares can be decrypted and patched and resigned for old PS3s. From the homebrew side, it means that it should be possible to have hombrew/linux and current games at the same time. From the piracy side, it means that all future games can be pirated. Note that this doesn't mean that these things will be easy (Sony can obfuscate things to annoy people as much as their want), but from the fundamental security standpoint, Sony doesn't have any security leg to stand on
Linux software RAID doesn't do it by default, but you can sure tell it to: /sys/block/md1/md/sync_action
15 8 * * 4 root echo check >>
You try running Amarok 1.4 on a modern Linux distro.
As much as it saddens me, yes, sometimes you do lose features with open source software.
What you're missing is that chip layout is NP-complete. For anything beyond very trivial chips, no computer algorithm can yield the optimal solution in a reasonable time.
As I understand it, automated layout algorithms are still, when you get down to it, largely quite dumb. I'm sure this is oversimplifying and someone who writes place-and-route software will probably want to kill me, but the algorithm is closer to "throw stuff together, measure performance, tweak things randomly, measure performance, keep the change if it got better" than to anything likely to yield an optimal solution. Eventually, you'll converge on a decent layout, sure, but not an optimal one.
It's pretty much guaranteed that this chip wasn't completely hand-crafted (modern chips are much too complicated to do that). Instead, most likely, engineers guided the placement of major blocks and data paths, and let the automated place-and-route software choose the rest. By constraining the design based on intelligent decisions, you can guide the automated process to converge on a better solution.
What would replace the helium atoms? If the case is rigid, and the pressure inside is equal to atmospheric pressure, and air can't diffuse back in since O2 and N2 molecules are larger, I expect that pressure alone will heep the helium from leaking significantly.
Spore did it with alpha channel steganography (alternating between 0xFF and 0xFE alpha).
White LEDs are blue LEDs with a phosphor that converts part of the blue light to yellow light. There's still a large portion of the output that is unconverted blue. Therefore, all you need to do is have a blue filter in front of your receiver, since that portion of the output spectrum will not be bandwidth-constrained by the phosphor.
More realistically, 4096 * 3072 * 60 Hz * 20 bits (That's 10-bit 4:2:2 YCbCr, like HD-SDI today) = 14 Gbit/s. You could push 6 of those streams over 100GbE.