offtop: What's the point of using google groups?
Mailing lists are great. Better than a slack for long-term discoverability.
Single random bit flip causes error in certificate transparency log
161–170 of 258 posts
Re: Single random bit flip causes error in certificate transparency log
#162> I think the most likely explanation is that this was a hardware error caused by a cosmic ray or the like, rather than a software bug. It's just very bad luck :-(
These sorts of cosmic bitflips have been exploited as a security error for some time. See bitsquatting for domain names.
ECC helps and so does software error detection on critical data in memory or on disk. The problem is always that input data should not be relied upon as correct. Do not trust data. It's a difficult mind shift, but it needs to be done, or programs will continue to mysteriously fail when data becomes corrupted.
Re: Single random bit flip causes error in certificate transparency log
#163Re: Single random bit flip causes error in certificate transparency log
#164Earlier quoted context omitted.
This is just learned helplessness because Intel were stingy as shit for over a decade and wanted to segregate their product lines. Error correction is literally prevalent in every single part of every PHY layer in a modern stack, it is an absolute must, and the lack of error correction in RAM is, without question, a ridiculous gap that should have never been allowed in the first place in any modern machine, especiall…
> By definition, if a failure occurs, it's because it passed multiple safeguards that were already in place. Having worked on a good bunch of critical system, there aren't multiple safeguards in most hardware. E.g. a multiplication error in a core will not be detected by an external device. Or a bit flip when reading cache, or from a storage device. Very often the only real safeguard is to do the whole computation tw…
> Very often the only real safeguard is to do the whole computation twice on two different hosts.
Three different hosts, for quorum, right?
Re: Single random bit flip causes error in certificate transparency log
#165A few years ago there was a CCC? talk about registering domains a bitflip away from the intended domain. Which effectively hijacked legitimate web traffic. While the chance of a bitflip is low it added up to a surprisingly large number of requests maybe a few hundred or so. Here is someone doing it for windows.com https://www.bleepingcomputer.com/news/security/hijacking-tra...
It's a well-known attack on a security vulnerability called bitsquatting.
Re: Single random bit flip causes error in certificate transparency log
#166Earlier quoted context omitted.
That's not what actually happened here (probably), but think of relatively heavy atoms like iron, ejected from a supernova at close to the speed of light. They're not really "rays". They're solid particles that punch holes in everything. The good news is, mostly they're ionized and they get repelled away from hitting the planet's surface by our magnetic field (generated by the big hot iron magnet that's churning unde…
> That's not what actually happened here (probably), but think of relatively heavy atoms like iron, ejected from a supernova at close to the speed of light. They're not really "rays". Wow, I have to admit I always assumed cosmic rays to be gamma radiation but alpha particle radiation sounds a lot more scary. Does anyone happen to know if computers engineered for the space station or shuttles have already some built-i…
The vast majority of the cosmic radiation consists of protons, i.e. hydrogen ions.
Light ions, e.g. of helium, lithium or boron are also relatively abundant and heavier ions are less abundant. There are also electrons, but in smaller quantities, because they can be captured by ions.
The high speed protons collide with the atoms of the Earth atmosphere and the collisions generate a huge variety of particles, but most of them have a very short lifetime, so they decay before reaching ground level.
At ground level, the cosmic radiation consists mostly of muons, because they have a longer lifetime, so they survive the travel from the upper atmosphere where they are generated, until ground level.
Only extremely few of the particles from the primary cosmic radiation, i.e. protons, reach ground, because most are deflected by the magnetic field of the Earth and the remaining protons lose their energy in the collisions with atmosphere, by generating particles, which eventually decay into muons.
Re: Single random bit flip causes error in certificate transparency log
#167Earlier quoted context omitted.
It doesn't really matter whether they have if (launch1 && launch2 && launch3) { launch(); } either because a single bit flip (of the code) could still cause a launch. You'd hope that it was at least stored in ROM and that ECC ensures that even if such a bit flips it does not lead straight to Armageddon. There are some 'near miss' stories where a single switch made all the difference: https://www.theatlantic.com/techn…
Obviously this anecdote is decades out-of-date, but my first boss’ PhD thesis is for an automatic small-airplane guidance system. I mean: as long as your plane was on a high speed ballistic arc and needed a guidance system that only ran for about 25 minutes. The guidance system used mercury & fluidic switches, in case the small aircraft encountered a constant barrage of extremely large EMPs.
Hehe, that's the most 'between the lines' comment ever on HN, congrats.
Re: Single random bit flip causes error in certificate transparency log
#168Earlier quoted context omitted.
Also, ECC ram is technically supported on AMD’s recent consumer platform, although it’s not advertised as so since they don’t do validation testing for it.
Not on all of it. They only don't lock it down on CPUs, but not on APUs. On AMD SoCs with integrated GPUs, ECC is not usable except if you buy the Ryzen Pro variant. And those are all laptops and most desktops...
Does e.g. the new Ryzen 7 5800U part support ECC?
Re: Single random bit flip causes error in certificate transparency log
#169Earlier quoted context omitted.
Process enough data and even ECC can - and will - fail undetected. Any kind of mechanism you come up with is going to have some rate of undetected errors.
Given the rate required for this its not a reasonable assumption. It's like saying Amazon sees sha256 collisions between S3 buckets. Just doesn't happen in practice.
Those two are many orders of magnitude apart, undetected bit flips in spite of ECC are a fact or life in any large computing installation.
Re: Single random bit flip causes error in certificate transparency log
#170Earlier quoted context omitted.
If a system is critical it should run on multiple machines in multiple locations and "sync with checks" kinda like the oh so hated and totally useless blockchains. Then if such a bit-flip would occur it would never occur on all machines at the same time in the same data. And on top of that you could easy make the system fix itself if something like that happens (simply assume the majority of nodes didn't have the bit…
Safety critical systems are not a good fit for a blockchain-based resolution to the Byzantine General problem. Safety critical systems need extremely low latency to resolve the conflict fast. So blockchain is not going to be an appropriate choice for all critical applications when there are multiple low-latency solutions for BFT at a very low ms latency and IIRC, microseconds for avionics systems.
Not sure what you mean with "safety critical". I made no such assumption. Also since the topic is about a (write-only) log it probably doesn't need such low latency. What it more likely needed is final states so once a entry is made and accepted it must be final and ofc correct. DLTs can do this distributed and self-fixing i.e. a node that tries to add fault data is overruled and can never get a confirmation for a final state that later would not be valid.
Getting the whole decentral system to "agree" will never be fast unless we have quantum tech. There is simply no way servers around the glob could communicate in microseconds even if all communication would be the speed of light and processing would be instant. It would still take time. In reality such system need seconds which is often totally fine. As long as everyone only relies on the data that has been declared final.