[HN Gopher] Putting out the hardware dumpster fire
___________________________________________________________________
Putting out the hardware dumpster fire
Author : peter_d_sherman
Score : 159 points
Date : 2023-06-23 13:48 UTC (9 hours ago)
(HTM) web link (dl.acm.org)
(TXT) w3m dump (dl.acm.org)
| villson wrote:
| [flagged]
| haskellandchill wrote:
| "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.
| binkHN wrote:
| From the abstract:
|
| > The immense hardware complexity of modern computers, both
| mobile phones and datacenter servers, is a seemingly endless
| source of bugs and vulnerabilities in system software.
|
| > Classical OSes cannot address this, since they only run on a
| small subset of the machine. The issue is interactions within the
| entire ensemble of firmware blobs, co-processors, and CPUs that
| we term the de facto OS. The current "whac-a-mole" approach will
| not solve this problem, nor will clean-slate redesign: it is
| simply not possible to replace some firmware components and the
| engineering effort is too great.
| [deleted]
| acuozzo wrote:
| I thought that when the Intel Management Engine implementation
| details (hidden Minix!) were released that it would only be a
| matter of time for a "Full FOSS" movement within enthusiast
| communities.
|
| I was wrong, it seems.
|
| There hasn't even been a push for an affordable 802.3ab gigabit
| ethernet card with an FPGA.
| StillBored wrote:
| Ethernet card built from a FPGA or one with an FPGA on the
| side? Because in both questions your talking about the fact
| that there are basically three companies providing FPGAs and
| none of them seem particularly interested in killing their high
| margin markets. Worse the "DPU" crowd are largely selling about
| $100 worth of compute for $3k+ because it has an attached 100G
| port.
|
| OTOH I assume the next step for the icestorm/etc folks once
| they actually have a reasonable toolchain working on the
| lattice parts is to actually find a company willing to produce
| a low cost open FPGA and write the backend bits to work with
| the toolchain.
|
| Similarly there are various open ethernet mac projects floating
| around, although AFAIK none of them actually have been fabbed
| into something a random consumer can buy.
|
| So much of this is really just the broken VC model in the US,
| no one is interested in funding stable but low margin
| businesses when they can gamble on high risk/reward ones. And
| banks won't loan people money without some kind of collateral.
| I suspect you have to look to China/etc at this point for to
| fill in the "sell a crapload with little margin" business (ex:
| lenovo). Making it sorta inevitable that they steamroll
| everyone, because if there is one truth in the tech field, its
| the guy with the most volume tends to win long term.
|
| Along those lines, the Si consolation has really been a
| negative in may aspects of the market. If one could still buy
| current generation PCIe switches for less than the price of an
| entire computer it would still be possible to find motherboards
| that have shared device bandwidths (aka a half dozen x4 m.2
| slots, or three x16 slots that aren't electrically just x4s)
| all hung off a x16 gen4/5 slot. Which is really the scam here,
| at least in my case I have a number of Gen3 parts which would
| all work great behind a single Gen4 x16 port with a switch port
| but instead I have to waste gen4 slots on gen3 devices.
| mistrial9 wrote:
| its not a democracy -- you discovered the implementation that
| is convenient to the towers of executive authority; there is no
| change just because it is more widely known, in fact, increased
| boldness in tracking activity in real-time and building
| dossiers on users for "ads" is growing, along with the
| stockpile of money available to implement that.
| zackmorris wrote:
| 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 Coke
| vs Pepsi mentality. There may be a hundred other hungry
| manufacturers, but without access to capital they'll never get
| enough traction to scale.
|
| Around 2000, FPGAs were set to go mainstream and let us design
| CPUs of our own, but Xilinx chose to keep them proprietary so
| they never evolved. It's unfortunate that the company most
| capable of thwarting the status quo is the one propping it up.
| But they were trendsetters, that's how it's going with all things
| tech now.
|
| Then Nvidia mostly monopolized the GPU industry and sent us down
| the SIMD rabbit hole. So we can process large vector buffers at
| great personal effort ..and that's about it.
|
| What I and I think a lot of people probably want is a return to
| big dumb processors. Something like a large array of RISC-V cores
| with local memories connected via content-addressable memory and
| copy-on-write that presents a symmetric, unified address space
| that can be driven with traditional desktop programming
| languages. Had a CPU like this kept up with Moore's law, we would
| have had a 10 core machine in 2000, a 1,000 core machine around
| 2010 and a 100,000 core machine today, reaching between 1 million
| and 10 million cores by 2030. Which shows just how incredibly
| slow CPUs are vs what they could be.
|
| The situation is so bad that I've all but given up on things ever
| improving. I mostly think about getting out of programming now
| and going back to living a normal life in the time I have left.
| Because the writing is on the wall: SIMD will deliver a narrowly
| conceived notion of neural network AI that's "good enough" and
| will stop all further evolution of CPUs. We'll miss out on the
| dozen or so other approaches like genetic algorithms and be
| forever separated from simple brute-force methods that "just
| work". The AI will soon be like Mrs. Davis and the vast majority
| of people will be face-down in their phones, then connected
| neurologically. The arrival of WALL-E and Idiocracy will coincide
| with the destruction of the natural world by 2100 and that will
| be that.
|
| The argument really comes down to centralized control vs
| distributed resilience and freedom. It's pretty obvious which one
| we have right now, and that it's getting worse each year. Now I
| look on each headline with growing weariness, picking up on which
| mistakes will be doubled down on, which kool-aid they want us to
| drink this time. Because without the intervention of at least one
| successful internet lottery winner, or a concerted effort by
| thousands of hobbyists, there's simple no viable path from where
| we are now to where we could be, making the vast majority of the
| work we do a waste of time in the face of the potential we might
| have had.
|
| It's hard to write anymore without sounding like a fringe lunatic
| projecting frustration on a world that is blissfully unaware that
| anything's even wrong. I'm probably wrong for doing so. Just
| another reason to probably get out of this business.
| fluoridation wrote:
| 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 _de_ centralization.
| 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.
| interroboink wrote:
| They might be referring to the fact that, eg, opening
| Microsoft Word today can take significantly longer than Word
| 2003 on Windows XP (or similar). See also Wirth's Law[1] and
| such.
|
| EDIT: though they focus on the hardware-could-be-better side,
| rather than the software-could-be-less-awful side (:
|
| There have been some good outspoken critics of how software
| bloat has canceled out (or more) modern hardware gains. Casey
| Muratori, Jonathan Blow, and Mike Acton come to mind -- they
| have some good material on the subject [2][3][4]. Some of the
| issues you mention, w.r.t. the hardware being
| discombobulated, are addressed in that first blog/video. No
| big surprise these people come from a video games background;
| video game hardware is traditionally much more tightly-bound-
| together.
|
| [1] https://en.wikipedia.org/wiki/Wirth%27s_law
|
| [2] https://caseymuratori.com/blog_0031
|
| [3] https://www.youtube.com/watch?v=pW-SOdj4Kkk
|
| [4] https://youtu.be/rX0ItVEVjHc?t=4211 (timestamp, but the
| whole talk is good)
| mitchbob wrote:
| [pdf]
| chubot wrote:
| _On an Android phone, Linux is effectively an application
| runtime._
|
| This is a good way of putting it, and it's sad
|
| Our OS is no longer open source -- they built the real one
| underneath
| [deleted]
| nightowl_games wrote:
| 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.
| dclowd9901 wrote:
| I know it's probably asking too much but I wonder what the
| world would look like if academic papers were actually fun to
| read.
|
| Brian Greene is probably considered a pariah around here but I
| really enjoyed reading his book The Elegant Universe.
| feoren wrote:
| I'm not sure. Imagine if life-critical safety documents were
| "fun to read". Or material safety data sheets. Or assembly
| instructions for heavy machinery. Or even code.
|
| All of this stuff needs to be extremely clear, precise, and
| readable by professionals. That's not the same as being "fun
| to read", and certainly not by laypeople. You can't really
| know whether an academic paper is clear, precise, and
| readable unless you're a professional in the sub-discipline
| the paper was written for.
| Hermitian909 wrote:
| > 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.
| derefr wrote:
| Are vertically-integrated SoCs (Apple Silicon, NVIDIA Tegra,
| etc.) subject to the "OS only controls part of the hardware"
| problem?
|
| I always figured that in these systems, there would be power-
| efficiency and BOM-cost pressure to "de-vendor" the SoC by
| replicating IP-core functionality with logic merged into firmware
| or a few larger service cores -- or even kernel daemons run on
| the efficiency cores of the application processor. I would expect
| e.g. the fan controllers on these systems to be a part of the
| PCH's event-loop logic, rather than its own little
| microcontroller with its own little firmware.
|
| If this doesn't happen--why doesn't it?
| topspin wrote:
| > 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 systems and has complex
| requirements of which operating systems are oblivious, and
| there is no world where device manufacturers and consumers will
| tolerate being gated on operating system evolution. These
| complications have to run somewhere so independent processing
| elements appear and grow. This pattern delivers ever crucial
| compatibility by hiding new complications from legacy operating
| system interfaces.
|
| The only path I can imagine that would change this paradigm
| requires a.) greatly increasing the reliability and security of
| operating systems to the point where they can be trusted not to
| fail and damage hardware or corrupt things and b.) generalizing
| all known _and future_ hardware and operating system interfaces
| such that hardware drivers (which, due to the more rapid
| evolution of hardware, do not enjoy the long term maintenance
| cycle of operating systems) can be highly portable, both across
| platforms and forward. Both of these requirements are "Hard"
| as in we have only begun to achieve this in primordial ways.
| derefr wrote:
| 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 me put it this way: in x86, the motherboard has a power
| controller, but the CPU also has its _own_ power controller.
| But on a vertically-integrated SoC system, I would expect
| there to be only one power controller, that controls power
| for the CPU, the other cores on the SoC die, _and_ the
| various other components on the logic board. And I would
| expect that power controller, whether standalone or
| integrated into the CPU, to be running first-party code
| written by the system integrator (who is also the designer of
| the logic board, the SoC, the CPU _in_ the SoC, and the power
| controller itself) rather than running code written by some
| vendor who was writing it in a "this chip could be used in
| many different builds, so it must be designed defensively for
| badly-integrated systems" manner.
| [deleted]
| samtho wrote:
| One long-term project I'm planning is actually a fully open
| source desktop computing platform. While originally meant as a
| learning project, I realized a few years ago Ben Eater[0] has
| done this in a way far superior to anything I could create
| myself, so I started focusing on very basic hardware, beginning
| with power supplies. My goal ultimately is to select a processor
| that is as close to open source as possible, design a motherboard
| around it, make it fast enough to be suitable for general purpose
| uses, design a PSU, daughter boards (hot swap SATA backplane, I/O
| ports), a few PCIe x16 lanes, and ultimately a custom graphics
| card.
|
| Designing the motherboard is surprisingly easy, the way PCIe is
| setup makes routing high speed connections fairly
| straightforward, and most I/O chips are just some sort of bus
| input and the interface output. The hardest part is finding the
| ICs that actually have good documentation not locked behind an
| NDA, or have good alternatives as one of my criteria is that
| every chip I select must have a pin-for-pin drop in replacement
| available. 6gbs SATA is the hardest one to source. I suspect this
| problem only will compound if I ever get to creating a graphics
| card.
|
| [0]: https://eater.net/
| jamesmunns wrote:
| This is something I'm also working on, but using off the shelf
| hardware for now and working on the OS first[0]. I'm going for
| something lower spec and portable for now, mostly because there
| are a fair number of _relatively_ well documented RISC-V
| processors these days (the single core, 1 GHz C906 CPU inside
| the SoC probably technically counts as open source!), where it
| seems feasible to write drivers. I 'm not sure it would be a
| wonderful "full desktop" solution (it's close to the original
| Pi Zero in terms of performance), but I hope to target larger
| chips as the OS gets more mature. The i.MX8 they mention in the
| research paper is actually one of the ones I've considered,
| it's also used by the MNT Reform (definitely worth a look if
| you haven't seen it before, and are designing your own larger
| scale computer!), and the Librem 5 (which I got after many
| years of waiting, and don't have a ton of use for right now).
|
| I actually would like to eventually play around with treating
| all the "hardware bits" inside of the computer, like the wifi
| chip, graphics card, etc., more like a distributed system than
| black boxes, but this generally comes down to writing a lot of
| the firmware myself (luckily this is a hobby/research project,
| so "non viable" solutions are still on the table).
|
| The more immediate goal for me is something portable, and
| comparable to a palm pilot/blackberry in terms of performance
| and capabilities. The current hardware will likely have an
| ESP32C3 for wifi (32-bit RISC-V), the main D1 CPU (64-bit
| RISC-V), and an RP2040 (32-bit Arm Cortex-M) for keyboard and
| IO, so I'll be able to test out some of my "network of tiny
| computers that make one small computer" ideas.
|
| [0]: https://onevariable.com/blog/mnemos-moment-1/
| samtho wrote:
| I love this concept and is why my current designs are
| littered with E-keyed M.2 ports and the only real I/O is on
| my board are USB-C and a few USB-As. The advantage is that I
| can supplement built-in peripherals with USB devices until I
| build them.
| colineartheta wrote:
| Does the Talos II not fit this already?
| LoganDark wrote:
| Who wants to spend tens of thousands of dollars for _that_?
| samtho wrote:
| Right, I'm not quite sure where it fits within the market.
| It's quite pricey for pro-sumer and not enterprise-y enough
| for larger companies to buy into it.
| AnthonyMouse wrote:
| It's about the fastest system you can get if you want
| open hardware. There are people willing to pay a premium
| for that. It's obviously not going to find a mass market
| at that price.
|
| But maybe they'll make enough money to develop a lower-
| priced one that can reach more customers.
| yafbum wrote:
| 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.
| ThreeFx wrote:
| I think there's potential for a second-order effect here:
| generate enough vulnerabilities and SoC designers will start to
| put it out themselves.
| genmud wrote:
| 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 NDA-based PDKs. Designing complex
| PCBs has required closed-source EDA tools. Interacting with any
| of the IC peripherals often requires binary or non-
| redistributable firmware.
|
| Hell, even with the modern "open" switch architectures, like
| Trident3, you can't get software or detailed datasheets from
| broadcom without an NDA. Same thing with some of the ARM based
| stuff like with the Raspberry Pi.
| orbital-decay wrote:
| _> 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_
|
| Is it, though? Software thrives because it has an open
| ecosystem. But it's no less of a dumpster fire of complexity,
| being slowly buried under the technical debt. We literally have
| decades-old system designs wrapped into multiple layers of
| progressively newer systems, and openness doesn't help here.
| Most software is _write-only_.
|
| The overarching reason might be the lack of refactoring and
| feedback loops. It's more related to the production cycles and
| incentives than to the second-order effects of openness.
| kevin_thibedeau wrote:
| Most electrical components have traditionally had open
| datasheets. It is only a relatively recent phenomenon that mass
| market ICs are locked behind NDAs.
| jrockway wrote:
| 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,
| because Mobile was the future and Apple wasn't going to buy
| your chip. But of course, "works on Linux" means that it
| works in the hardware vendor's 3-year-old version of Linux.
| And "works" is always up in the air when hardware vendors
| start writing code.)
|
| When I worked on embedded devices, we would report bugs and
| the vendor would send us new datasheets with updated known
| issues; updated to include the issue we reported. Or we'd do
| something like "the datasheet says it can handle a 100MHz
| clock but it's very unreliable" and they'd send back a
| datasheet saying it only supports 50MHz. That's the reason
| that datasheets are closed, every customer gets their own
| datasheet.
|
| The more you get into higher margin stuff, be it hardware or
| software, the more you'll run into datasheets or branches
| just for you. It is weird and inefficient. But cheaper than
| testing it yourself.
| reaperman wrote:
| > 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.
| userbinator wrote:
| _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.
| genmud wrote:
| I mean, sure, for certain x86 things... like 20 years
| ago, but IIRC their host controllers were not though, and
| that isn't but a fraction of all CPUs.
|
| Think about how many billions of devices there are where
| you can't get simple a pinout diagram for the main CPU. I
| would argue only a tiny, _TINY_ , percentage of any Linux
| devices actually have CPUs/SOCs/SOMs with sufficient
| documentation to look at from a hardware design
| standpoint.
| mfuzzey wrote:
| It seems to depend on the market.
|
| For example CPUs that run Linux open reference manuals are
| still the norm in the industrial range (chips like the NXP
| i.MX series, the TI SAMA ones or the fairly new STM32MP1)
| whereas in the mobile market (Qualcomm, Exynos etc) you
| can't get any information without a NDA and they'll only
| sign one with you if you're going to be buying millions.
|
| The first category also tend to have good mainline support,
| the second stuck on ancient vendor kernels.
| sitzkrieg wrote:
| 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
| SV_BubbleTime wrote:
| 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.
| slaymaker1907 wrote:
| 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 extend its life instead of
| complex wear-leveling techniques.
| jrockway wrote:
| 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.
| AnthonyMouse wrote:
| > 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.
| dezgeg wrote:
| 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.
| CrazyStat wrote:
| > 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.
| jrockway wrote:
| Maybe. The most compelling reason I have heard is it's an
| easy way to get attrition. You don't have to do layoffs,
| which are expensive emotionally and financially.
| srcreigh wrote:
| In my city office buildings are being converted to
| residential housing. 3 buildings recently in an area of
| population size 250k.
| hoosieree wrote:
| What part of the world? I've heard that the cost of
| converting office spaces to residential is more than
| building new.
| peoplearepeople wrote:
| (1) is really simple, managers want to lower the effort
| for themselves to interrupting people with sudden
| meetings
| joezydeco wrote:
| 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.
| userbinator wrote:
| 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.
| mozman wrote:
| 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.
| stavros wrote:
| What forces them toward an open ecosystem?
| AnthonyMouse wrote:
| 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.
| stavros wrote:
| That's interesting, thanks!
| gchadwick wrote:
| 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.
| hlandau wrote:
| 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?
| tiffanyg wrote:
| 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.
| mschuster91 wrote:
| > The immense hardware complexity of modern computers, both
| mobile phones and datacenter servers, is a seemingly endless
| source of bugs and vulnerabilities in system software.
|
| I'm a bit torn here. On one side, I'd really love to have
| equipment that can be proven to be bug free in theory or in
| practice. On the other side, often enough the only thing allowing
| me as an user to actually use a computing device for things that
| have not been intended by the manufacturer - everything from
| running my own software over running pirated games to using ad
| and tracking blockers - are (serious) security bugs, or when one
| uses the manufacturer-provided options to load their own
| software, the device irrevocably bricks parts of itself like
| Samsung's Knox environment does after rooting your phone, which
| breaks a ton of stuff - most notably Netflix DRM or Google Pay.
| mikewarot wrote:
| Here's a Usenix presentation by the last author, Timothy Roscoe,
| from August, 2021 on YouTube. [1]
|
| He makes a very compelling case for greatly expanding the concept
| of an operating system into _all_ of the hardware in a given
| computing environment.
|
| [1] https://www.youtube.com/watch?v=36myc8wQhLo
| imiric wrote:
| > He makes a very compelling case for greatly expanding the
| concept of an operating system into _all_ of the hardware in a
| given computing environment.
|
| I haven't watched the presentation, and just glanced at the
| paper, but while I see how this would be an improvement, I'm
| not sure if giving operating systems all that power would be an
| absolutely good idea.
|
| While I certainly don't trust the firmware that runs on my
| devices, in most cases it's self-contained to the device
| itself. Modern operating systems are themselves a dumpster fire
| of security issues and spyware, built by corporations who
| realized they can also profit from their user's data, and they
| take advantage of that in subtle and nefarious ways. Even Linux
| distros aren't safe, and users need to be under constant
| vigilance that the software they're running isn't actively
| tracking or exfiltrating their data. These are much larger and
| widespread threats than any ones caused by firmware.
|
| I think the solution must involve a radical simplification of
| hardware, and a migration towards open source platforms. RISC-V
| looks very promising in this regard, and, coupled with a
| reasonably secure OS, is the best path towards safer computing.
| ForOldHack wrote:
| "Dumpster fire?" You are too kind. It's a cesspool, and a
| leaky one a that. Mostly Microsoft fault, and it has been now
| known to be getting worse.
| mikewarot wrote:
| >Mostly Microsoft fault,
|
| It's the lack of capability based security, and a common
| tragic misunderstanding of what it is, that is the root
| cause of this dumpster fire. This effects _all operating
| systems in common use_ , including all versions of Linux,
| Mac OS, Windows, etc.
|
| Imagine if your only choice to buy an ice cream cone was to
| give the other person full access to your checking account,
| _forever_. That 's what phones do, and as a result, we've
| learned to call that a "capability"
|
| Imagine taking out a $5 and handing it over to pay for that
| ice cream... the most you can lose, ever, is $5. That is
| what capability based security does. You interactively
| chose what side effects you'll allow (by picking bills out
| of your wallet), at the time of purchase.
|
| For desktop apps, like an office suite, all you have to do
| to port code over is change the calls to file selection
| dialogs (which return a list of file names) to "powerbox"
| calls (which return handles), then use those handles
| instead of directly opening the files. The user doesn't see
| any difference in behavior, but they are now firmly in
| control of things, instead of your program.
___________________________________________________________________
(page generated 2023-06-23 23:00 UTC)