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 E0F0D5D6 for ; Wed, 31 Jul 2019 15:21:43 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.64,330,1559512800"; d="scan'208,217";a="394020451" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 31 Jul 2019 17:21:42 +0200 Received: by sympa.inria.fr (Postfix, from userid 20132) id DE84082709; Wed, 31 Jul 2019 17:21:42 +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 9EA4E826BB for ; Wed, 31 Jul 2019 17:21:37 +0200 (CEST) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=xavier.leroy@college-de-france.fr; spf=Pass smtp.mailfrom=xavier.leroy@college-de-france.fr; spf=None smtp.helo=postmaster@smtpout01-ext1.partage.renater.fr X-IronPort-AV: E=Sophos;i="5.64,330,1559512800"; d="scan'208,217";a="315273056" X-MGA-submission: =?us-ascii?q?MDFu5W0ewd7ZYY0AWBNP8XRl9il8zKeyoB2Uy2?= =?us-ascii?q?oC/weKzYDfLNjbs/kWgRGKEVyHGe35asfXuriCspDzcmmYFxVxPglmI/?= =?us-ascii?q?dGOdbpT/5m6TURbFWcFuSVBBDvb57ovMXbx5AhEMP7cK3w8xvn+sK1z8?= =?us-ascii?q?pFi1wP4fm+ylkqDjf0aB3p+g=3D=3D?= Received: from smtpout01-ext1.partage.renater.fr ([194.254.240.32]) by mail3-smtp-sop.national.inria.fr with ESMTP; 31 Jul 2019 17:21:37 +0200 Received: from zmtaauth01.partage.renater.fr (zmtaauth01.partage.renater.fr [194.254.240.25]) by smtpout10.partage.renater.fr (Postfix) with ESMTP id 024046178A for ; Wed, 31 Jul 2019 17:21:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zmtaauth01.partage.renater.fr (Postfix) with ESMTP id F0D5A1400EF for ; Wed, 31 Jul 2019 17:21:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at zmtaauth01.partage.renater.fr Received: from zmtaauth01.partage.renater.fr ([127.0.0.1]) by localhost (zmtaauth01.partage.renater.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7V087t1TbqT4 for ; Wed, 31 Jul 2019 17:21:35 +0200 (CEST) Received: from 209.85.217.52 (unknown [194.254.241.251]) by zmtaauth01.partage.renater.fr (Postfix) with ESMTPA id ADDD21400B5 for ; Wed, 31 Jul 2019 17:21:35 +0200 (CEST) Received: by mail-vs1-f52.google.com with SMTP id m23so46439739vso.1 for ; Wed, 31 Jul 2019 08:21:35 -0700 (PDT) X-Gm-Message-State: APjAAAWSCKVPuYr3YWdKgU2wnxr3Aco8XsQVagJojcgB7dNdSrvRQueq Mij5tnVz6t7qxoudDuFPkv0gxS+rY1Z1sVm4JgI= X-Google-Smtp-Source: APXvYqz1nJatMMHICXNjXnwWGEvTBvOYg8KvjaBG7xBoTON0TqixM85JkWXmDFZEOEMtawucognmKkkwsz6Ny6g/qvU= X-Received: by 2002:a67:eec2:: with SMTP id o2mr16804872vsp.221.1564586494710; Wed, 31 Jul 2019 08:21:34 -0700 (PDT) MIME-Version: 1.0 References: <20190725142821.hf524xbdgqcshrei@annexia.org> <20190731141952.zod7aftusgchoiyq@topoi.pooq.com> In-Reply-To: <20190731141952.zod7aftusgchoiyq@topoi.pooq.com> From: Xavier Leroy Date: Wed, 31 Jul 2019 17:21:08 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Hendrik Boom Cc: caml users Content-Type: multipart/alternative; boundary="0000000000003cdd33058efbae7f" Subject: Re: [Caml-list] Any plans for supporting Intel CET in OCaml? Reply-To: Xavier Leroy X-Loop: caml-list@inria.fr X-Sequence: 17723 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: --0000000000003cdd33058efbae7f Content-Type: text/plain; charset="UTF-8" On Wed, Jul 31, 2019 at 4:20 PM Hendrik Boom wrote: > > There is, of course, also the question what would happen on nonintel or > older machines if they don't have those ENDBR64 or ENDBR32 > instructions in the hardware. > I read somewhere that those instructions look like no-ops on older machines. > > (Such as, perhaps, an actual AMD-manufactured AMD64? Like my > 10-year-old AMD server?) > > Do we now have two distinct platforms to support? > It could be a configure-time choice. I wouldn't call that two distinct platforms, more like two variants of the same platform. Just speculating here. All this needs to be discussed and agreed on, of course. - Xavier Leroy > -- hendrik > > > > > > > > > > > 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: > > > > > > > > > > https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf > > > https://lwn.net/Articles/758245/ > > > > > > > > I don't understand how these shadow stacks are supposed to interact with > > exception handling, either Caml-style or C++/Java style. > > > > Kind regards, > > > > - Xavier Leroy > > > > > > > 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. > > > > --0000000000003cdd33058efbae7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 31, 2019 at 4:20 PM Hendrik Boom <hendrik@topoi.pooq.com> wrote:

There is, of course, also the question what would happen on nonintel or older=C2=A0 machines if they don't have those ENDBR64 or ENDBR32
instructions in the hardware.

I read so= mewhere that those instructions look like no-ops on older machines.

(Such as, perhaps, an actual AMD-manufactured AMD64?=C2=A0 Like my
10-year-old AMD server?)

Do we now have two distinct platforms to support?

=
It could be a configure-time choice.=C2=A0 I wouldn't call t= hat two distinct platforms, more like two variants of the same platform.=C2= =A0

Just speculating here.=C2=A0 All this nee= ds to be discussed and agreed on, of course.

-= Xavier Leroy


-- hendrik

>
>
> >
> > There's also some stuff with shadow stacks which looks a lot = more
> > complicated and I didn't fully understand.=C2=A0 The whole th= ing is
> > described in:
> >
> >
> > https://software.intel.com/sites/default/files/managed/4d= /2a/control-flow-enforcement-technology-preview.pdf
> > https://lwn.net/Articles/758245/
> >
> >
> I don't understand how these shadow stacks are supposed to interac= t with
> exception handling, either Caml-style or C++/Java style.
>
> Kind regards,
>
> - Xavier Leroy
>
>
> > Unfortunately (but for obvious reasons) every asm object in a pro= gram
> > must be compiled with CET in order to enable the feature for the<= br> > > program as a whole.=C2=A0 This means that any mixed OCaml/C progr= am 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 co= mmits,
> > but maybe I missed something in my grepping).
> >
> > Rich.
> >
--0000000000003cdd33058efbae7f--