Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Putting out the hardware dumpster fire

dl.acm.org

Post reply on HN
Print view View original

51–60 of 115 posts

Re: Putting out the hardware dumpster fire

#51

Post by tiffanyg »

gchadwick wrote: post #36
jpleger wrote: 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.…

I like this approach, speaking from a very general perspective (very uneducated regarding hardware, comparatively). Absolutely brings back memories of the 90s and arguments regarding open vs closed source and "security through obscurity".

Security through obscurity doesn't work, ultimately. When economic stakes are / were lower, it CAN have benefits. At this point, I suspect it's likely that more eyes and openness is better.

That said, I do think that the best solution is likely to be based in a mixture of approaches, much as has been pursued (to my knowledge) and developed over time already. However, personally, I'm a big fan of "formal methods" and seeing more real-world deployment of such methods.

In practice, as has been done that I've seen, you start with small & critical subsystems, trying to design for "parsimony" - making formal methods and everything else more realistic / practical (e.g., "microkernels", everyone's favorite 'solution' since the 80s, at least). But, it's all very challenging because then it has to be balanced against performance, cost, etc.

Not sure this comment adds much, here - again, not an area I have much direct knowledge or experience in - but, your comment did bring some analogous areas and work I'm more familiar with to mind.

Re: Putting out the hardware dumpster fire

#52

Post by hlandau »

gchadwick wrote: post #36
jpleger wrote: 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.…

Can you explain how the root of trust is configured? Is it efuses or some sort of onboard mutable nonvolatile storage? If I buy a system with one of these chips in, am I likely to be able to set my own root of trust, or will the OEM have irreversibly set the root of trust to their own key?

Re: Putting out the hardware dumpster fire

#53

Post by [deleted] »

derefr wrote: post #45
topspin wrote: post #26

Earlier quoted context omitted.

> or even kernel daemons run on the efficiency cores When (not if) the kernel scheduler locks up while the fans are slow/stopped at the same moment some scheduled user process begins driving 250W+ through a CPU the isolated fan controller (not to mention isolated thermal throttling logic, also independent of the OS) has great value. > If this doesn’t happen—why doesn’t it? Hardware evolves faster than operating syste…

You don’t seem to be paying attention to the words “vertically integrated” in my question — which were the whole point of my question. Apple creates both the OS and the hardware for their phones. So why shouldn’t the hardware microcontroller firmware for the hardware they create (or commission and constrain the design of), run as one or several RTOS blobs that ship as part of the OS on one or several shared MCUs? Let…

[deleted]

Re: Putting out the hardware dumpster fire

#54

Post by userbinator »

jrockway wrote: post #27
kevin_thibedeau wrote: post #17

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…

CPUs that run Linux, Wifi chips supporting recent standards, etc.? Rare.

Intel was relatively open with its documentation (including reference schematics -- I think you can still find the 440BX ones on their site somewhere) until around the end of the P4 era, so that covers "CPUs that run Linux". As for the wireless stuff, I suspect a lot of that has to do with regulatory issues.

Re: Putting out the hardware dumpster fire

#55

Post by userbinator »

slaymaker1907 wrote: post #23
sitzkrieg wrote: post #20

Earlier quoted context omitted.

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

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…

IMHO the secrecy is more because they don't want people realising how incredibly unreliable NAND flash is becoming. 20 years of retention after 1M cycles? Advertise that proudly to everyone. 10 years after 100K cycles? Not too bad. 5 years after 10K cycles? OK. 3 months after 1K cycles? No, don't tell anyone. The very few leaked TLC/QLC flash datasheets out there don't even have any clear endurance numbers anymore.

Re: Putting out the hardware dumpster fire

#56

Post by AnthonyMouse »

jrockway wrote: post #28
slaymaker1907 wrote: post #23

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.

> 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.

The thing I don't get is, the chips are all commodities, and it's not like soldering them to a board is rocket science. Why isn't one of the companies that makes fully-specified inexpensive RISC-V chips selling one attached to some commodity flash chips and an NVMe connector? Include some minimalist open source firmware that offloads most of the work to the host OS and let the Linux community figure out how to make it better.

At minimum it should allow you to undercut the existing competition on price because you're using a less expensive controller and no DRAM, and in a few years the open source drivers could have enough advantages over black box devices that nobody wants to buy anything else.

Re: Putting out the hardware dumpster fire

#57

Post by haskellandchill »

"A key result of this work as applied to existing hardware will be whether it is possible to assign less-than-complete trust to any of the black-box components in an SoC, or whether current HW design practices are incompatible with building secure, correct systems."

Having been exploring this research area for a while I fear it is the latter and there is no clean formal model that will apply to real hardware as currently construed.

Re: Putting out the hardware dumpster fire

#58

Post by AnthonyMouse »

stavros wrote: post #19
jpleger wrote: 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…

What forces them toward an open ecosystem?

Customer demand. If you're Google or AWS or any sufficiently large customer and the black box firmware is getting in your way, you have the resources to roll your own. Then the incumbents not only lose their business, they face the prospect of new competition when that company publishes the documentation and firmware because they're more interested in commodifying their complement and getting bug reports on what they're now using internally than in competing in that commodity market.

Then from the other end, RISC-V is starting to get good enough that relatively small companies can put the pieces together into useful open products that compete with closed incumbents.

The hardware vendors are better off to get in front of it and publish the same for their own hardware so they can gain some market share in the time before everybody is doing it.

Re: Putting out the hardware dumpster fire

#59

Post by stavros »

AnthonyMouse wrote: post #58
stavros wrote: post #19

Earlier quoted context omitted.

What forces them toward an open ecosystem?

Customer demand. If you're Google or AWS or any sufficiently large customer and the black box firmware is getting in your way, you have the resources to roll your own. Then the incumbents not only lose their business, they face the prospect of new competition when that company publishes the documentation and firmware because they're more interested in commodifying their complement and getting bug reports on what they…

That's interesting, thanks!

Re: Putting out the hardware dumpster fire

#60

Post by dezgeg »

AnthonyMouse wrote: post #56
jrockway wrote: post #28

Earlier quoted context omitted.

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.

> 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. The thing I don't get is, the chips are all commodities, and it's not like soldering them to a board is rocket science. Why isn't one of the companies that makes fully-specified inexpensive RISC-V chips selling one attached to some commodity flash chips and an NVMe connector? Include some…

For starters, I doubt that acting as a NVMe device is something you can do with a off the self "inexpensive RISC-V" with any kind of acceptable performance. A NVME engine would almost certainly be something that the flash controller would have implemented in fixed function hardware.

Also NAND flash practically requires some sort of error correction system - another thing that fixed function logic in a custom ASIC is very well suited for. Using CPU time on the host CPU for that would probably suck.

Post reply on HN