Build the IRT with nacl-clang for x86

src/untrusted/irt/frame_info_stubs.c

+/*
+ * Copyright (c) 2015 The Native Client Authors. All rights reserved.
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ */
+
+/*
+ * On x86-64 we build the IRT with sandbox base-address hiding. This means that

[Mark Seaborn, 2015/03/19 20:54:48]

What's the plan for making sure this doesn't regress?  If we stopped including
this file in the build, would anything catch that?

Shyam was going to implement some extra validator checks in parallel with your
work on changing the IRT build, but he left.

There are a lot of parts that must be right for the base-address-hiding to work.
 I'm concerned that an innocent-looking toolchain change could cause a
regression without us noticing.

Should we find someone to do the validator change, if only to catch a simple
subset of cases, like disallowing CALL instructions?

[Derek Schuff, 2015/03/19 21:28:30]

That sounds reasonable.
For simple things like catching call instructions, we could even implement
something with objdump. We could even check for 'push rbp' that way.

[Derek Schuff, 2015/03/24 01:27:19]

I've started a CL with a simple objdump-based lint check to keep this from
regressing. It catches several bad constructs:
https://codereview.chromium.org/1009533004
I don't think it needs to block this CL though; are there any other issues here?

[Mark Seaborn, 2015/03/25 08:37:00]

Thanks, that would be useful.  It's not as good as a validator change, which
would give us some extra security hardening against bugs in the translator, but
it's an improvement on the current lack of checks.

+ * all of its components must be built with LLVM's assembler. Currently the
+ * unwinder library is built with nacl-gcc and so does not use base address
+ * hiding. The IRT does not use exceptions, so we do not actually need the
+ * unwinder at all. To prevent it from being linked into the IRT, we provide
+ * stub implementations of its functions that are referenced from crtbegin.c.
+ */
+
+void __register_frame_info(void *begin, void *ob) {}

[Mark Seaborn, 2015/03/19 20:54:48]

When linking nexes with nacl-clang, do we always use the variant of crtbegin.o
that pulls these in?  Does nacl-clang always pull in these functions from
libgcc_eh?

[Derek Schuff, 2015/03/19 21:28:30]

Yes; there is currently only one variant, pnacl/support/clang_direct/crtbegin.c,
which calls these from a global contstructor. The unwinder/libgcc_eh is the only
implementation I know of.

+void __deregister_frame_info(const void *begin) {}