From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 09A373B2A4 for ; Sat, 7 Oct 2017 14:32:53 -0400 (EDT) Received: by mail-qt0-x230.google.com with SMTP id 34so19743022qtb.13 for ; Sat, 07 Oct 2017 11:32:53 -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=Vbm2SY/QhlSeUFWS/DZeI9S3+baSKR1zVnIaMV7LD+g=; b=XoIdYLpmDzYER9EDkdND74P0d1+typVk/ZmpM412Kj/UuEI95r0kdn6VGibUH1tKSz qnd7hACnS4ojAe9g7+N2aAs2yVEhCbB6M25EyGqJIUPOO5WZrOpTPHFdKArZ61rEWbdK 4/gXHjq02zqCyi6jUwfWuPqfwbsEUs/lR42egGr3ChvImCvJt5ZnXAaKqRVGKtQzgd+C aTxmC6JQzVb8ROXGvOvjq5uMLnmEF1RsM350QC1XI3zoT/gEDOdjR0W7Q86BLGDyUZBu LuFmn/wX+1WAm+esn7PQ6AsCCgtzojHp0wGNmVR69HjDHm6r3pF67Y9+iiww1Jtzf30b sm8g== 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=Vbm2SY/QhlSeUFWS/DZeI9S3+baSKR1zVnIaMV7LD+g=; b=J9KujQHhDBYci+bRjLr2kRUgA78rG/2Iitl+lZVaJUFHPkYv46fHDI5VOVFbBNnKQs +UoNdf0Z5k+FAM2qsNijuStcezGtJ/mC/tbfB8YBOAvX1TleICrUzpZCSA9OX2g+A9VX 6t6mcpuD3OL9b8oezIA7XQy/x/hi9fO6mzDEjjjqa2YSQoisOnMP7QXLiiQE7uuPpEQZ 8bcIansSJyTnCCm0+65IbNFC5cYp+6NQKLerddIlFQUpi1Sa+rrsfdeAMlasaDneo0RZ pvKiif8+bNUHTgcheuqtLqy8Am+pccn6ZVmUVT0X4kzW9PlDMP6hiGB9GHikl16j2mfz 8XfQ== X-Gm-Message-State: AMCzsaW5nUdSPYBPQOpw/ug6PbcNlMH1x+XxcAS3tFiEa3QG19mORekh wtA8zAoEqU+U+2hFeKd4xEB5SQ80vKPhsE3jxiE= X-Google-Smtp-Source: AOwi7QBGr765XurAjsJ8OIgcMNMtiBt8cBk5f5J22O90ALFRCmYd+elGwAxQdqQgXOBefIcsHPbMKxSXP1pEqq7IYOk= X-Received: by 10.200.8.131 with SMTP id v3mr7633413qth.262.1507401173494; Sat, 07 Oct 2017 11:32:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.193.115 with HTTP; Sat, 7 Oct 2017 11:32:52 -0700 (PDT) In-Reply-To: <59d8d7ae.5b37c80a.9c70e.c057SMTPIN_ADDED_BROKEN@mx.google.com> 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 11:32:52 -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 18:32:54 -0000 On Sat, Oct 7, 2017 at 6:33 AM, dpreed wrote: > No disagreement here. I saw a wonderful discussion recently by a research= er > at Mentor Graphics about 2 things: VLSI design hacking and low level > interconnect hacking. Things we call "hardware" and just assume are desig= ned > securely. > > They are not. The hardware designers at the chip and board level know lit= tle > 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 abou= t > 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 kno= w, > 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 subroutine= s. 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, 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-octob= er-4-2017/ > > --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619