Add lint check for IRT sandbox base address hiding.

Add lint check for IRT sandbox base address hiding.

This is a kind of lint check to ensure that the LLVM assembler's option for
hiding the sandbox base address on x86-64 is being used in all code compiled
into the IRT (and that assembly code does not have similar issues). It is only a
heuristic intended to prevent accidental changes in the IRT or toolchain build,
and is not exhaustive,
nor is it intended to catch adversarial code.
It is a stopgap until we can fix
https://code.google.com/p/nativeclient/issues/detail?id=3596

R=jvoung@chromium.org, mseaborn@chromium.org
BUG= https://code.google.com/p/nativeclient/issues/detail?id=4088

Committed: https://chromium.googlesource.com/native_client/src/native_client/+/2d8b0bb6ffaf871fdc1f902d38778b2df8c6ff0d

[Derek Schuff, 2015-03-24 17:20:39]

dschuff@chromium.org changed reviewers:
+ jvoung@chromium.org

[Derek Schuff, 2015-03-24 17:20:39]

+jvoung

[jvoung (off chromium), 2015-03-24 20:47:25]

https://codereview.chromium.org/1009533004/diff/1/build/link_irt.py
File build/link_irt.py (right):

https://codereview.chromium.org/1009533004/diff/1/build/link_irt.py#newcode168
build/link_irt.py:168: '''
""" instead of ''' for docstrings and oneliner summary on the first line.

https://codereview.chromium.org/1009533004/diff/1/build/link_irt.py#newcode181
build/link_irt.py:181: test_regex += r'|[^(]%rsp,(?!%rbp)|[^(]%rbp,'
Hmm, so the trailing ","  is required? What about push %rbp?

https://codereview.chromium.org/1009533004/diff/1/build/link_irt.py#newcode189
build/link_irt.py:189: for line in output.splitlines():
Hmm... can the splitlines() be done earlier?

My main concern is if this will dump the whole executable's text section on
error, which I don't think a developer would want (scrolls the error message).
You could possibly search for the function header as you scan along and scope
the error to a function to dump some context. You could also print the line
number within the objdump output for someone to repro / run objdump separately
and look at just the dump.

https://codereview.chromium.org/1009533004/diff/1/build/link_irt.py#newcode190
build/link_irt.py:190: match = re.search(test_regex, line)
3 space indent -> 2 space indent

https://codereview.chromium.org/1009533004/diff/1/build/link_irt.py#newcode192
build/link_irt.py:192: print line
1 space indent -> 2 space indent

https://codereview.chromium.org/1009533004/diff/1/build/link_irt.py#newcode218
build/link_irt.py:218: default=False)
help message?

[Derek Schuff, 2015-03-24 23:15:15]

https://codereview.chromium.org/1009533004/diff/1/build/link_irt.py
File build/link_irt.py (right):

https://codereview.chromium.org/1009533004/diff/1/build/link_irt.py#newcode168
build/link_irt.py:168: '''
On 2015/03/24 20:47:25, jvoung wrote:
> """ instead of ''' for docstrings and oneliner summary on the first line.

Done.

https://codereview.chromium.org/1009533004/diff/1/build/link_irt.py#newcode181
build/link_irt.py:181: test_regex += r'|[^(]%rsp,(?!%rbp)|[^(]%rbp,'
On 2015/03/24 20:47:25, jvoung wrote:
> Hmm, so the trailing ","  is required? What about push %rbp?

It needs the trailing comma so that it doesn't catch things like
lea    0x0(%rbp,%r15,1),%rbp
or
mov    %rsp,%rbp

I added a check to catch pushes.

https://codereview.chromium.org/1009533004/diff/1/build/link_irt.py#newcode189
build/link_irt.py:189: for line in output.splitlines():
On 2015/03/24 20:47:25, jvoung wrote:
> Hmm... can the splitlines() be done earlier?
> 
> My main concern is if this will dump the whole executable's text section on
> error, which I don't think a developer would want (scrolls the error message).
> You could possibly search for the function header as you scan along and scope
> the error to a function to dump some context. You could also print the line
> number within the objdump output for someone to repro / run objdump separately
> and look at just the dump.

I was attempting to avoid splitlines in the non-error case, in case the text was
really big, to avoid a big memory bloat. I could try to limit the number of
lines in the output in case of failure though, in addition to printing the
objdump command? The line output has the address and so is sufficient to locate
a unique instance in the output.

https://codereview.chromium.org/1009533004/diff/1/build/link_irt.py#newcode190
build/link_irt.py:190: match = re.search(test_regex, line)
On 2015/03/24 20:47:25, jvoung wrote:
> 3 space indent -> 2 space indent

Done.

https://codereview.chromium.org/1009533004/diff/1/build/link_irt.py#newcode192
build/link_irt.py:192: print line
On 2015/03/24 20:47:25, jvoung wrote:
> 1 space indent -> 2 space indent

Done.

[jvoung (off chromium), 2015-03-25 16:53:49]

lgtm

https://codereview.chromium.org/1009533004/diff/1/build/link_irt.py
File build/link_irt.py (right):

https://codereview.chromium.org/1009533004/diff/1/build/link_irt.py#newcode189
build/link_irt.py:189: for line in output.splitlines():
On 2015/03/24 23:15:15, Derek Schuff wrote:
> On 2015/03/24 20:47:25, jvoung wrote:
> > Hmm... can the splitlines() be done earlier?
> > 
> > My main concern is if this will dump the whole executable's text section on
> > error, which I don't think a developer would want (scrolls the error
message).
> > You could possibly search for the function header as you scan along and
scope
> > the error to a function to dump some context. You could also print the line
> > number within the objdump output for someone to repro / run objdump
separately
> > and look at just the dump.
> 
> I was attempting to avoid splitlines in the non-error case, in case the text
was
> really big, to avoid a big memory bloat. I could try to limit the number of
> lines in the output in case of failure though, in addition to printing the
> objdump command? The line output has the address and so is sufficient to
locate
> a unique instance in the output.

Okay sounds fine.

[Derek Schuff, 2015-03-25 17:42:29]

Committed patchset #2 (id:20001) manually as
2d8b0bb6ffaf871fdc1f902d38778b2df8c6ff0d (presubmit successful).