From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp89.iad3a.emailsrvr.com (smtp89.iad3a.emailsrvr.com [173.203.187.89]) (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 E090C3B2A4 for ; Sat, 7 Oct 2017 09:33:34 -0400 (EDT) Received: from smtp12.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp12.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id A9FA02505F; Sat, 7 Oct 2017 09:33:34 -0400 (EDT) X-Auth-ID: dpreed@reed.com Received: by smtp12.relay.iad3a.emailsrvr.com (Authenticated sender: dpreed-AT-reed.com) with ESMTPSA id 7A78325062; Sat, 7 Oct 2017 09:33:34 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from [172.31.98.142] (50-245-62-59-static.hfc.comcastbusiness.net [50.245.62.59]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Sat, 07 Oct 2017 09:33:34 -0400 Date: Sat, 7 Oct 2017 09:33:34 -0400 From: dpreed To: Dave Taht Cc: Rich Brown , "=?utf-8?Q?cerowrt-devel=40lists.bufferbloat.net?=" Message-ID: <@localhost> In-Reply-To: <82be7dac-c30b-449d-a392-305c31b83519@reed.com> References: <82be7dac-c30b-449d-a392-305c31b83519@reed.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="EdoMail59d8d7ae_2870e9f1_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 13:33:35 -0000 --EdoMail59d8d7ae_2870e9f1_30a3 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline 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. The principle of least privilege is one of those. The end to end argument should be applied to bus protocols like CAN, for the same reason. > > 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/ > --EdoMail59d8d7ae_2870e9f1_30a3 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
No disagreement here. I saw a wonderful = discussion recently by a researcher at Mentor Graphics about 2 things: VL= SI design hacking and low level interconnect hacking. Things we call =22h= ardware=22 and just assume are designed securely.

They are not. The hardware designers at the chip and board level know l= ittle or nothing about security techniques. They don't work with systems = people who build with their hardware to limit undefined or covert behavio= rs.

Systems people in turn make unreasonable and= often wrong assumptions about what is hard about hardware. Assumptions a= bout what it won't do, in particular.

We need to= treat hardware like we treat software. =46ull of bugs, easily compromise= d. There are approaches to reliability and security that we know, that ar= e tractable. But to apply them we need to drop the fictional idea that ha= rdware is hard... It's soft.

The principle of le= ast privilege is one of those. The end to end argument should be applied = to bus protocols like CAN, for the same reason.


On Oct 4, 2017 at 12:38= PM, <Dave Taht> w= rote: 

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-octob=
er-4-2017/
=20
--EdoMail59d8d7ae_2870e9f1_30a3-- 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--