4 ms·

Interesting talk but I'm not convinced of the value proposition of "rediscovering hardware". The speaker points out that there are lots of small processors insi

by evilos 5y ago

Interesting talk but I'm not convinced of the value proposition of "rediscovering hardware". The speaker points out that there are lots of small processors inside a modern SoC that are often running their own software hidden from Linux. I agree that there are security implications here a la Qualcomm Hexagon vulnerabilities or Intel Management Engine backdoors but I'm not sure what the speaker's proposed alternative is. Is it that a "true" OS would directly execute the duties of these hidden processors? This is extra work that would make systems slower. Having dedicated hardware handle these duties is an optimization (hardware acceleration). Alternatively you could replace these small processors with fixed function hardware. This would make any system flaws permanent although it would be much harder to exploit any vulnerabilities. Does the lack of hidden processors make the system "better" somehow? (aside from potentially more secure) Are bus masters and hardware accelerators part of the OS? It would certainly be a more beautiful system that I would love to see, but I need help justifying the engineering cost. I hope to see some open hardware passion projects along these lines, but I doubt they will ever be mainstream.

SilverRed 5y ago
I'm increasingly seeing the value of Apple style products where almost every part of the device from the hardware, to firmware, to OS, to UI is all from the same company. The whole combined experience just makes things run so smoothly and allows security issues to be patched since Apple has the resources that maintain each part internally.
- pas 5y ago
  Yeah, of course that works, for a while at least. Also developed in the open, patches are welcome, you can update your own NIC/GPU/Wifi-dongle components would work too. Unfortunately the whole industry (Apple as one of the main culprits) is quite hostile to anything like that. Though maybe we'll have a RedHat of hardware someday.
- darkwater 5y ago
  Yeah, and as a side-effect you have to obey your one true lord.
  - foxpurple 5y ago
    Vs relying on 100 chip vendors who do not give two shits about you once the product is out the door.
elcritch 5y ago
More likely its that a "full" OS would at least be be aware of the heterogeneous elements. Then it could provide api's for negotiation between them, if not directly providing a method to run them. One method could be, say, extending microkernel capability systems to incorporate these remote processors. Or perhaps even the ability to provide WASM or ePBF control blocks to customize the power management system. Though its true that'd require more engineering resources. Actually USB is somewhat like this in that there's a hardware api and spec that the OS knows about. Linux has troubles with even that in my experience (often requiring a reboot to fix.
- pas 5y ago
  Most of these components already provide all their functionality over SPI, I2C, PCI or whatever. Maybe, instead of opening up all that complexity, simply making better ways to fake a dumb component would be more effective. (That is with verified, memory safe parsers and API interfaces. Then it doesn't matter what other gunk it has behind that interface.) And this could be implemented as yet another managed layer between the main CPU that runs user space and the hardware SoC. (Basically a low-level "WAF".) Yeah, it's a herculean task, but at least we have access to the Linux drivers.
taneliv 5y ago
I think the "speaker's proposed alternative" is to do more academic research in this area. You have good questions in your comment, and I think he is calling out for searching answers to them and other similar questions. Apparently, the operating system researchers haven't been doing this enough, or at all. His speech is a lament for this state of affairs, and a call to get excited about finding out what benefits would be gained by doing things (very) differently. But that's just my take, and I'm not working on operating systems research.
- evilos 5y ago
  I guess I'm struggling to understand what the problem to solve here is (besides security bugs). Maybe that is wrong, and the idea is just to try new things. But seems to me that 'try new things' isn't a particularly strong call to action when you are competing for research funds/time.
  - jyounker 5y ago
    > Maybe that is wrong, and the idea is just to try new things. That's what basic research does. It discovers new things, and new ways of doing things.
  - pdimitar 5y ago
    Addressing potential dozens of firmware level of security exploits is no small thing by itself.
alexisread 5y ago
Actually there are a few bright spots on the horizon. RISC-V is gaining mindshare, and I've seen separate events/papers which push for using modified RISC-V cores as specialised processors, similar to eg. The Nintendo64 which used MIPS cores. If that gains traction then there's a good chance that the software will improve. On the radio side of things, Dash7 firmware will run on many Lora devices, meaning you don't have to use the proprietary Lora software.
jart 5y ago
Pffftttt "hardware acceleration" of features we literally never wanted. We don't even have the freedom to buy computers that aren't "enriched" with this junk.
jdefr89 5y ago
This.. This is exactly what I was thinking. Well put. The complexity it would add the Linux kernel code base would probably, inadvertently, create more security issues. The more code, the larger the attack scope. In general, as a security researcher, I would tell people to let hardware do most of the lifting when possible as software being involved usually means introducing a higher probability of bugs/vulnerabilities.
Const-me 5y ago
> Is it that a "true" OS would directly execute the duties of these hidden processors? I think a “true” OS would run its code on all these processors, implementing both sides of the communication protocols connecting these pieces of hardware into a computer. For one, such hypothetical OS may upgrade or replace these communication protocols with OS updates, or because user changed some system preferences. This also allows to re-configure these things based on runtime information. For instance, when AC power is disconnected from a battery-powered device, it makes sense to do stuff slightly differently, like stop all processes on all CPUs who are polling to get events faster, and switch to slower but energy efficient interrupts.

by evilos 5y ago

SilverRed 5y ago

I'm increasingly seeing the value of Apple style products where almost every part of the device from the hardware, to firmware, to OS, to UI is all from the same company. The whole combined experience just makes things run so smoothly and allows security issues to be patched since Apple has the resources that maintain each part internally.

pas 5y ago
Yeah, of course that works, for a while at least. Also developed in the open, patches are welcome, you can update your own NIC/GPU/Wifi-dongle components would work too. Unfortunately the whole industry (Apple as one of the main culprits) is quite hostile to anything like that. Though maybe we'll have a RedHat of hardware someday.
darkwater 5y ago
Yeah, and as a side-effect you have to obey your one true lord.
- foxpurple 5y ago
  Vs relying on 100 chip vendors who do not give two shits about you once the product is out the door.

elcritch 5y ago

More likely its that a "full" OS would at least be be aware of the heterogeneous elements. Then it could provide api's for negotiation between them, if not directly providing a method to run them. One method could be, say, extending microkernel capability systems to incorporate these remote processors. Or perhaps even the ability to provide WASM or ePBF control blocks to customize the power management system. Though its true that'd require more engineering resources. Actually USB is somewhat like this in that there's a hardware api and spec that the OS knows about. Linux has troubles with even that in my experience (often requiring a reboot to fix.

pas 5y ago
Most of these components already provide all their functionality over SPI, I2C, PCI or whatever. Maybe, instead of opening up all that complexity, simply making better ways to fake a dumb component would be more effective. (That is with verified, memory safe parsers and API interfaces. Then it doesn't matter what other gunk it has behind that interface.) And this could be implemented as yet another managed layer between the main CPU that runs user space and the hardware SoC. (Basically a low-level "WAF".) Yeah, it's a herculean task, but at least we have access to the Linux drivers.

taneliv 5y ago

I think the "speaker's proposed alternative" is to do more academic research in this area. You have good questions in your comment, and I think he is calling out for searching answers to them and other similar questions. Apparently, the operating system researchers haven't been doing this enough, or at all. His speech is a lament for this state of affairs, and a call to get excited about finding out what benefits would be gained by doing things (very) differently. But that's just my take, and I'm not working on operating systems research.

evilos 5y ago
I guess I'm struggling to understand what the problem to solve here is (besides security bugs). Maybe that is wrong, and the idea is just to try new things. But seems to me that 'try new things' isn't a particularly strong call to action when you are competing for research funds/time.
- jyounker 5y ago
  > Maybe that is wrong, and the idea is just to try new things. That's what basic research does. It discovers new things, and new ways of doing things.
- pdimitar 5y ago
  Addressing potential dozens of firmware level of security exploits is no small thing by itself.

alexisread 5y ago

Actually there are a few bright spots on the horizon. RISC-V is gaining mindshare, and I've seen separate events/papers which push for using modified RISC-V cores as specialised processors, similar to eg. The Nintendo64 which used MIPS cores. If that gains traction then there's a good chance that the software will improve. On the radio side of things, Dash7 firmware will run on many Lora devices, meaning you don't have to use the proprietary Lora software.

jart 5y ago

Pffftttt "hardware acceleration" of features we literally never wanted. We don't even have the freedom to buy computers that aren't "enriched" with this junk.

jdefr89 5y ago

This.. This is exactly what I was thinking. Well put. The complexity it would add the Linux kernel code base would probably, inadvertently, create more security issues. The more code, the larger the attack scope. In general, as a security researcher, I would tell people to let hardware do most of the lifting when possible as software being involved usually means introducing a higher probability of bugs/vulnerabilities.

Const-me 5y ago

> Is it that a "true" OS would directly execute the duties of these hidden processors? I think a “true” OS would run its code on all these processors, implementing both sides of the communication protocols connecting these pieces of hardware into a computer. For one, such hypothetical OS may upgrade or replace these communication protocols with OS updates, or because user changed some system preferences. This also allows to re-configure these things based on runtime information. For instance, when AC power is disconnected from a battery-powered device, it makes sense to do stuff slightly differently, like stop all processes on all CPUs who are polling to get events faster, and switch to slower but energy efficient interrupts.