caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Hendrik Boom <hendrik@topoi.pooq.com>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Any plans for supporting Intel CET in OCaml?
Date: Wed, 31 Jul 2019 10:19:53 -0400	[thread overview]
Message-ID: <20190731141952.zod7aftusgchoiyq@topoi.pooq.com> (raw)
In-Reply-To: <CAH=h3gHMAB61PF2V0BkmZSh52tjPdom_EBN6yzmJPyuv89t1tw@mail.gmail.com>

On Wed, Jul 31, 2019 at 02:05:26PM +0200, Xavier Leroy wrote:
> On Thu, Jul 25, 2019 at 4:28 PM Richard W.M. Jones <rich@annexia.org> wrote:
> 
> > 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.
> >
> 
> Sounds like it should be easy to add to the OCaml x86-64 back-end.

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.

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

Do we now have two distinct platforms to support?

-- 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.
> >

  reply	other threads:[~2019-07-31 14:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-25 14:28 Richard W.M. Jones
2019-07-25 15:52 ` Gerd Stolpmann
2019-07-25 19:24   ` Hendrik Boom
2019-07-31 12:05 ` Xavier Leroy
2019-07-31 14:19   ` Hendrik Boom [this message]
2019-07-31 15:21     ` Xavier Leroy
2019-07-31 17:40       ` Ivan Gotovchits

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190731141952.zod7aftusgchoiyq@topoi.pooq.com \
    --to=hendrik@topoi.pooq.com \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).