
Minifree Server Motherboard Supporting Libreboot - ThatGeoGuy
http://minifree.org/product/libreboot-d16/
======
yuhong
BTW, I emailed rms@gnu.org about microcode updates and the only reply was a
pointer to [http://gnu.org/philosophy/free-hardware-
designs.html](http://gnu.org/philosophy/free-hardware-designs.html).

------
jdub
So... it's just one of these [1] with the firmware pre-flashed?

[https://www.asus.com/Commercial-Servers-
Workstations/KGPED16...](https://www.asus.com/Commercial-Servers-
Workstations/KGPED16/)

------
Nexxxeh
Cool, although vastly out of budget for me.

>is ideal for setting up a custered (and libre!) super computing environment.

I'm assuming they mean "clustered", as opposed to the dessert topping or the
General.

------
nickpsecurity
As usual, any claim that this will resist High Strength Attackers like NSA is
BS until proven otherwise. I recently put two links here showing what that
takes:

[https://news.ycombinator.com/item?id=10529676](https://news.ycombinator.com/item?id=10529676)

On topic of FOSS boards, it sounds like a good idea given the principles of
incremental progress toward one's goals and getting there by investing. The
hardware would certainly be usable and very hacker-friendly. Both usages of
the term. ;)

Hope it gets released and delivers on its promises. Step in right direction.

~~~
chei0aiV
Any thoughts on lowRISC?

[http://www.lowrisc.org/](http://www.lowrisc.org/)

~~~
nickpsecurity
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_...](https://www.schneier.com/blog/archives/2013/12/friday_squid_bl_404.html#c2902272)

