From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by c5ff346549e7 (Postfix) with ESMTPS id 698ED5D5 for ; Thu, 25 Jul 2019 19:24:16 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.64,307,1559512800"; d="scan'208";a="393337022" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 25 Jul 2019 21:24:15 +0200 Received: by sympa.inria.fr (Postfix, from userid 20132) id 8515182708; Thu, 25 Jul 2019 21:24:15 +0200 (CEST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id E478B826D8 for ; Thu, 25 Jul 2019 21:24:11 +0200 (CEST) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=hendrik@topoi.pooq.com; spf=None smtp.mailfrom=hendrik@topoi.pooq.com; spf=None smtp.helo=postmaster@april.topoi.pooq.com IronPort-PHdr: =?us-ascii?q?9a23=3AWFoIoRVlq9U70bRJn9SrYQ7IprLV8LGtZVwlr6E/?= =?us-ascii?q?grcLSJyIuqrYbBeDt8tkgFKBZ4jH8fUM07OQ7/m6Hzxaqs/a6jgrS99lb1c9k8?= =?us-ascii?q?IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUhrwOhBo?= =?us-ascii?q?KevrB4Xck9q41/yo+53Ufg5EmCexbal9IRmrswndrMobjZVtJqosxBbFvGZDdv?= =?us-ascii?q?hLy29vOV+dhQv36N2q/J5k/SRQuvYh+NBFXK7nYak2TqFWASo/PWwt68LlqRfM?= =?us-ascii?q?TQ2U5nsBSWoWiQZHAxLE7B7hQJj8tDbxu/dn1ymbOc32Sq00WSin4qx2RhLklD?= =?us-ascii?q?sLOjgk+2zRl8d+jr9UoAi5qhJxw4DafpybOvlwfqzSYdwVWGhOUchKWixdHo+x?= =?us-ascii?q?dZcDA/YbMOpGqYT2ulsArQG5BQmpHO7hyCFHhnnr0q0g0uQhEhzN0REnH9IJtX?= =?us-ascii?q?TfsdL4NKcMXuCz0abI1zTDb/BN1Dfh74jIahchofCWUbJodsrRzlAvGxnZgVWX?= =?us-ascii?q?rIzoJjWY3fkDvWic6upvT+Ovi2g/pgF+vDev3NojhpDShoIJzVDE8T15wIMvKt?= =?us-ascii?q?2+Tk53e8OrH4VIuyGbMYt2Xt0tQ2VytCkmzb0GvIa3czQQx5Qiwx7Qd/2Hc5SI?= =?us-ascii?q?4x75U+aROzh4iGpheLOxgRa+606gxfPgVsSyzV1ErTJFn8HNu30JzRDf98mKR/?= =?us-ascii?q?tn8ku81zuDyhrf5vxKLE07k6fQNoQvzaQqlpUJtETOBi/2l1vyjK+Rbkgr4PCo?= =?us-ascii?q?6/7mYrXivJOcK4h0ihn5MqQvgMC/GeM4Mg8XX2SB5eu807jj8VX4QLVMkPI2jr?= =?us-ascii?q?HUvZHeKMgBu6K0Ag9Y3pw+5xuxEjuqyskUkHcIIV5dfRKIlYnpO1XAIPDiCve/?= =?us-ascii?q?hkyhkDd1yPDAI7LhGJTNLnvYnbf9erZ980lcyAspwdBH4JJUDagBLOjvVU/2sd?= =?us-ascii?q?zUFgU5PBCsw+b7FNV90ZsTVn6VDa+cNKPeqFuI5uM0I+mQf4IVozb8K/095/H0?= =?us-ascii?q?l3M5mFkdfbOo3ZQNcny4EO5mcA2lZi/ni9IFVGMLpRYWTerwiVTEXyQASWy1Wv?= =?us-ascii?q?cc6zc3EoOlRa3EQYXl1LyM2iuhH55+emdeDVHKCXDvbsOPXPJaO3HaGdNojjFR?= =?us-ascii?q?DevpcIQmzxz77FanmYoiFfLd/2gjjbym1NVx4LeJxxgq7z1wSdiay2aMCXlzmX?= =?us-ascii?q?pOTDgzjvgm/R5Nj2yb2K09uMR2UMRJ7qoXABs9LZndifR9DMm0UQXELI/QGQSW?= =?us-ascii?q?B+6+CDR0deofhtoHYkJzAdKn106Rwy2yBL5Tj7uMHdo/9aeOh3U=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DwBwDDADpd/4aDpUVmHgEGBwaBZ4MEB?= =?us-ascii?q?UwhEiqNGYoomnsJAQMBMwUBAgEBgUuCdQKCeQYGNBMBAwEBBAEBAgEDAwFshR4?= =?us-ascii?q?Mgjoigm4BAQEBAQEBOhs0CxgJJQ8dKxkJgxqBew8Prn+EMwELAQYCOwQBQIMyg?= =?us-ascii?q?UiBNIkWgmCBf4ERgmQuPoJWCwECAYdCBIwHCxKHdpZXCYIcYYV4hG6GFIIpDBt?= =?us-ascii?q?0lxiVBJIaIYFYMxoIGxU7gmwJFoYUM4QmO4VbJjABgQUBAY1MAQE?= X-IPAS-Result: =?us-ascii?q?A0DwBwDDADpd/4aDpUVmHgEGBwaBZ4MEBUwhEiqNGYoomns?= =?us-ascii?q?JAQMBMwUBAgEBgUuCdQKCeQYGNBMBAwEBBAEBAgEDAwFshR4Mgjoigm4BAQEBA?= =?us-ascii?q?QEBOhs0CxgJJQ8dKxkJgxqBew8Prn+EMwELAQYCOwQBQIMygUiBNIkWgmCBf4E?= =?us-ascii?q?RgmQuPoJWCwECAYdCBIwHCxKHdpZXCYIcYYV4hG6GFIIpDBt0lxiVBJIaIYFYM?= =?us-ascii?q?xoIGxU7gmwJFoYUM4QmO4VbJjABgQUBAY1MAQE?= X-IronPort-AV: E=Sophos;i="5.64,307,1559512800"; d="scan'208";a="314728186" X-MGA-submission: =?us-ascii?q?MDEcaYis4KfGeyEu0UwOEyaxaMC/RS0MPARfOR?= =?us-ascii?q?01MIv/3+L76argEXhzc9hUi2gmjA2nZpUBKF6HJ9beH3z+KJgqymvQuF?= =?us-ascii?q?PTtXwLkUVhc79nFmUJZuwTfmfYrGyAzMhIMfBavYNwX/gatPSUxM+TN6?= =?us-ascii?q?MHaJuxatoNAMeehOwiepjdCw=3D=3D?= Received: from topoi.pooq.com (HELO april.topoi.pooq.com) ([69.165.131.134]) by mail3-smtp-sop.national.inria.fr with ESMTP; 25 Jul 2019 21:24:10 +0200 Received: by april.topoi.pooq.com (Postfix, from userid 1001) id B4B44C4127; Thu, 25 Jul 2019 15:24:07 -0400 (EDT) Date: Thu, 25 Jul 2019 15:24:07 -0400 From: Hendrik Boom To: caml-list@inria.fr Message-ID: <20190725192407.veppoxsv4ag2xkdi@topoi.pooq.com> References: <20190725142821.hf524xbdgqcshrei@annexia.org> <766885e6-5cf9-c5b0-7944-ed2e4db666b9@gerd-stolpmann.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <766885e6-5cf9-c5b0-7944-ed2e4db666b9@gerd-stolpmann.de> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [Caml-list] Any plans for supporting Intel CET in OCaml? Reply-To: Hendrik Boom X-Loop: caml-list@inria.fr X-Sequence: 17710 Errors-to: caml-list-owner@inria.fr Precedence: list Precedence: bulk Sender: caml-list-request@inria.fr X-no-archive: yes List-Id: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu, Jul 25, 2019 at 05:52:06PM +0200, Gerd Stolpmann wrote: > Am 25.07.19 um 16:28 schrieb Richard W.M. Jones: > > There's an effort to harden every binary in RHEL to protect against > > ROP-style attacks. Of course this is mainly applicable when your > > language is vulnerable to buffer overflows, but sadly even our OCaml > > applications still link to some C libraries :-( > > > > I was looking into this and the indirect branch tracking (IBT) part > > seems simple enough. For every indirect jump or call _target_ you > > must insert one of the two instructions ENDBR64 or ENDBR32 (both are > > NOP-like on older processors). The processor sets a flag when an > > indirect jump is taken and #CP's if the indirect jump doesn't land on > > one of these instructions. > > I guess that's fairly simple to add: Just put these instructions at the > beginning of each function, and you're good. For local functions, you > could do a bit more analysis to find those that are really used as branch > targets. If I understand it correctly, the idea of CET is to reduce the > attack surface. > > > > > There's also some stuff with shadow stacks which looks a lot more > > complicated and I didn't fully understand. The whole thing is > > described in: > > I think the idea is to prevent that you can change the return addresses > on the stack. For most code this should be fairly automatic, with a > few exceptions. The first is long jumps (used for exceptions in OCaml). > I've seen that there's a special instruction for removing entries from > the shadow stack, and for doing a long jump you need to know how many > frames you are going back. > > The other area where this could fall on your feet are structural > transitions where you write new stack entries, e.g. when you need to > switch to different calling conventions and need to write completely new > frames including return addresses. You cannot write new return addresses > to the shadow stack, though. I don't know by heart whether this affects > OCaml, but it could. I wonder how the shadow stack interacts with tail recursion. -- hendrik > > Gerd > > > > > > https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf > > https://lwn.net/Articles/758245/ > > > > Unfortunately (but for obvious reasons) every asm object in a program > > must be compiled with CET in order to enable the feature for the > > program as a whole. This means that any mixed OCaml/C program can't > > benefit from CET even in the C parts, unless we also support this in > > the OCaml parts. > > > > Has anyone looked into supporting this kind of thing in the amd64 > > backend? > > > > (I looked at the OCaml trunk and couldn't see any relevant commits, > > but maybe I missed something in my grepping). > > > > Rich. > > -- > ------------------------------------------------------------ > Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de > My OCaml site: http://www.camlcity.org > Contact details: http://www.camlcity.org/contact.html > Company homepage: http://www.gerd-stolpmann.de > ------------------------------------------------------------ > >