From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E597A3B2A4 for ; Sat, 7 Oct 2017 16:28:47 -0400 (EDT) Received: by mail-qt0-x22b.google.com with SMTP id 6so27982043qtw.3 for ; Sat, 07 Oct 2017 13:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=anfCNxGe2dGg/Do7hRUyMaa3F2J3rzbPwdScKJicom4=; b=l4Y8PWStxoJjbILV8ades4MA8MxPNUT6t/RboQhaXx87e9wxixsKSV8RNZ5XtrXAo5 TxpbtGWjSurOHGIF8so/uDv8ocKM5Yp4GnRsxjRdxXWETrZJushHb4fYEPQ/WHsaJb4M xJrg0j3Laj/qNOr084uASdsbsOHZN+BPdF7jUFD6MARp6fi+/rzy6FoPytVqrIfekFTg nLOKduJLR71qLo5NAnGgDeBgJB3DcSJAa4qq2868trNZC2L3peh+pSR5wXz7QADYa298 q3Uz2fWDZChJ0Hr7BkH+Wd3nHJWcZPwE0/TJ3fqtdQlArpflJTosYttLDIrSZZDn6hTp mxIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=anfCNxGe2dGg/Do7hRUyMaa3F2J3rzbPwdScKJicom4=; b=KXyW2bMGetFkhzjDuWxJmA2bSO45LEk1q6F44janpJZ/6WvDVZ7pZmUuMNFRbx+EBV Lmjgv23P3DRxjvkkmmAUbEkA+LaR8DZhyy08j7pMIypalX1SDntPem7tdaGSn+dm1iVg iPbml4JVZuTU7sW57+76YtZHVx3iEi1jY5KjmldUW4EexpX8KmbR7Or55oxHatRCjju1 N2g4GOy8yhw1RLXvvmtNHPMPZVgwCQ6yK7XSltkP/bE+zIkxPaNkpYj4gX2hzCnizhiT IWG1SnuDUMQhHeHjpnd8hFp8jJ7CwYjQfaqb3prum4f2VUfHVXh+3QPBnSsI3gmD75Rw QpLw== X-Gm-Message-State: AMCzsaXHfTSeOUu37qbUVlDLan6UuL9Oayf6TR1uQc1KPiBSMb9zk0Wl kNNEsRIAjQuUuFkiStXIesGFquZ0wKCD1lJc+KY= X-Google-Smtp-Source: AOwi7QAafiPN2e7EpGyg7yACwcpa61EQmPJTKZRFdTQNp4kB8Pnn8lu5HK3Xv9abjSzYjQ23MOhJxuPLpjUzntk8LiY= X-Received: by 10.200.40.19 with SMTP id 19mr8128941qtq.314.1507408127423; Sat, 07 Oct 2017 13:28:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.193.115 with HTTP; Sat, 7 Oct 2017 13:28:46 -0700 (PDT) In-Reply-To: References: <82be7dac-c30b-449d-a392-305c31b83519@reed.com> <59d8d7ae.5b37c80a.9c70e.c057SMTPIN_ADDED_BROKEN@mx.google.com> From: Dave Taht Date: Sat, 7 Oct 2017 13:28:46 -0700 Message-ID: To: dpreed Cc: Rich Brown , "cerowrt-devel@lists.bufferbloat.net" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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:28:48 -0000 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 researc= her >> at Mentor Graphics about 2 things: VLSI design hacking and low level >> interconnect hacking. Things we call "hardware" and just assume are desi= gned >> securely. Was this filmed, btw? >> They are not. The hardware designers at the chip and board level know li= ttle >> or nothing about security techniques. They don't work with systems peopl= e >> who build with their hardware to limit undefined or covert behaviors. >> >> Systems people in turn make unreasonable and often wrong assumptions abo= ut >> 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 kn= ow, >> 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 subrouti= nes. > > 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-octo= ber-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