Enable address sanitizer for SystemZ

[Quuxplusone]

Bugzilla Link	PR23433
Status	RESOLVED FIXED
Importance	P enhancement
Reported by	Ulrich Weigand (uweigand@de.ibm.com)
Reported on	2015-05-06 08:11:07 -0700
Last modified on	2016-11-30 07:22:44 -0800
Version	trunk
Hardware	Other Linux
CC	cjhowe@vt.edu, koriakin@0x04.net, llvm-bugs@lists.llvm.org, vonosmas@gmail.com
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

The address sanitizer is currently not supported on SystemZ.  It would be good
to have this working.

This would include:
 - Sanitizer runtime library support for SystemZ
 - Compiler support to enable instrumention on SystemZ
 - Compiler driver support
 - Test suite updates

Goal is to have the sanitizer test suite pass on s390x-linux.

[Quuxplusone]

Do you (or someone else with sufficient SystemZ experience) plan to work on this?

[Quuxplusone]

(In reply to comment #1)
> Do you (or someone else with sufficient SystemZ experience) plan to work on
> this?

We're planning to offer a BountySource bounty for this item, similar to what we
did for sanitizers on PowerPC (see e.g. bug 23218).

[Quuxplusone]

Do you have a system to test this on? I know there is Hercules emulation available for SystemZ, but it's a little outdated. I want to attempt the BountySource bounty, but I need something solid to test it on and documentation about SystemZ.

[Quuxplusone]

(In reply to comment #3)
> Do you have a system to test this on? I know there is Hercules emulation
> available for SystemZ, but it's a little outdated. I want to attempt the
> BountySource bounty, but I need something solid to test it on and
> documentation about SystemZ.

There's the "IBM Developer Community Cloud for z Systems", where you can get
access to a virtual machine running Linux on z Systems for the purpose of
porting open source applications to z, which is certainly applicable for this
bounty.  I'll send you a link how to request access.

As to documentation about SystemZ, the most important document is the
"z/Architecture Principles of Operations" describing the architecture and
instruction set.  You can find this document here:
http://www-01.ibm.com/support/docview.wss?uid=isg2b9de5f05a9d57819852571c500428f9a

Another important document is the Linux on z Systems Application Binary
Interface description here:
http://refspecs.linuxbase.org/ELF/zSeries/lzsabi0_zSeries.pdf

If you have more specific questions, just let me know.

Thanks for working on this!

[Quuxplusone]

Hey,

I got asan more or less working with gcc/s390, gcc/s390x and llvm/s390x.  I
will submit the patches soon.

There's one important decision to make for asan (it'll become part of the ABI):
the shadow memory offset.  Basically, we need to find a free area covering 1/8
of the address space, preferably with an address that's easy to represent.

For s390, it's easy enough: the usual 0x20000000 works fine.  However, s390x on
linux supports 1<< 53 bytes of virtual space, and tends to allocate things just
below 1 << 42 - making the smallest possible offset 1 << 42.  I've considered a
few possibilities:

1. The simple thing - just use 1 << 42.  Unfortunately won't fit in any add
instruction immediate.
2. The OR trick - use 7 << 50, the end of the address space.  Since it's the
end, we can use OR instead of add for the offset, which maps to a simple OIHH
on s390x.  The only problem is if linux ever gains support for full 64-bit
address space - we'd need to change the or into add, but this could be done in
a         somewhat compatible way.
3. The x86_64 way - use 0xffff8000 (the largest properly aligned thing that
fits in ALGFI) as the offset - due to the 1 << 42 issue, it'd require
artificially limitting the address space.  It's also not a win on machines
without extended immediates.
4. The android way - use 0 as the offset.   Very simple instruction sequence
(no or/add), but also requires limitting the address space, and requires
programs to be compiled as PIE.  Not good.

So, IMO we should go with #2 (which is also what my current code uses).  What
do you think?

[Quuxplusone]

I agree that option 2 is the way to go.

The Z hardware supports either 3 (2^42), 4 (2^53), or 5 (2^64) levels of page
tables.  Linux only supports 3 or 4 levels, where any 64-bit application will
start out in 3-level mode, with the kernel automatically switching to 4-level
mode at the point the applications attempts to make a memory mapping that does
not fit in the 3-level address space.

At this point, there are no plans to support 5 levels of page tables in the
Linux kernel, for two reasons: 1) there does not appear to be any need to
support more than 2^53 bytes of virtual address space for any application, and
2) Linux kernel *common code* memory management infrastructure is limited to 4
levels, so before supporting this on Z, we'd have to spend significant effort
to get this implemented in common code (and accepted upstream).

And even if this happens at any point in the future, applications would still
start out with 3 levels, switch to 4 levels first, and only switch to 5 levels
once making memory mappings that no longer fit into 4 levels.  So even if asan
doesn't work with 5 levels, this would only affect those very few programs.  We
could then always add a special asan mode to be used for those, if necessary.

[Quuxplusone]

Well, I've got some bad news - turns out reserving that much memory (1PB) hits a serious bug somewhere in the kernel on some asan tests. It hangs the process somewhere in paging routine (it can never make forward progress on a simple load from memory instruction, as checked by gdb with stepi - it never finishes), and crashes the whole machine the second time you kill it.

I'll try to investigate that bug so that we can get it fixed, but I guess we'll have to come up with some workaround, perhaps by limitting the amount of reserved space on older kernels - I suppose it'd be bad to have -fsanitize=address easily emitting a machine-crasher....

[Quuxplusone]

Should be working as of rL288116. The ASan testsuite is passing on the clang-s390x-linux buildbot. Anything left to do here?

[Quuxplusone]

Looks like everything is working now. Thanks, Marcin!