Live data from Hacker News

Single random bit flip causes error in certificate transparency log

groups.google.com

251–258 of 258 posts

Re: Single random bit flip causes error in certificate transparency log

#251
post #189
post #110

Earlier quoted context omitted.

> The push for crypto without ecc ram is a nonstop horror show That's a bit hyperbolic. First, ECC doesn't protect the full data chain, you can have a bitflip in a hardware flip flop (or latch open a gate that drains a line, etc...) before the value reaches the memory. Logic is known to glitch too. Second: ECC is mostly designed to protect long term storage in DRAM. Recognize that a cert like this is a very short-ter…

Using ECC is a no-brainer. Even the Raspberry Pi 4 has ECC RAM. It’s not particularly expensive and only a artificial limitation Intel has introduced for consumer products.

The Pi 4 uses DRAM with on-die ECC, which AFAIK does not provide any means of reporting errors (corrected or uncorrected) to the SoC's memory controller. It is effectively a cost-saving measure to improve DRAM yields. As such, it does little to guarantee that there are no memory errors.

Re: Single random bit flip causes error in certificate transparency log

#252
post #190
post #189

Earlier quoted context omitted.

Using ECC is a no-brainer. Even the Raspberry Pi 4 has ECC RAM. It’s not particularly expensive and only a artificial limitation Intel has introduced for consumer products.

Thought you were wrong. Checked it out. You were right.. Under "1.2. Features" https://datasheets.raspberrypi.org/cm4/cm4-datasheet.pdf https://datasheets.raspberrypi.org/rpi4/raspberry-pi-4-produ...

(See my reply to parent.)

Re: Single random bit flip causes error in certificate transparency log

#253
post #78

Earlier quoted context omitted.

Strange that build services are not just going full ECC, especially with cheaper hardware now supporting it.

Says it's a Mac/iOS build platform. Since it's a commercial service they're probably complying with the license and thus using actual Mac hardware, and in turn the only ECC option is the really awful value, outdated Mac Pro. Seems more likely they're using Minis instead, or at least mostly Minis. An unfortunate thing about Apple hardware (says someone still nursing along a final 5,1 Mac Pro for a last few weeks).

Aha! I had totally forgotten about that. Solid point, thank you.

Re: Single random bit flip causes error in certificate transparency log

#254
post #243

Earlier quoted context omitted.

Failing to account for bit flips and HW failure is too common in web/service coding. Lookup how Google dropped a massive Big Table instance in prod, and traced it back to a cosmic ray bit flip that made a WRITE instruction into a DROP TABLE instruction. I laugh when I compare my day to day coding to that of an avionics programmer in the aero industry.

I couldn't find it. Do you have a reference?

There are some examples here [1]. Dig as I may, I cannot locate the original Google source I read about this ~3y ago.

1. https://www.usenix.org/system/files/conference/atc12/atc12-f...

Re: Single random bit flip causes error in certificate transparency log

#255
post #71

Earlier quoted context omitted.

One of the issues with putting servers in orbit is cooling; you can't just use fans in space. On the other hand, real estate is pretty cheap. Servicing is hard, though, and micrometeorites are another risk. Plus launch costs being high, and radiation an issue, I don't see it happening any time soon outside of very specific areas.

Forget cooling for a minute. Cooling dissipates energy but you need to collect the energy first and worry about powering the server. It’s going to be a solar-plus-battery system, which is heavy and expensive, with substantial launch costs.

Not sure you need a big battery when you have almost 24/7 sunlight, depending on the altitude. Of course, latency is another issue.

Re: Single random bit flip causes error in certificate transparency log

#256
post #122

Earlier quoted context omitted.

I've always wondered about that. Seems to me that if you can shield one side from the sun's heat and expose the other side to the cold of space, an MRI magnet's superconductors should be quite happy with the temperature. A big ol' magnet would be a pain to charge up once, and then provide long-term shielding.

MRIs are big electromagnets and they use big power and produce big heat. In space you have no convection so you must radiate away all of your heat which is challenging. Maybe you can make something better with superconductors that doesn't use much power, but I don't think it exists yet.

Um, what?

The magnet in an MRI is a superconducting electromagnet. It needs power once, to charge it up, then you close the loop and it just sits there being a superconducting electromagnet. The only power used continuously is for cooling, which is to say, when ambient room heat leaks in, it has to be carried out again. The magnet itself does not produce heat; it has no electrical resistance because it is a superconductor.

Re: Single random bit flip causes error in certificate transparency log

#257
post #49

Earlier quoted context omitted.

I’ve had a case where a bit flip in a TCP stream was not caught because it happened in a Singapore government deep packet inspection snoop gateway that recalculated the TCP checksum for the bit-flipped segment: https://blog.majid.info/telco-snooping/

Sorry if this is obvious, but how do we know this isn't due to something more "innocent" like fragmentation?

Fragmentation doesn’t change the TCP checksum. The packet is reassembled and the original checksum verified against the rehydrated packet and TCP segment.

Re: Single random bit flip causes error in certificate transparency log

#258
post #49

Earlier quoted context omitted.

I’ve had a case where a bit flip in a TCP stream was not caught because it happened in a Singapore government deep packet inspection snoop gateway that recalculated the TCP checksum for the bit-flipped segment: https://blog.majid.info/telco-snooping/

Nice article, enjoyed it.

Thanks!
Post reply on HN