Re: [Cerowrt-devel] dnsmasq CVEs

[Dave Taht <dave.taht@gmail.com>]

On Sat, Oct 7, 2017 at 6:33 AM, dpreed <dpreed@reed.com> 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.
>
> 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.

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:

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, <Dave Taht> 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