Minifree Server Motherboard Supporting Libreboot

Tagged memory: ranges from stopping/detecting specific kinds of failures to enforcing complex policies. Might benefit but highly implementation-specific issues means I have to delay analysis.

Minion helper cores are both interesting and what has me most concerned: about everything like that fails in the marketplace. Kilocore, Cell, and most coarse-grained parallel chips come to mind. One or more simple processors for I/O is a great idea that I've pushed since I learned about mainframes' Channel I/O (see Wikipedia). It's also important given that the security and verification models are often different for regular computation and I/O. Splitting them into CPU's customized for them is better. Additionally, one can put accelerators in that are relevant for that kind of work. Compute cores might have SIMD/MIMD instructions while I/O cores support checksums or TCP/IP processing. Both could have crypto.

Scratchpad is good. I pushed it in embedded because it's easier to implement than cache and you can control it. That makes both real-time and security issues easier to handle. However, it doesn't manage itself. So, my suggestion was compiler support that automatically handled scratchpads like caches for the general case. That can be replaced with custom direction for scratchpads if necessary.

The security features they list indicate they've at least done their research: all good features. The slides show tagged memory, secure boot, crypto accelerators, encrypted off-chip memory (need authenticated too), isolated execution (vague), and virtaulization (can be pretty secure). I'd throw in a TRNG, too. Anyway, these are all a good start to securing a SOS. They might also want to add asynchronous execution support, partitioned caches, and high-speed clearing of memory spaces to deal with covert channel issues. Good list, though.

My knowledge of ASIC's has grown by leaps and bounds but I'm still not a real HW guy. So, I might be way off thinking that going from two components in FPGA to 28nm/40nm ASIC in 6 months might be too challenging. Of course, it could be done if they're keeping that SOC minimal.

I just don't want to talk much more about the security aspects of lowRISC for now. One of the people involved asked for a review here on HN and I didn't respond due to being swamped with stuff. There's a lot of good work around RISC-V in general right now with Rocket CPU being truly exciting. They're also in exploratory phase. So, I want to delay a real assessment until I have time to truly review what they're doing. Just to be fair.

I do like how they had a good feature list (security, not Minions) and cited relevant work from the past. Knowing what's been done before is a rare, good sign. I'm keeping them in my peripherals for now. ;)

Note: If you want to see the field's many angles, there's a link below to all kinds of work (including CPU-oriented) that I dumped in response to Schneier's call for technical solutions to NSA surveillance. Mine mostly focused on endpoints, from hardware to privileged software, as that's where I figured attacks would be. Was confirmed shortly... Anyway, lots of good stuff in those papers.

https://www.schneier.com/blog/archives/2013/12/friday_squid_...