4 ms·

Minifree Server Motherboard Supporting Libreboot

19 points by ThatGeoGuy 11y ago

jdub 11y ago
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...
nickpsecurity 11y ago
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 11y ago
  Any thoughts on lowRISC? http://www.lowrisc.org/ http://www.lowrisc.org/
  - nickpsecurity 11y ago
    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_bl_404.html#c2902272 https://www.schneier.com/blog/archives/2013/12/friday_squid_...
yuhong 11y ago
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.
Nexxxeh 11y ago
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.

19 points by ThatGeoGuy 11y ago

jdub 11y ago

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...

nickpsecurity 11y ago

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 11y ago
Any thoughts on lowRISC? http://www.lowrisc.org/ http://www.lowrisc.org/
- nickpsecurity 11y ago
  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_bl_404.html#c2902272 https://www.schneier.com/blog/archives/2013/12/friday_squid_...

yuhong 11y ago

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.

Nexxxeh 11y ago

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.