You can make a VM look a lot like the host. I don't know if the license allows you to run Windows inside a VM on top of another instance of Windows with one license, but what I actually do is run the natively-installed Windows inside a VM running on my also-natively-installed Linux (so I can boot Windows natively, or boot it inside a VM on Linux) - a single instance of Windows 10, just with or without a hypervisor under it (this should be perfectly legal; I recall actually reading through the EULA and it being ambiguous about this usage). I made sure the VM had the same CPU settings, the same GUID, the same hard disk serial number, and a few other identifiers. Windows isn't complaining and claims it's correctly activated, regardless of whether I boot it on bare metal or on the VM.
This used to be sometimes problematic when I had Windows 7, but Windows 10 hasn't given me any trouble. Perhaps they loosened up the hardware checks.
... which Python only uses for auxiliary purposes. Just call gc.disable(). Poof, no garbage collection. No memory leaks as long as you do not use data structures with reference cycles, either.
Let's assume you're talking about CPython, because Python is a language, not an implementation.
Python explicitly runs as a single thread
No it doesn't. CPython supports threading.
and uses time slicing to simulate multi threading.
No it doesn't. CPython uses OS threads, it does not do its own time slicing.
What you're thinking about is the GIL, which ensures that only one (real) thread is running *inside the interpreter* at any one point. You can spawn multiple CPython threads and they will be *real* threads scheduled by the OS. However, they will mutex each other out of running the interpreter at once in multiple threads. You can make blocking OS calls, or calls out to C code that is thread-safe, and they will run concurrently on multiple cores. No time-slicing.
CPython has perfectly real threads. It just isn't suitable for concurrent computation in pure Python code due to the GIL.
The is also no such thing as a real time processor
There is, however, such a thing as a platform unsuitable for real-time processing. And commodity x86 platforms have been unsuitable for real-time processing ever since BIOSes decided to schedule code behind your back in SMM code without the OS being able to do anything about it. You need a very special BIOS to make sure this doesn't happen.
Smart card access has been broken in Linux Chrome for seven odd years, and that's *with* native PKCS plugins. Browser support for smartcards is still horrible. No wonder they had to go for java.
No. USB-PD is not a "firehose". That is not how electricity works. USB-PD specifies certain discrete voltage levels, but you can draw as much or as little current as you want. Devices are supposed to have a buck converter to adapt the voltage of the input to the voltage of the battery, and they can do so at a wide range of input voltages.
The only reason to raise the voltage at the USB connector is to reduce resistive losses in the cable by reducing the required current. Once the electricity arrives at the device it can be converted to whatever voltage is appropriate for the battery, and it can deliver exactly as much current as it should. There is absolutely no reason whatsoever why USB-PD would cause more damage to a battery than Qualcomm QC, in a correctly designed device.
It's not a year-long suspension. It's a permanent suspension of trust in their current roots. They can, however, re-apply after one year - with extra auditing over what is normally required - and if and when they pass that they may be let in again. If they do nothing, they don't get back in for free after a year.
I have no idea where the submitter got Fabrice Bellard from. This is hosted on a completely different site and authored by a completely different person. Yes, more than one person is capable of implementing an x86 emulator in Javascript. Bellard wrote his and never released the (editable) source; this guy, OTOH, wrote a more compatible emulator of his own (runs more than Linux) and open sourced it.
This is also old news, I remember seeing it quite some time ago. The site has been up since 2014. Slow news day much?
CyanogenMod still uses TZ/QSEE on phones where that is used in the original firmware.
However, that never reduces security, only increases it. If your passphrase is long enough not to be at risk of a bruteforce, then this attack does not affect you.
The problem is not "trusting" the proprietary crap, the problem is trusting it to improve security in any measurable way.
Android full disk encryption is just as secure as LUKS (in fact, under the hood it's dm-crypt just like LUKS, the key derivation is just different). This doesn't break the FDE. You still need the passphrase. What this does is break the "you need the hardware to access the FDE and we're going to impose additional non-provable restrictions such that you can keep using your 4-digit PIN and it'll be secure, promise" bunch of hot air that vendors like to sell you. Just like the FBI cracked that iPhone's FDE - by bruteforcing the passcode. This lets you bruteforce Android's FDE offline after a one-time attack on the hardware.
I use CyanogenMod on my phone. I have my FDE passphrase set to a long string, independent of my (shorter) unlock code. This attack doesn't affect me because my FDE passphrase is not bruteforceable in a reasonable amount of time. This only affects people who still think using a 4-digit PIN to secure FDE on their phone is a good idea because Apple and Qualcomm pinkie-promise that their secure tamperproof hardware can limit bruteforce attempts enough to make that a reality.
A security researcher who goes around looking for ATM skimmers should know that the magstripe reader always goes along with a camera for the PIN pad, and that the electronics inside the card reader part aren't the whole story.
It's completely obvious once you look for it, once you know a skimmer was installed on the card slot, especially having another pristine ATM right next to it to compare. Nobody's going to blame someone for not noticing a skimmer in the first place, but once you know one was installed, yes, the PIN pad part is blatant.
The ARM has nothing to do with game consoles. The PS4 and the Xbox One don't even use the ARM for their secure boot/DRM, they use something else (the PS4 uses the SAMU which is an LM32 derivative core inside the GPU portion, and I think the Xbox One uses more custom stuff). Read this libreboot page; the ARM is required to boot any modern AMD chip. Or this if you want a reference from AMD from last year. The PSP is very much alive and well and required to boot modern AMD chips.
... and guess what, AMD CPUs have an extra ARM core in them, as well as multiple little cores of various architectures attached to the GPU. All running proprietary firmware.
Throwing random little CPUs at problems is nothing new. What makes you think the firmware in your PCIe WiFi card also can't access all main memory and be turned into a rootkit? What about the Embedded Controller on laptops, that runs even when it's off?
Yes, the state of firmware auditability of modern PCs is dismal. It's been like this for at least a decade. Yes, Intel does it one way, AMD does it another way, and just about every other peripheral on your board is also an attack surface. GPU? Dozens of little auxiliary cores (unrelated to the GPU unified shaders); Nvidia or AMD, doesn't matter. That USB 3.0 host controller? Probably runs firmware too. Ethernet? Yup, often has firmware these days. That LSI SAS controller? Full PowerPC core with enough oomph to run Linux itself. Your hard drive? 3 ARM cores, you can make them run Linux too. And all of those things can scribble all over your main memory unless you enable the IOMMU (except the HDD, that one can scribble all over your storage instead).
Length doesn't matter. What matters is that you use a unique password for everything.
Using a unique password for everything is impractical without making your passwords random (for a secure definition of unique, i.e. you can't guess one password given another one). But once you make them random, it doesn't matter how long they are as long as they're at least 6 (if fully random), preferably 8 (if constrained) characters or so.
Why? Because your password doesn't have to withstand an offline brute-force attack. It has to withstand an online, over-the-network brute-force attack. If the attacker gets your password hash such that they can use an offline attack, they have already broken into that service and have all your data anyway. And, since you use different password everywhere, cracking your password on that service gets them nothing.
Passphrases used to directly generate or wrap encryption keys are the exception to this, of course. Those had better be long.
Me? I use a pwgen-generated password on all sites/services, with the defaults (8 characters, pronounceable), and write them down in an encrypted password file. It's great, because I end up easily remembering the ones I use often, and the rest I look up as I need them. Can you crack those offline? Absolutely. But I couldn't care less; if you already have the hash, there's nothing more you get by cracking it.
Yup, they don't have any Seagate 3TB drives this time around... because they were so bad they ditched them all late last year. Meanwhile, as you mention, the ST4000DM000 (at 2.54% failure, sample size 34k drives) is doing better than the WD drives. The ST4000DX000 stat is not statistically significant, as they don't have many of those drives.
No, it will affect you if you choose to ignore the results and buy a *3TB* Seagate drive.
When will people stop picking stupid manufacturer sides when it comes to drive reliability? It has nothing to do with manufacturers and everything to do with models. *Every* drive maker has put out shitty models that fail in dumb ways, from HGST (ex-IBM)'s DeathStars to Samsung's firmware fail (I still own a bunch of HD204UIs with an unfixed firmware bug that eats data if you dare use SMART self-tests) to Seagate's 3TB failures. Picking manufacturer sides just means you'll get hit whenever they make the next broken drive.
If you actually look at their per-drive stats, you'll see that Seagate's 4TB drive is, so far, *more* reliable than WD's current drives. I have a bunch of those and they're mostly running fine - though I had one drop off the controller last weekend (came back after reboot), first failure in years, I need to look into that. We'll see. Right now, 4TB Seagates seem to be the best bang per buck with decent reliability. Next year it might be another brand/drive.
Except Google does own the font. It's not an off the shelf font. They took Futura and tweaked it to their liking. Googe used Google's version with all the tweaks.
Same as Win95 32-bit edition. 64-bit CPUs can run 32-bit code just fine. What I mean is that QEMU is emulating 64-bit capability, which presumably adds at least a bit of overhead compared to building it in 32-bit mode only (and this is on a 32-bit host).
I have no idea what emulator he's using, but it gets the prize for slowest x86 emulator of the year. Windows 95 is *lightweight* compared to anything modern, even under an emulator.
Let's see, quick test here. Samsung Chromebook, which is a dual-core Cortex-A15 (ARMv7) at 1.7GHz. Let's set cpufreq cap to 500MHz (Apple Watch is 520MHz). Install Win95 on a PC under QEMU, copy it over to the Chromebook, compile QEMU (for some reason it's not in the Arch Linux ARM repo...), and boot it up.
Boot time, from qemu launch to desktop and no "hourglass" cursor? 90 seconds. Emulating a PC on a 500MHz ARMv7.
Okay, so the Apple watch probably uses a lighter weight core than the Cortex-A15 on the Chromebook, but still, that doesn't anywhere near account for this kind of discrepancy. Oh, and QEMU is actually emulating a full 64-bit CPU (which of course Win95 doesn't need).
Actually, there is no EEPROM in the SoC. The ROM firmware is, well, a true mask ROM (the first stage), and the rest is loaded from external NAND flash. It's actually impractical to put EEPROM onto the same chip as a modern high-end SoC: it would be too cost-prohibitive or take too long to develop, because EEPROM needs special processing steps that regular CMOS chips don't. You'll never find EEPROM/Flash on a leading edge, high-end process, it's always older stuff. This is why eFuses and other OTP technologies are used, because some of them can be done without any special processing steps. And why just about any decently powerful device always has a little 8-pin flash chip to hold the firmware next to the main SoC. You only get embedded flash with low-end microcontrollers.
Some (particularly older) OTP chips are just EPROM (one "E") - the kind you erase with UV light - without the UV window. EEPROM is actually UV-erasable too, and one of the things often done to reset security "fuses" in EEPROM-based microcontrollers is to apply UV light in the right spot. Chip designers end up using shield metal above the bits, sometimes not very successfully (I recall one such chip was hacked by putting the light at an angle to get in under the upper metal shield). But this is the realm of lower-end microcontrollers with embedded EEPROM/Flash.
Slashdot Mirror
You can make a VM look a lot like the host. I don't know if the license allows you to run Windows inside a VM on top of another instance of Windows with one license, but what I actually do is run the natively-installed Windows inside a VM running on my also-natively-installed Linux (so I can boot Windows natively, or boot it inside a VM on Linux) - a single instance of Windows 10, just with or without a hypervisor under it (this should be perfectly legal; I recall actually reading through the EULA and it being ambiguous about this usage). I made sure the VM had the same CPU settings, the same GUID, the same hard disk serial number, and a few other identifiers. Windows isn't complaining and claims it's correctly activated, regardless of whether I boot it on bare metal or on the VM.
This used to be sometimes problematic when I had Windows 7, but Windows 10 hasn't given me any trouble. Perhaps they loosened up the hardware checks.
... which Python only uses for auxiliary purposes. Just call gc.disable(). Poof, no garbage collection. No memory leaks as long as you do not use data structures with reference cycles, either.
Let's assume you're talking about CPython, because Python is a language, not an implementation.
No it doesn't. CPython supports threading.
No it doesn't. CPython uses OS threads, it does not do its own time slicing.
What you're thinking about is the GIL, which ensures that only one (real) thread is running *inside the interpreter* at any one point. You can spawn multiple CPython threads and they will be *real* threads scheduled by the OS. However, they will mutex each other out of running the interpreter at once in multiple threads. You can make blocking OS calls, or calls out to C code that is thread-safe, and they will run concurrently on multiple cores. No time-slicing.
CPython has perfectly real threads. It just isn't suitable for concurrent computation in pure Python code due to the GIL.
There is, however, such a thing as a platform unsuitable for real-time processing. And commodity x86 platforms have been unsuitable for real-time processing ever since BIOSes decided to schedule code behind your back in SMM code without the OS being able to do anything about it. You need a very special BIOS to make sure this doesn't happen.
Smart card access has been broken in Linux Chrome for seven odd years, and that's *with* native PKCS plugins. Browser support for smartcards is still horrible. No wonder they had to go for java.
No. USB-PD is not a "firehose". That is not how electricity works. USB-PD specifies certain discrete voltage levels, but you can draw as much or as little current as you want. Devices are supposed to have a buck converter to adapt the voltage of the input to the voltage of the battery, and they can do so at a wide range of input voltages.
The only reason to raise the voltage at the USB connector is to reduce resistive losses in the cable by reducing the required current. Once the electricity arrives at the device it can be converted to whatever voltage is appropriate for the battery, and it can deliver exactly as much current as it should. There is absolutely no reason whatsoever why USB-PD would cause more damage to a battery than Qualcomm QC, in a correctly designed device.
#define _XOPEN_SOURCE 700
#include <signal.h>
#include <unistd.h>
int main() {
sigset_t set; int status; if (getpid() != 1) return 1;
sigfillset(&set); sigprocmask(SIG_BLOCK, &set, 0);
if (fork()) for (;;) wait(&status);
sigprocmask(SIG_UNBLOCK, &set, 0); setsid(); setpgid(0, 0);
return execve("/etc/rc", (char *[]){ "rc", 0 }, (char *[]){ 0 });
}
Until Google does exactly the same thing in Chrome... which they probably will, as one of the authors of that document works for Google.
Speaking of Comodo... (bonus: WoSign owner also tries to step in and makes a fool of himself).
It's not a year-long suspension. It's a permanent suspension of trust in their current roots. They can, however, re-apply after one year - with extra auditing over what is normally required - and if and when they pass that they may be let in again. If they do nothing, they don't get back in for free after a year.
Too bad this isn't his.
Fabian Hemmer (http://copy.sh/, copy@copy.sh)
I have no idea where the submitter got Fabrice Bellard from. This is hosted on a completely different site and authored by a completely different person. Yes, more than one person is capable of implementing an x86 emulator in Javascript. Bellard wrote his and never released the (editable) source; this guy, OTOH, wrote a more compatible emulator of his own (runs more than Linux) and open sourced it.
This is also old news, I remember seeing it quite some time ago. The site has been up since 2014. Slow news day much?
CyanogenMod still uses TZ/QSEE on phones where that is used in the original firmware.
However, that never reduces security, only increases it. If your passphrase is long enough not to be at risk of a bruteforce, then this attack does not affect you.
The problem is not "trusting" the proprietary crap, the problem is trusting it to improve security in any measurable way.
Android full disk encryption is just as secure as LUKS (in fact, under the hood it's dm-crypt just like LUKS, the key derivation is just different). This doesn't break the FDE. You still need the passphrase. What this does is break the "you need the hardware to access the FDE and we're going to impose additional non-provable restrictions such that you can keep using your 4-digit PIN and it'll be secure, promise" bunch of hot air that vendors like to sell you. Just like the FBI cracked that iPhone's FDE - by bruteforcing the passcode. This lets you bruteforce Android's FDE offline after a one-time attack on the hardware.
I use CyanogenMod on my phone. I have my FDE passphrase set to a long string, independent of my (shorter) unlock code. This attack doesn't affect me because my FDE passphrase is not bruteforceable in a reasonable amount of time. This only affects people who still think using a 4-digit PIN to secure FDE on their phone is a good idea because Apple and Qualcomm pinkie-promise that their secure tamperproof hardware can limit bruteforce attempts enough to make that a reality.
A security researcher who goes around looking for ATM skimmers should know that the magstripe reader always goes along with a camera for the PIN pad, and that the electronics inside the card reader part aren't the whole story.
It's completely obvious once you look for it, once you know a skimmer was installed on the card slot, especially having another pristine ATM right next to it to compare. Nobody's going to blame someone for not noticing a skimmer in the first place, but once you know one was installed, yes, the PIN pad part is blatant.
Backwards compatibility. They still mostly work in foreign ATMs that only use the magstripe.
... the blatant camera/panel overlay above the PIN pad, which is almost certainly where the main logic and storage of the skimmer is.
The ARM has nothing to do with game consoles. The PS4 and the Xbox One don't even use the ARM for their secure boot/DRM, they use something else (the PS4 uses the SAMU which is an LM32 derivative core inside the GPU portion, and I think the Xbox One uses more custom stuff). Read this libreboot page; the ARM is required to boot any modern AMD chip. Or this if you want a reference from AMD from last year. The PSP is very much alive and well and required to boot modern AMD chips.
... and guess what, AMD CPUs have an extra ARM core in them, as well as multiple little cores of various architectures attached to the GPU. All running proprietary firmware.
Throwing random little CPUs at problems is nothing new. What makes you think the firmware in your PCIe WiFi card also can't access all main memory and be turned into a rootkit? What about the Embedded Controller on laptops, that runs even when it's off?
Yes, the state of firmware auditability of modern PCs is dismal. It's been like this for at least a decade. Yes, Intel does it one way, AMD does it another way, and just about every other peripheral on your board is also an attack surface. GPU? Dozens of little auxiliary cores (unrelated to the GPU unified shaders); Nvidia or AMD, doesn't matter. That USB 3.0 host controller? Probably runs firmware too. Ethernet? Yup, often has firmware these days. That LSI SAS controller? Full PowerPC core with enough oomph to run Linux itself. Your hard drive? 3 ARM cores, you can make them run Linux too. And all of those things can scribble all over your main memory unless you enable the IOMMU (except the HDD, that one can scribble all over your storage instead).
Sleep tight.
Length doesn't matter. What matters is that you use a unique password for everything.
Using a unique password for everything is impractical without making your passwords random (for a secure definition of unique, i.e. you can't guess one password given another one). But once you make them random, it doesn't matter how long they are as long as they're at least 6 (if fully random), preferably 8 (if constrained) characters or so.
Why? Because your password doesn't have to withstand an offline brute-force attack. It has to withstand an online, over-the-network brute-force attack. If the attacker gets your password hash such that they can use an offline attack, they have already broken into that service and have all your data anyway. And, since you use different password everywhere, cracking your password on that service gets them nothing.
Passphrases used to directly generate or wrap encryption keys are the exception to this, of course. Those had better be long.
Me? I use a pwgen-generated password on all sites/services, with the defaults (8 characters, pronounceable), and write them down in an encrypted password file. It's great, because I end up easily remembering the ones I use often, and the rest I look up as I need them. Can you crack those offline? Absolutely. But I couldn't care less; if you already have the hash, there's nothing more you get by cracking it.
This release contains security fixes. At least this one stood out, but more of the changelog sounds like it might fix exploitable issues.
Yup, they don't have any Seagate 3TB drives this time around... because they were so bad they ditched them all late last year. Meanwhile, as you mention, the ST4000DM000 (at 2.54% failure, sample size 34k drives) is doing better than the WD drives. The ST4000DX000 stat is not statistically significant, as they don't have many of those drives.
No, it will affect you if you choose to ignore the results and buy a *3TB* Seagate drive.
When will people stop picking stupid manufacturer sides when it comes to drive reliability? It has nothing to do with manufacturers and everything to do with models. *Every* drive maker has put out shitty models that fail in dumb ways, from HGST (ex-IBM)'s DeathStars to Samsung's firmware fail (I still own a bunch of HD204UIs with an unfixed firmware bug that eats data if you dare use SMART self-tests) to Seagate's 3TB failures. Picking manufacturer sides just means you'll get hit whenever they make the next broken drive.
If you actually look at their per-drive stats, you'll see that Seagate's 4TB drive is, so far, *more* reliable than WD's current drives. I have a bunch of those and they're mostly running fine - though I had one drop off the controller last weekend (came back after reboot), first failure in years, I need to look into that. We'll see. Right now, 4TB Seagates seem to be the best bang per buck with decent reliability. Next year it might be another brand/drive.
Except Google does own the font. It's not an off the shelf font. They took Futura and tweaked it to their liking. Googe used Google's version with all the tweaks.
Same as Win95 32-bit edition. 64-bit CPUs can run 32-bit code just fine. What I mean is that QEMU is emulating 64-bit capability, which presumably adds at least a bit of overhead compared to building it in 32-bit mode only (and this is on a 32-bit host).
I have no idea what emulator he's using, but it gets the prize for slowest x86 emulator of the year. Windows 95 is *lightweight* compared to anything modern, even under an emulator.
Let's see, quick test here. Samsung Chromebook, which is a dual-core Cortex-A15 (ARMv7) at 1.7GHz. Let's set cpufreq cap to 500MHz (Apple Watch is 520MHz). Install Win95 on a PC under QEMU, copy it over to the Chromebook, compile QEMU (for some reason it's not in the Arch Linux ARM repo...), and boot it up.
Boot time, from qemu launch to desktop and no "hourglass" cursor? 90 seconds. Emulating a PC on a 500MHz ARMv7.
Okay, so the Apple watch probably uses a lighter weight core than the Cortex-A15 on the Chromebook, but still, that doesn't anywhere near account for this kind of discrepancy. Oh, and QEMU is actually emulating a full 64-bit CPU (which of course Win95 doesn't need).
Actually, there is no EEPROM in the SoC. The ROM firmware is, well, a true mask ROM (the first stage), and the rest is loaded from external NAND flash. It's actually impractical to put EEPROM onto the same chip as a modern high-end SoC: it would be too cost-prohibitive or take too long to develop, because EEPROM needs special processing steps that regular CMOS chips don't. You'll never find EEPROM/Flash on a leading edge, high-end process, it's always older stuff. This is why eFuses and other OTP technologies are used, because some of them can be done without any special processing steps. And why just about any decently powerful device always has a little 8-pin flash chip to hold the firmware next to the main SoC. You only get embedded flash with low-end microcontrollers.
Some (particularly older) OTP chips are just EPROM (one "E") - the kind you erase with UV light - without the UV window. EEPROM is actually UV-erasable too, and one of the things often done to reset security "fuses" in EEPROM-based microcontrollers is to apply UV light in the right spot. Chip designers end up using shield metal above the bits, sometimes not very successfully (I recall one such chip was hacked by putting the light at an angle to get in under the upper metal shield). But this is the realm of lower-end microcontrollers with embedded EEPROM/Flash.