One could do it mainframe style where the I/O was offloaded to one core with the rest doing compute. Those hundreds of thousands of interrupts never hit your single-CPU task. You can get a boost in performance even in your use-case.
I had thought of using multiple SoCs for compartmentalization, instead of VMs. Rather like a hardware version of Qubes. I was very inspired by Tinfoil Chat.[0] Using optoisolators, one could have a secure device with strictly text-only communication with other components.
But it's over my head. I lack knowledge and equipment for measuring RF leakage among SoCs. So it goes. Maybe the Qubes team will do it :)
" I was very inspired by Tinfoil Chat.[0] Using optoisolators, one could have a secure device with strictly text-only communication with other components."
Our discussions about physical and diode security on Schneier's blog were a small part of inspiration for Tinfoil Chat. Markus Ottela then showed up to discuss the design. He wisely incorporated each piece of feedback like switching from OTP to a polycipher and covert-channel mitigation at protocol level. Loved reading his regular updates he posted of the things he added. The design, not implementation, is one of the only things I'll call NSA proof for confidentiality and security but not availability. By NSA proof, I mean without TAO getting involved with really hands-on stuff.
One drawback was he didn't know system programming. So, reference implementation is in Python. People that know statically-verifiable C, Ada/SPARK, or Rust need to implement it on a minimal TCB. I'd start with a cut down OpenBSD first just because the NSA will go for 0-days in the lower layers and they have less. Make the implementation as portable on MIPS and ARM as possible so the hardware can be interchanged easily. Trimmed Linux next if drivers absolutely need it w/ Poly2 Architecture-style deletion of unnecessary code. If money comes in, implement it on a secure CPU such as CHERI w/ CHERIBSD.
That was my plan when I was talking to him. Lots of potential with TFC after it gets a proper review of protocol and implementation.
"People called the IO processor "the real OS" because they had never seen dedicated I/O processors before."
I didn't know that. That's funny as it's the confusion I'd expect where the old wisdom of I/O processors in non-server stuff was lost for a few generations. Then, the new one sees them to wonder if it's an extra core for apps, the OS, or whatever.
https://en.wikipedia.org/wiki/Channel_I/O
Even some embedded SoC's are doing this now where there's a strong core and a cheap core w/ main function and I/O split among them.