Re: We need the Mozilla / Firefox phone!
268 posts • joined 22 May 2018
Could it be any more inefficient and bogus (continuously vulnerable, just utter out ‘media-framework’ aloud) than Android?
If it wasn’t for that ton of Apps... Android spyware itself can be considered a pile a crap. Some sort of capability to run Android apps would suffice (as Sailfish-OS does).
It's not that it isn't true, it's just that this is normally not being reported like this (attempting to kill a company).
Pick your favorite brand and add the terms "battery explodes", doing a web-search. Just two examples:
iPhone battery explodes in the middle of a store | New York Post
Motorola Droid 2 cell phone EXPLODES in mans ear
Unless I missed something, we’re still unable to take pieces out of files or add something at the beginning/in the middle. This is, because our systems were based on tape recorders. Adding something in the middle or at the beginning was simply impossible.
Today we have random access SSDs with block-based file-systems and we still treat them like tape recorders. As much as I hate being the Cassandra, just imagine how long it’s going to take before your system will truly utilize something like eMRAM. ;-)
They mention the possibility to combine this with “Row Hammer”. Row Hammer exploits a hardware defect/design fault of dynamic random-access memory (DRAM), which allows you to “flip bits” in memory. If you know WHERE to flip a bit, you can let lose the mentioned hammer. Flipping the right bit can get you access to the entire system. For instance, you can turn a “read-only” page table into a writable one and change system code, etc. pp.
>>But that's what the customers demand: good, safe, fast--all or nothing. Anything who replies, "I'm sorry I can't do that" gets left for the one that says "Can do."<<
Nah, 'the customers' didn't invent the MMU to afterwards ignore it for the sake of speed.
I remember the first patches hitting me (Intel) hard. I was running stuff in a VM and it suddenly felt like the handbrake was on.
Don't be mislead by the average penalties of those mitigations. It depends mostly on what you are doing - and in some cases, you're fûcked!
Michael has done some benchmarks to show the impact of Spectre mitigations (hint: Linux usually handles this better than Windows and others). Check out the results on:
In the Netperf benchmark, Intel’s 8086K performs less than 1/8th – in other words: without mitigations (which is how Intel benchmarks them;-) the processor would be more than eight times faster!
... and there are more to come.
“…just won't quietly die in the IT world”
The hardware is bogus. Not only do you get to keep your expensive junk, which they sold you under false pretense (MMU, multiuser system capabilities, VM addons, etc.), but you can acquire new expensive hardware that is just as faulty as the one you got. Thereby, the faults stick around - surprise!
As a programmer I feel the urge to oppose this “there is no alterative” non-sense. When it comes to number crunching on the big irons, speculative execution doesn’t get you much.
When it comes to the normal user and your everyday experience, better code could easily speed up the performance by a factor of ten and more.
In the recent years we have seen software becoming slower and slower. It is almost as if chip makers ordered their minions to apply handbrakes everywhere.
Wherever you look, programmers are trying to slow down your everyday experience. Just look at Android. Their phones now have eight cores and four GB of RAM or more. Some people say that you shouldn’t buy a phone with less than two GB, because “multitasking” isn’t going to work well, otherwise.
Those phones are yesterday’s workstations. They are running a system that is so inefficient that it hogs gigabytes of memory and needs gigahertz to display the system interface without excessive delays. It’s a joke.
We don’t need super-fast processors for typical usages. Better programming can speed up your experience more than a liquid hydrogen cooled super processor could. As a conclusion, we don’t need bogus processors. We could do very well without them.
Intel ME runs an entire system that can access everything WITHOUT YOUR control. The NSA (and others) have everything they ordered with Intel & co.
I'm afraid that Spectre comes due to simple cheating. They made their processors faster. All they had to do, was remove a little safety here and there. ;-)
That is from '18 Jan 2018'. It states that:
"Techies are scratching their heads after Red Hat pulled a CPU microcode update ..."
"...stalling on rolling out microcode patches after Intel admitted its firmware caused systems to fall over."
In other words: Intel had release a buggy microcode update, which caused problems. Therefore, some distributions didn't (temporarily) distribute it (until it got fixed).
(The same - buggy - microcode would cause the same problems when installed via BIOS, btw.)
"For SPECTRE and Meltdown, there were two levels of mitigation, firmware and software. For Meltdown (IIRC), software mitigations were only partially effective; you needed a firmware update from your hardware vendor for complete prevention."
This is misleading. What you call 'firmware' is the microcode. This is CAN be "loaded into the CPU" by the BIOS at each boot, but it's typically done by the operating system (anyhow). For Intel and Linux, for example, the package is called "intel-microcode". Other mitigations are part of the kernel (Linux, Windows, etc.). Others again, get worked into compilers...
That said, if you are using "a typical" operating system, you do not need the fixes for your BIOS.
"So I don't think that particular issue has any motherboard-level ramifications. ...
I may be failing to think of the proper angle."
Yes and no. If you are using a 'modern' up-to-date operating system (Linux, BSD, Windows-10, Mac-OS) the mitigations are applied by the operating system. If, however, you want to run something 'out of the ordinary' (or old), which doesn't come with mitigations (OS/2;-) then loading the mitigations via the BIOS would apply them anyhow. Without the BIOS fixes, such a - Weirdo-OS - would be unprotected.
Then again, it has to be said that the current mitigations are far from perfect and likely don't really close even nearly all the holes...
1. There's nothing "cheating" about speculative execution. It turns out it has a huge security downside, but nobody realized that at the time."
Right, so you believe that nobody noticed that they were ignoring the MMU - thus treating every system as if it were a single user system running DOS during speculative execution?
You are aware that there are plenty of people involved in such a process? Some of them having intimate knowledge of the CPUs... and you believe that they all failed to see this "little detail"?
Forcing your software to circumnavigate the hardware bugs, just so they can keep selling them with a 'cheating' speculative execution engine. Yes, it’s cheating. It’s running all the red lights. That’s why it’s so efficient.
Guess what? You are paying triple by circumventing this in software, which makes the whole thing even slower. Yet, Intel keeps publishing benchmarks WITHOUT mitigations enabled; something that should be illegal to begin with.
They are trying to make this look as if something immensely complicated has a few bugs. Shit happens, right? Wrong. This is a fundamental problem. It’s not that they didn’t know they were ignoring the red lights. They simply chose to do so, because cheating can be lucrative. Remember Volkswagen with their "super clean" cars? How did they manage to get them that clean again? Oh yeah, just like Intel managed to get their crappy processors so fast...
You may throw in "But what about the competitors? Didn’t they cheat as well?" Again, just like Volkswagen. The competitors (not all of them) had to follow. It was either that or make it public that they were cheating.
Here’s some insider information for you: With Volkswagen, they tried to make it public since 2007 without avail! Only when a US secret service thought that it was time to punish the Germans, it made the headlines and went to court.
With Intel, it’s the other way round. German "intelligence" is behind "rendering those bugs public" (revenge) and the US is backing Intel. Hence, no refunds and let’s pretend that those "bugs" are unavoidable.
I wish the (compiler) programmers had the guts to refuse, simply telling them that the hardware needs to be replaced.
Biting the hand that feeds IT © 1998–2019