Live data from Hacker News

Putting out the hardware dumpster fire

dl.acm.org

31–40 of 115 posts

Re: Putting out the hardware dumpster fire

#31

Earlier quoted context omitted.

One common component where things are really secretive is with flash storage. This is because the underlying physical components are pretty commodified, and the software/firmware (like block virtual addressing) is where brands actually distinguish themselves. It's kind of unfortunate since there's a lot of really cool stuff you could do with more control over the hardware like reducing the size of a failing disk to e…

If I'm ever going to get on the conspiracy theory bandwagon, it will be on two topics: 1) Return to office. 2) Why we need a dedicated CPU and DRAM attached to flash memory. You can garbage collect and wear level in your OS if you want to. Manufacturers say "no, we have a super secret secret sauce that nobody else could possibly improve upon". Uh huh, sure.

> 1) Return to office.

In the spirit of unbridled conspiracy theory (i.e. I have no evidence for this and don't believe it is generally true):

Landlords are paying CxOs kickbacks to push return to office in order to prop up commercial real estate.

Re: Putting out the hardware dumpster fire

#32

Earlier quoted context omitted.

One common component where things are really secretive is with flash storage. This is because the underlying physical components are pretty commodified, and the software/firmware (like block virtual addressing) is where brands actually distinguish themselves. It's kind of unfortunate since there's a lot of really cool stuff you could do with more control over the hardware like reducing the size of a failing disk to e…

If I'm ever going to get on the conspiracy theory bandwagon, it will be on two topics: 1) Return to office. 2) Why we need a dedicated CPU and DRAM attached to flash memory. You can garbage collect and wear level in your OS if you want to. Manufacturers say "no, we have a super secret secret sauce that nobody else could possibly improve upon". Uh huh, sure.

(1) is really simple, managers want to lower the effort for themselves to interrupting people with sudden meetings

Re: Putting out the hardware dumpster fire

#33

Earlier quoted context omitted.

Most electrical components have traditionally had open datasheets. It is only a relatively recent phenomenon that mass market ICs are locked behind NDAs.

It really depends on the complexity. Sure, 555 timers and even microcontrollers have datasheets. CPUs that run Linux, Wifi chips supporting recent standards, etc.? Rare. This is why Linux in the 90s was a big pain; you get some random Ethernet chip and there is no documentation on how to talk to it, so you're just dead in the water. (I think Android was the turning point. From then on, stuff had to support Linux, bec…

> But cheaper than testing it yourself.

It always felt like, IMO, that we end up testing it ourselves anyways. Obviously we don't go through the whole spec, but like you, we implement what we need and find the relevant bugs/errata ourselves. It's very painful to run across these and I don't recall an MCU that doesn't have at least one that we run into and have to workaround because development is already deep enough that we're economically locked it and it wouldn't be worth the rework to switch to a different MCU. Sometimes the bugs are in the silicon, sometimes they're in the middleware, but both are very painful to root-cause.

Re: Putting out the hardware dumpster fire

#34

Earlier quoted context omitted.

Most electrical components have traditionally had open datasheets. It is only a relatively recent phenomenon that mass market ICs are locked behind NDAs.

i only hit NDA on secure element chips and similar things. 99% of my embedding work is plain ol mcus w reams of datasheets available. i do not do pc stuff tho

That is my experience, for NDA, Atmel wouldn’t let you see a datasheet without it.

But, I’m starting to see fairly typical data sheets for micros being hidden away behind portals.

Re: Putting out the hardware dumpster fire

#35

Earlier quoted context omitted.

One common component where things are really secretive is with flash storage. This is because the underlying physical components are pretty commodified, and the software/firmware (like block virtual addressing) is where brands actually distinguish themselves. It's kind of unfortunate since there's a lot of really cool stuff you could do with more control over the hardware like reducing the size of a failing disk to e…

If I'm ever going to get on the conspiracy theory bandwagon, it will be on two topics: 1) Return to office. 2) Why we need a dedicated CPU and DRAM attached to flash memory. You can garbage collect and wear level in your OS if you want to. Manufacturers say "no, we have a super secret secret sauce that nobody else could possibly improve upon". Uh huh, sure.

I think NAND controllers are fine. If erase is slow, especially at lower voltage levels, then buffer away. I also think internal controllers help mask and work around shitty yields on the arrays.

Re: Putting out the hardware dumpster fire

#36
post #14

I think one of the primary reasons that it is such a dumpster fire is there traditionally hasn't been an "open" ecosystem in the hardware world, though now they are being forced towards that direction kicking and screaming. Every part of the hardware ecosystem has traditionally been done in closed, NDA ridden environments and only over the last 5-10 years has that even started to change. Designing chips has required…

We're aiming to push things in the other direction with OpenTitan: https://github.com/lowRISC/opentitan/

It's an Open Silicon root of trust, all RTL (the actual hardware design in SystemVerilog), firmware, documentation and verification environment is open source and in the repository I just linked.

We're closing in on our first discrete chip (details here https://opensource.googleblog.com/2023/06/opentitan-rtl-free... and https://lowrisc.org/blog/2023/06/opentitans-rtl-freeze-lever...) and have lots more in the pipeline (our project director Dom Rizzo gave a keynote at the Barcelona RISC-V Europe summit recently with some details, sadly not available on video yet).

The hope is this will be a real proof point of the value of open source in hardware and, if as successful as we like it to be, can push the industry from a closed by default to people having to justify why they're not using open technology.

Re: Putting out the hardware dumpster fire

#37

I've noticed the trend of ever-increasingly complex hardware with little or no change in performance since the 90s, and ranted about it extensively since I joined HN. I think we're past considering the problem from a technical perspective and need to look at the conspiratorial forces involved. To me, the problem is one of monopoly and corporate thinking. When Intel and AMD make most of the chips, we end up with a Cok…

What do you mean "little or no change in performance since the 90s"? Computers now are hundreds if not thousands of times faster than in the 90s.

Also, if anything, modern desktop hardware is so complex not because of centralization, but because of decentralization. If your computer was made by a single manufacturer, that manufacturer could optimize the final product as much as it wanted, because it'd have control not only of each component, but of the communication between each pair of components. It'd only need to make sure that the programming interface remained the same, so that the software could still function. Because different companies make your CPU, your motherboard, your storage, your memory, etc. and they all have to agree on some protocol so the parts can talk to each other, each manufacturer focuses their optimization efforts on the part that they manufacture, irrespective of what the rest of the system is doing. That's how you get SSDs running garbage collectors, GPUs with little operating systems, motherboards with little operating systems, etc.

Re: Putting out the hardware dumpster fire

#38
post #14

I think one of the primary reasons that it is such a dumpster fire is there traditionally hasn't been an "open" ecosystem in the hardware world, though now they are being forced towards that direction kicking and screaming. Every part of the hardware ecosystem has traditionally been done in closed, NDA ridden environments and only over the last 5-10 years has that even started to change. Designing chips has required…

Having ran my own internal hw/warranty service for many years hw management is a skill, there are a lot of traces and if you have a cold joint, zinc whiskers, etc it can wreak havoc and diagnostic skills are imperative.

Diagnosis is much more important than open, as to truly diagnose with open will require EE level skills and time which is not free.

Re: Putting out the hardware dumpster fire

#39

I like the boldness of the title and the simple clarity of the writing. Academic papers are frustrating to me in that they seem to use esoteric language in order to create a veneer of importance, sometimes above trivial real content. This stands against that trend and harkens back to papers of old.

> they seem to use esoteric language in order to create a veneer of importance,

It's kind of true, but also I think the real answer is that you're not the target audience.

A lot of time you use esoteric language because part of the problem being solved for in these conversations are:

1. what are useful and meaningful abstractions?

2. which abstractions are seeing uptake?

3. Who gets credit for the abstraction?

This mean papers are very often introducing new terminology as part of an exploratory conversation. Communication is optimized for the people engaging in that process.

As time passes most of these terms fall into disuse and the field circles around a few winners which then pass into the wider world. This stage is much more approachable and this content is what most of us are used to consuming.

Re: Putting out the hardware dumpster fire

#40
post #30

I'm not sure what fire has been put out here. IMO, a more convincing proof for the usefulness of this approach would be that it allows to find whole new classes of exploitable vulnerabilities that can then be corrected ahead. That's how static code analysis tools typically demonstrate their value. Without such proof, the description that they make of a hardware platform is mentally interesting but not clearly useful.

I think there’s potential for a second-order effect here: generate enough vulnerabilities and SoC designers will start to put it out themselves.
Post reply on HN