[Cerowrt-devel] dnsmasq CVEs

[Dave Taht]

I misstated something, fix below.

On Sat, Oct 7, 2017 at 11:32 AM, Dave Taht <dave.taht at gmail.com> wrote:
> On Sat, Oct 7, 2017 at 6:33 AM, dpreed <dpreed at 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.

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



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619