The microcode update "should not" brick hardware. The output of the command "rpm -qi microcode_ctl | tail -3" tells you why:
The microcode update is volatile and needs to be uploaded on each system boot i.e. it doesn't reflash your cpu permanently, reboot and it reverts
back to the old microcode.
This seems to focus on branch prediction and the impact of backing the pipeline contents. The error seems to center on taking a branch into privileged memory that is initiated by unprivileged code. Therefore, any CPU with branch prediction is likely suspect.
32-bit ARM may be safer, because speculative execution is much, much more difficult there.
The program counter is a visible register that can be manipulated by any opcode - an explicit JUMP or BRANCH is not necessary. This makes branch prediction mostly impossible.
Most opcodes are conditional. This dependency between adjacent instructions is also a huge obstacle for speculative execution.
Design errors, like having r15 as the program counter or making every instruction conditional, are problems for CPU architects rather than programmers, and it's no surprise that they disappeared in the 64-bit version of the ARM architecture. They must have made it awfully hard to implement superscalar, out-of-order execution.
The Snapdragon 808/810 has a habit of frying cores on the Google Nexus 5x and 6p. There are class actions on this problem as well.
There is a fix for the problem - disable the 4 large/fast cores, and run the phones only on the other 4 small/slow(er) cores.
As far as I know, Google has not pushed this fix out as an OTA. If the bootloader is unlocked, then an owner can apply an independent set of fixes (replace both the recovery and the boot.img, at the very least).
Apple at least detects and compensates for a basic hardware problem, but both companies should strive to also clearly report what is happening to the user.
An owner of a failed 5x or 6p likely admires Apple's approach.
LineageOS provides an optional root package. If you apply it, and you also apply a GAPPS package, Google's Skynet/(Safetynet) will mark you forever tainted and forbid you from using Android Pay or Netflix. I don't care about either of these features, so that's what I'm doing for now.
Option B: You can also skip GAPPS and run without Google. If you load F-Droid, you can use the Yalp app to pull non-GMS (Google Mobile Services) based apps out of Google Play for use on a non-Google version of LineageOS.
LineageOS updates will successfully apply either way.
I am carefully considering Option B for my upgrade to Oreo.
Here is an interesting difference between Apple and Google.
The CPUs in the Nexus 5x and 6p are prone to burning out the fast cores. When this thermal damage takes place, the phones go into boot-loops.
If you were smart enough to unlock the bootloader, you are able to install a version of TWRP that locks down the fast cores, and only uses the slow ones. From there, you can load a custom kernel that does the same, and restore limited functionality.
You would think that any sane company would immediately roll this into their stock ROM. You would be wrong - Google/Qualcomm did not, and there are a LOT of Nexus bricks now. Instead there is a class action, and Google is extending liberal trade-ins on Pixels (that have their own hardware problems).
The right answer to both Apple's battery and Google's Snapdragon fast-core meltdown is to detect, report, and compensate. At least Apple (unlike Google) was able to do two out of three.
Yes, systemd is/was new, and different from the classical/etc/inittab and/etc/inetd.conf. These features justify the changes:
-The user= and group= options allow spawned processes to be launched with reduced privilege as a non-root user. While inetd.conf could do this, inittab could not.
-The RootDirectory= option allows spawned processes to be confined to a chroot(). Neither inittab nor inetd.conf could do this directly.
-We now have standardized controls, instead of a pile of scripts in/etc/init.d - much cleaner.
-Path units allow standardized handlers for inotify events - your code can run when a file or directory changes.
-Containers can be launched with nspawn.
Systemd acceptance will increase when they push some of this into the POSIX standards. The first three above should not be difficult.
Instead of CentOS, it would have made more sense to benchmark Oracle Linux, running both the UEK (Unbreakable Enterprise Kernel), and the RHCK (Red Hat-Compatible Kernel).
I've never tried running the UEK on CentOS/RedHat/Scientific Linux. I'm assuming it's built with GCC and runs equally well on AMD vs. Intel.
AT&T has Common Carrier status, which is derived from English Common Law as documented in Blackstone. This Common Carrier status allows AT&T to install its equipment on the property of others by granting them a "right of way."
However, Common Carrier status has an important restriction (from the wiki):
An important legal requirement for common carrier as public provider is that it cannot discriminate, that is refuse the service unless there is some compelling reason.
What is going to happen is some organization that owns physical property with AT&T equipment installed on it will sue AT&T when they face digital discrimination, assert that (unlike voice traffic) AT&T no longer has Common Carrier status for their data traffic, and demand either the termination of data services traversing their property or fair compensation.
This will go to the Supreme Court, and it will be anybody's guess what will happen to telecommunications at that point - AT&T might have to start paying rent wherever their data lines are installed. It could all very well end in tears.
Slashdot Mirror
Try it. Pick a search term. Any search term.
Search results from Bing and DuckDuckGo are often identical. Try it.
The question is, how much of DuckDuckGo does Microsoft already own? If great success comes, how long until Bing embraces / extends / extinguishes it?
The Cortex-A75 is vulnerable according to ARM's own documentation.
Documented here - this is the only CPU listed by ARM as vulnerable to CVE-2017-5754.
ARM has reported that some of their processors are impacted.
The Cortex-A75 is supposedly vulnerable to all variants.
ARM has reported that some of their processors are impacted.
The microcode update "should not" brick hardware. The output of the command "rpm -qi microcode_ctl | tail -3" tells you why:
The microcode update is volatile and needs to be uploaded on each system boot i.e. it doesn't reflash your cpu permanently, reboot and it reverts back to the old microcode.
Under Oracle Linux 7.4, the command "ls /lib/firmware/intel-ucode/ | wc -l" reports 95 files in that location.
You can run "rpm -qi microcode_ctl" and "rpm -ql microcode_ctl" to get more information about what these are.
It's free to use and free of ads and malware - I assume that "Psiphon" isn't, since they mention how much government crackdowns help their marketing.
...I would not be surprised to see advocacy for alternative architectures from those circles, be that AMD or ARM.
Theo can now rightly say that Intel design flaws will have 0-day impacts on OpenBSD that are beyond his control.
Here is their timeline. Surprising that (unlike RedHat) there is still no patch.
State-level agencies also must have known. Intel might have had conversations with them about it.
Very interesting. Thank you for the information.
This seems to focus on branch prediction and the impact of backing the pipeline contents. The error seems to center on taking a branch into privileged memory that is initiated by unprivileged code. Therefore, any CPU with branch prediction is likely suspect.
32-bit ARM may be safer, because speculative execution is much, much more difficult there.
The program counter is a visible register that can be manipulated by any opcode - an explicit JUMP or BRANCH is not necessary. This makes branch prediction mostly impossible.
Most opcodes are conditional. This dependency between adjacent instructions is also a huge obstacle for speculative execution.
32-bit ARM is mostly in-order for these reasons.
https://www.jwhitham.org/2016/02/risc-instruction-sets-i-have-known-and.html
For such an amazingly portable runtime platform, it's curious how rarely I see operational .APKs on non-Android platforms.
This was not quite the panacea that we were led to believe so long ago.
The Snapdragon 808/810 has a habit of frying cores on the Google Nexus 5x and 6p. There are class actions on this problem as well.
There is a fix for the problem - disable the 4 large/fast cores, and run the phones only on the other 4 small/slow(er) cores.
As far as I know, Google has not pushed this fix out as an OTA. If the bootloader is unlocked, then an owner can apply an independent set of fixes (replace both the recovery and the boot.img, at the very least).
Apple at least detects and compensates for a basic hardware problem, but both companies should strive to also clearly report what is happening to the user.
An owner of a failed 5x or 6p likely admires Apple's approach.
Newer than the Blackphone is the Copperhead hardened Android.
There is a free download for the Nexus 5x and 6p (but these phones have a terrible habit of frying their CPUs).
They also sell Pixels preloaded with Copperhead, but these are quite expensive.
LineageOS provides an optional root package. If you apply it, and you also apply a GAPPS package, Google's Skynet/(Safetynet) will mark you forever tainted and forbid you from using Android Pay or Netflix. I don't care about either of these features, so that's what I'm doing for now.
Option B: You can also skip GAPPS and run without Google. If you load F-Droid, you can use the Yalp app to pull non-GMS (Google Mobile Services) based apps out of Google Play for use on a non-Google version of LineageOS.
LineageOS updates will successfully apply either way.
I am carefully considering Option B for my upgrade to Oreo.
Here is an interesting difference between Apple and Google.
The CPUs in the Nexus 5x and 6p are prone to burning out the fast cores. When this thermal damage takes place, the phones go into boot-loops.
If you were smart enough to unlock the bootloader, you are able to install a version of TWRP that locks down the fast cores, and only uses the slow ones. From there, you can load a custom kernel that does the same, and restore limited functionality.
You would think that any sane company would immediately roll this into their stock ROM. You would be wrong - Google/Qualcomm did not, and there are a LOT of Nexus bricks now. Instead there is a class action, and Google is extending liberal trade-ins on Pixels (that have their own hardware problems).
The right answer to both Apple's battery and Google's Snapdragon fast-core meltdown is to detect, report, and compensate. At least Apple (unlike Google) was able to do two out of three.
Yes, systemd is/was new, and different from the classical /etc/inittab and /etc/inetd.conf. These features justify the changes:
Systemd acceptance will increase when they push some of this into the POSIX standards. The first three above should not be difficult.
Very witty story, surprising and full of twists. Quite good.
While I saw Pertwee first, I will quote Shada to say that Baker had a certain style, flair, and panache.
Instead of CentOS, it would have made more sense to benchmark Oracle Linux, running both the UEK (Unbreakable Enterprise Kernel), and the RHCK (Red Hat-Compatible Kernel).
I've never tried running the UEK on CentOS/RedHat/Scientific Linux. I'm assuming it's built with GCC and runs equally well on AMD vs. Intel.
And brand new, prehacked ME binaries for easy, promiscuous access!
AT&T has Common Carrier status, which is derived from English Common Law as documented in Blackstone. This Common Carrier status allows AT&T to install its equipment on the property of others by granting them a "right of way."
However, Common Carrier status has an important restriction (from the wiki):
What is going to happen is some organization that owns physical property with AT&T equipment installed on it will sue AT&T when they face digital discrimination, assert that (unlike voice traffic) AT&T no longer has Common Carrier status for their data traffic, and demand either the termination of data services traversing their property or fair compensation.
This will go to the Supreme Court, and it will be anybody's guess what will happen to telecommunications at that point - AT&T might have to start paying rent wherever their data lines are installed. It could all very well end in tears.