Re: [Cerowrt-devel] dnsmasq CVEs

[dpreed <dpreed@reed.com>]

[-- Attachment #1: Type: text/plain, Size: 5072 bytes --]

  
  
Interesting. If stack pops zeroed memory, a stack machine would fix the subroutine call privilege drop issue. Also register zeroing on syscall return avoids privilege leaks. Linux on Intel 64 doesn't do this :-(
  

  
The mill is very interesting.   
  

  
One concern, I have recently realized that it is not fully open like RISC-V. I don't blame its    developers for wanting a ROI. But adoption may require rethinking that choice. These days, shared standardized infrastructure tends to require open adoptability.
  
  

  
  
  
  
  
>   
> On Oct 7, 2017 at 4:28 PM,  <Dave Taht>  wrote:
>   
>   
>  I misstated something, fix below. On Sat, Oct 7, 2017 at 11:32 AM, Dave Taht wrote:  >  On Sat, Oct 7, 2017 at 6:33 AM, dpreed wrote:  >>  No disagreement here. I saw a wonderful discussion recently by a researcher  >>  at Mentor Graphics about 2 things: VLSI design hacking and low level  >>  interconnect hacking. Things we call "hardware" and just assume are designed  >>  securely. Was this filmed, btw?  >>  They are not. The hardware designers at the chip and board level know little  >>  or nothing about security techniques. They don't work with systems people  >>  who build with their hardware to limit undefined or covert behaviors.  >>   >>  Systems people in turn make unreasonable and often wrong assumptions about  >>  what is hard about hardware. Assumptions about what it won't do, in  >>  particular.  >>   >>  We need to treat hardware like we treat software. Full of bugs, easily  >>  compromised. There are approaches to reliability and security that we know,  >>  that are tractable. But to apply them we need to drop the fictional idea  >>  that hardware is hard... It's soft.  >   >  hardware design tools and software seem stuck in the 80s.  >   >>  The principle of least privilege is one of those.  >   >  Everybody here probably knows by now how much I am a mill cpu fan.  >   >  The principle of least privs, on a mill, can apply to individual subroutines.  >   >  The talk (it's up at [0], but because it has to cover so much prior  >  material doesn't really get rolling till slide 30) highlighted how  >  they do secure IPC, and transfer memory access privs around, cheaply.  >   >  One thing I hadn't realized was that the belt concept[1] resulted in  >  having no register "rubble" left over from making a normal... or! IPC  >  call that changed privs. Say you have a belt with values like:  >   >  3|4|2|1|5|6|7|8  >   >  a subroutine call, with arguments  >   >  jsr somewhere,b1,b4,b3  >   >  creates a new belt (so the called routine sees no other registers from  >  the caller)  >   >  4,5,1,X,X,X,X,X # (the mill has a concept of "not a value, or NAR")  >   >  On a return, the same idea applies, where the return values are dropped  >  at the head of the callee's belt. head of the callers belt, I meant.  >  callee does some work:  >   >  8|1|2|3|6|2|7|1  >  ...  >  retn b1,b5  >   >  Which drops those two values only on the callers belt, and discards  >  everything else. SSA, everywhere.  >   >  callee belt becomes: caller belt becomes  >   >  1|2|3|4|2|1|5|6  >   >  This makes peer to peer based secure IPC (Where normally you'd have a  >  priv escalation call like syscall, or attempt sandboxing) a snap,  >  instead of making a jsr, you make a "portal" call, which also ets up  >  memory perms, etc.  >   >  Me trying to explain here how they handle priv (de)escalation  >  (switching between "turfs" and so on) is way beyond the scope of what  >  I could write here, let me just say their work is computer  >  architecture Pr0n of the highest order, and I've lost many, many  >  weekends to grokking it all. [2].  >   >>  The end to end argument  >>  should be applied to bus protocols like CAN, for the same reason.  >   >  Too late!  >   >  [0] https://millcomputing.com/docs/inter-process-communication/  >  [1] https://en.wikipedia.org/wiki/Belt_machine  >  [2] https://millcomputing.com/docs/  >   >>   >>  On Oct 4, 2017 at 12:38 PM, wrote:  >>   >>  well, I still think the system is rotten to its (cpu) cores and much  >>  better hardware support for security is needed to start from in order  >>  to have better software. Multics pioneered a few things in that  >>  department as I recall, but research mostly died in the 90s...  >>   >>  Blatant Plug: The mill cpu folk are giving a talk about how they do  >>  secure interprocess communication tonight in san jose, ca. I'm going.  >>  While I expect to be cheered up by the design (the underlying  >>  architecture supports memory protections down to the byte, not page,  >>  level, and may be largely immune to ROP) - I expect to be depressed by  >>  how far away they still remain from building the darn thing.  >>   >>  https://millcomputing.com/event/inter-process-communication-talk-on-october-4-2017/  >>   >>   >   >   >   >  --  >   >  Dave Täht  >  CEO, TekLibre, LLC  >  http://www.teklibre.com  >  Tel: 1-669-226-2619 -- Dave Täht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619  
>   
     

[-- Attachment #2: Type: text/html, Size: 5740 bytes --]