From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp105.iad3a.emailsrvr.com (smtp105.iad3a.emailsrvr.com [173.203.187.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 54B653B2A4 for ; Sat, 7 Oct 2017 16:54:38 -0400 (EDT) Received: from smtp30.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp30.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 2D434598B; Sat, 7 Oct 2017 16:54:38 -0400 (EDT) X-Auth-ID: dpreed@reed.com Received: by smtp30.relay.iad3a.emailsrvr.com (Authenticated sender: dpreed-AT-reed.com) with ESMTPSA id CD2F459C5; Sat, 7 Oct 2017 16:54:37 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from [192.168.192.87] (209-6-11-27.s1557.c3-0.ded-ubr1.sbo-ded.ma.cable.rcncustomer.com [209.6.11.27]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Sat, 07 Oct 2017 16:54:38 -0400 Date: Sat, 7 Oct 2017 16:54:37 -0400 From: dpreed To: Dave Taht Cc: Rich Brown , "=?utf-8?Q?cerowrt-devel=40lists.bufferbloat.net?=" Message-ID: <@localhost> In-Reply-To: References: <82be7dac-c30b-449d-a392-305c31b83519@reed.com> <59d8d7ae.5b37c80a.9c70e.c057SMTPIN_ADDED_BROKEN@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="EdoMail59d93f0d_14910b31_30a3" Subject: Re: [Cerowrt-devel] dnsmasq CVEs X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 20:54:38 -0000 Message-ID: <20171007205437.MDMzlG82CS493p2jM_6KtYlhE7etAtUkHIlOPKaY-V0@z> --EdoMail59d93f0d_14910b31_30a3 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =20 =20 Interesting. If stack pops zeroed memory, a stack machine would fix the s= ubroutine call privilege drop issue. Also register zeroing on syscall ret= urn avoids privilege leaks. Linux on Intel 64 doesn't do this :-( =20 =20 The mill is very interesting. =20 =20 =20 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 r= equire rethinking that choice. These days, shared standardized infrastruc= ture tends to require open adoptability. =20 =20 =20 =20 =20 =20 =20 > =20 > On Oct 7, 2017 at 4:28 PM, wrote: > =20 > =20 > I misstated something, fix below. On Sat, Oct 7, 2017 at 11:32 AM, Dav= e Taht wrote: > On Sat, Oct 7, 2017 at 6:33 AM, dpreed wrote: >> No d= isagreement 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 =22hardware=22 and just assume = are designed >> securely. Was this filmed, btw=3F >> They are not. Th= e hardware designers at the chip and board level know little >> or noth= ing about security techniques. They don't work with systems people >> w= ho build with their hardware to limit undefined or covert behaviors. >> = >> Systems people in turn make unreasonable and often wrong assumption= s about >> what is hard about hardware. Assumptions about what it won't= do, in >> particular. >> >> We need to treat hardware like we trea= t software. =46ull of bugs, easily >> compromised. There are approaches= to reliability and security that we know, >> that are tractable. But t= o apply them we need to drop the fictional idea >> that hardware is har= d... 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 sub= routines. > > The talk (it's up at =5B0=5D, but because it has to cov= er so much prior > material doesn't really get rolling till slide 30) h= ighlighted how > they do secure IPC, and transfer memory access privs a= round, cheaply. > > One thing I hadn't realized was that the belt con= cept=5B1=5D resulted in > having no register =22rubble=22 left over fro= m making a normal... or=21 IPC > call that changed privs. Say you have = a belt with values like: > > 3=7C4=7C2=7C1=7C5=7C6=7C7=7C8 > > a = subroutine call, with arguments > > jsr somewhere,b1,b4,b3 > > cr= eates a new belt (so the called routine sees no other registers from > = the caller) > > 4,5,1,X,X,X,X,X =23 (the mill has a concept of =22not= a value, or NAR=22) > > On a return, the same idea applies, where th= e return values are dropped > at the head of the callee's belt. head of= the callers belt, I meant. > callee does some work: > > 8=7C1=7C2=7C= 3=7C6=7C2=7C7=7C1 > ... > retn b1,b5 > > Which drops those two va= lues only on the callers belt, and discards > everything else. SSA, eve= rywhere. > > callee belt becomes: caller belt becomes > > 1=7C2=7C= 3=7C4=7C2=7C1=7C5=7C6 > > This makes peer to peer based secure IPC (W= here normally you'd have a > priv escalation call like syscall, or atte= mpt sandboxing) a snap, > instead of making a jsr, you make a =22portal= =22 call, which also ets up > memory perms, etc. > > Me trying to e= xplain here how they handle priv (de)escalation > (switching between =22= turfs=22 and so on) is way beyond the scope of what > I could write her= e, let me just say their work is computer > architecture Pr0n of the hi= ghest order, and I've lost many, many > weekends to grokking it all. =5B= 2=5D. > >> The end to end argument >> should be applied to bus prot= ocols like CAN, for the same reason. > > Too late=21 > > =5B0=5D = https://millcomputing.com/docs/inter-process-communication/ > =5B1=5D h= ttps://en.wikipedia.org/wiki/Belt=5Fmachine > =5B2=5D https://millcompu= ting.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 >> arch= itecture supports memory protections down to the byte, not page, >> lev= el, and may be largely immune to ROP) - I expect to be depressed by >> = how far away they still remain from building the darn thing. >> >> ht= tps://millcomputing.com/event/inter-process-communication-talk-on-october= -4-2017/ >> >> > > > > -- > > Dave T=C3=A4ht > CEO, Tek= Libre, LLC > http://www.teklibre.com > Tel: 1-669-226-2619 -- Dave T=C3= =A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619 =20 > =20 --EdoMail59d93f0d_14910b31_30a3 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Interesting. If stack pops zeroed memory= , a stack machine would fix the subroutine call privilege drop issue. Als= o register zeroing on syscall return avoids privilege leaks. Linux on Int= el 64 doesn't do this :-(

The mill is very inter= esting. 

One concern, I have recently reali= zed that it is not fully open like RISC-V. I don't blame its  develo= pers for wanting a ROI. But adoption may require rethinking that choice. = These days, shared standardized infrastructure tends to require open adop= tability.

On Oct 7, 2017 at 4:28 PM, <Dave Taht> wrote: 

I misstated somethin=
g, 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 l=
evel
>> interconnect hacking. Things we call =22hardware=22 and just ass=
ume are designed
>> securely.

Was this filmed, btw=3F

>> They are not. The hardware designers at the chip and board level=
 know little
>> or nothing about security techniques. They don't work with syste=
ms people
>> who build with their hardware to limit undefined or covert behav=
iors.
>>
>> Systems people in turn make unreasonable and often wrong assumpt=
ions about
>> what is hard about hardware. Assumptions about what it won't do,=
 in
>> particular.
>>
>> We need to treat hardware like we treat software. =46ull of bugs=
, easily
>> compromised. There are approaches to reliability and security th=
at we know,
>> that are tractable. But to apply them we need to drop the fictio=
nal 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 sub=
routines.
>
> The talk (it's up at =5B0=5D, but because it has to cover so much pr=
ior
> 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=5B1=5D resulte=
d in
> having no register =22rubble=22 left over from making a normal... or=
=21 IPC
> call that changed privs. Say you have a belt with values like:
>
> 3=7C4=7C2=7C1=7C5=7C6=7C7=7C8
>
> a subroutine call, with arguments
>
> jsr somewhere,b1,b4,b3
>
> creates a new belt (so the called routine sees no other registers fr=
om
> the caller)
>
> 4,5,1,X,X,X,X,X =23 (the mill has a concept of =22not a value, or NA=
R=22)
>
> On a return, the same idea applies, where the return values are drop=
ped
> at the head of the callee's belt.

head of the callers belt, I meant.

> callee does some work:
>
> 8=7C1=7C2=7C3=7C6=7C2=7C7=7C1
> ...
> 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=7C2=7C3=7C4=7C2=7C1=7C5=7C6
>
> 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 =22portal=22 call, which also et=
s up
> memory perms, etc.
>
> Me trying to explain here how they handle priv (de)escalation
> (switching between =22turfs=22 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. =5B2=5D.
>
>> The end to end argument
>> should be applied to bus protocols like CAN, for the same reason=
.
>
> Too late=21
>
> =5B0=5D https://millcomputing.com/docs/inter-process-communication/
> =5B1=5D https://en.wikipedia.org/wiki/Belt=5Fmachine
> =5B2=5D 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 g=
oing.
>> While I expect to be cheered up by the design (the underlying
>> architecture supports memory protections down to the byte, not p=
age,
>> level, and may be largely immune to ROP) - I expect to be depres=
sed 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=C3=A4ht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619



-- =20

Dave T=C3=A4ht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
=20
--EdoMail59d93f0d_14910b31_30a3--