Posts by gnasher729 2334 publicly visible posts • joined 13 Oct 2014
MITM attacks run into legal problems. In at least two cases the encrypted message didn’t get touched, but a software update contained code that would send the unencrypted message directly to the police. With a MITM attack police might have no evidence that is acceptable by a court. If they modify your software to send unencrypted messages then it is much easier to use legally. .
Anonymous: The application sends the same message encrypted to an ultra secure server which sends it 100% safely to the planned receiver, and the original unencrypted message to the police. Thats done with a software update, without any changes to the server.
And since the app tries to prevent anyone from accessing your message, it also prevents anything from detecting that two messages are sent instead of one.
You can write macOS code, compile it for ARM and x86, and run both on an ARM silicon Mac. The Intel version will automatically be translated from Intel to ARM assembler code using Clang.
The result runs typically at 80% of the speed of an ARM processor. So thats at most the penalty: 20% slower after translating assembler code.
Intel processors are just not very fast. If you look at performance per Watt they don’t come close to Apples ARM implementation. There are people who use Apple Silicon because it runs Intel code at same speed for much less power.
No, you don’t get six or five years. You get a “reasonable time” from the date of sales until the defect is found. The repair can take a bit longer. And a device less durable then it should be is defective from day one. But six years is when statute of limitations runs out.
"Sarcasm aside, how much help on this are we getting from the current x86 architecture? Hardware-based runtime checks should be much-faster than software-only-based runtime checks."
Says who? Software based can run through an optimiser. So in a loop for (i = 0; i < n; ++i) a[i] = 0; I can get away with exactly one check in software (is n greater than the size of the array). But then there has been tons of effort to make normal code run fast that is used by software-only runtime checks. With hardware checks, good luck integrating this into the normal code flow.
So let's say I have an array with 100 elements and do an assignment a[101] = 0. Undefined bheaviour in C or C++. In Swift I know it will crash the application. Instantly and guaranteed. Which is likely the best possible outcome, but obviously not good. In Objecctive-C it throws an exception which is unlikely to get handled properly. No matter what, the user is f****d.
So what exactly does it do in Rust, and how is that safe?
Mersenne primes have a special form. There are primality tests that work well if you have the complete factorisation of n + 1. And for Mersenne primes, we know the complete factorisation of n + 1, because (2^k-1) + 1 is just a power of two. Proving that a general number is a prime is much much much harder.
That’s what the article says. The obvious way to go is to use speculative execution wherever it doesn’t reveal internal information to the outside (99% of the time) and don’t use it when it does. So with a lot of care you can remove the problems with very little performance impact.
The main problem is that this is hard to test. You need a test case that is vulnerable against spectre and not vulnerable against spectre after a fix. And that apparently wasnt tested correctly.
With Spectre, someone figured out that predictive execution could open a side channel. On the other hand those calling to abolish it seem unaware what kind of performance gains it gives. It’s not percent, it’s factors two or three. Want your processor to crawl, turn off predictive execution.
The article states quite clearly that this is different; Out of the many changes to defang Sceptre one wasnt implemented correctly. There is just a bug. I guess it’s an area that is very hard to test, but still a bug. They had a correct design that would have fixed the problem and it wasn’t implemented correctly.
O just realised the big differences between Sunak and Trump. First, Sunak made his fortune himself. Not thanks to millions and millions of dollars from a racist scum dad.
Second, plenty of press that claims “Sunak doesn’t understand how little people think and doesnt care for them” when in reality he has done his best for the UK (tough job after Liz Truss bringing us to the brink of bankruptcy), while in the USA the idiots actually think that Trump cares for them, while he only sees them as stupid marks. Or as scapegoats. Because fascism doesnt work without scapegoats.
Twitter is financially painful for Musk, but it won’t bankrupt him. Another court case not allowing him to steal $56bn from Tesla share holders that might help more.
Twitter just loses over half a billion per year, plus 1.2 billion unpaid interest. The banks will suffer for their loans and unpaid interest when musk lets Twitter go bankrupt, but for him the damage is already done.
Nothing to do with that. Two problems: Mothrrboard makers asked for more voltage and power than they should. And Intel hardware produced higher voltage and power use than asked for. The chips (probably) survive one of those, but definitely not both.
An ARM chip would have the same problem. If Apple asked for more power than is safe, and then provided more power than the already unsafe amount it’s asked for, then the chips would be just as damaged. It’s just that Apple doesn’t overclock its chips.
What they shipped to customers just could never work. That was not a bug that you could miss, that bug would have crashed on everybody single machine it was tried without exception. Before testing comes “trying out if it works”. Neither the developer nor their test system did that.
The bug itself was a combination of a totally broken configuration file reader and a tiny mistake in a configuration file. A configuration file reader should survive _anything_ you throw at it. That is an unforgivable weakness.
Interestingly, I see nothing that makes this related to the kernel in any way.
Apple looks at the long term as well. The best overall strategy would be to hang on to lightning as long as possible, and then on one day switch to USB-C. Because what’s worst is using both at the same time. Like ripping of a plaster, it’s painful but has to be done.
Curiously the EU is talking about “USB-C chargers” all the time. My charger is a bit old, so it has four old-style ports with USB-A (or is it B?) ports with 19 Watts and one 27 watt port with a USB-C port. Now there are four different cables I could plug in, and they all work. One cable is USB-C to lightning and it does 27 Watt on my old iPhone like USB-C should do, and one is USB-a to lightning doing 19 watt. So my iPhone supports USB-c charging through its lightning port. Old iPad doesnt support usb-c but the same cables work. Except you get 19 instead of 27 watt from the usb-c port on the charger.
But then the whole rule is nonsense. It makes sense for new devices, but for old ones whatever damage there is, that damage is already done and selling the device and keeping it in use is surely better than buying a new device.
It’s like plastic straws: You shouldn’t buy them because they are bad for the environment when you throw them away. So some idiots throw them all away, which causes exactly the damage they want to prevent. I say the damage was done when you bought them, so once bought you might as well use them.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
