RFR: Disable PaX mprotect on executables

[Erik Joelsson]

On 2017-04-13 07:00, David Holmes wrote:
> Hi Mikael,
>
> On 13/04/2017 9:09 AM, Mikael Vidstedt wrote:
>>
>> Alpine by default has PaX [1] enabled. Among other things, PaX tries 
>> to prevent various attack vectors by controlling the ways in which 
>> page protection can be updated/changed. For example, it does not 
>> allow marking previously writable pages as executable. Guess what 
>> hotspot likes to do?
>>
>> This change is incomplete, and I could use some help figuring out how 
>> to complete it.
>
> In all seriousness I would not do this. I think it is up to the 
> "deployer" of a JRE on such a system to take whatever PaX related 
> steps are needed to allow the binaries to run. I don't think we should 
> be making any such decisions at build time, nor requiring paxctl be 
> available. All we should do is document what is required.
>
I think we do have to support this. Alpine is the platform we are being 
asked to support and our bits will be DoA unless this is done. This will 
get very annoying quickly when trying to test the bits. Unless, of 
course, we only support and test on alpine in containers. Whichever we 
do, it needs to be documented.

You are correct that this has nothing to do with muscl, so I think it 
should be controlled with a specific configure flag (--enable-pax?) and 
it should be default off. We would need to put paxctl in the devkit for 
the affected platform(s) since it's not default installed on our build 
platforms today (or create a separate package with it, perhaps easier). 
In our jib profile configuration we would enable this for the alpine 
linux builds.

Supporting running the build on a PaX enabled system is a different 
issue. If we want to support this, then we could have configure detect 
that PaX is currently active (I assume that's possible) and take the 
necessary precautions to use paxctl on at least the buildjdk, and if not 
cross compiling, also the target jdk. This would be the only case where 
the default value of the flag would be true.

/Erik

> David
> -----
>
>> http://cr.openjdk.java.net/~mikael/webrevs/portola/paxctl/webrev.00/webrev/ 
>>
>>
>> Basically, it all comes down to needing to use a tool - paxctl - to 
>> mark the executables in a way so that the kernel knows to 
>> disable/relax some of the PaX features for the process. The patch 
>> adds support for finding the paxctl tool, and for using the tool (if 
>> found) to mark the excutable. However, here are two of the main 
>> reasons why this patch is incomplete:
>>
>> * There are two different JDKs which may or may not need the special 
>> paxctl treatment: buildjdk and target jdk. When building the JDK on 
>> Alpine (really: on a PaX enabled system) the buildjdk needs to have 
>> its executables marked as well, but when cross compiling that’s not 
>> necessarily needed.
>> * The patch currently bases the decision on whether to mark the 
>> executables on whether the target CLIB is “musl”, where in fact that 
>> doesn’t really have anything to do with musl
>> * Not all executables necessarily load and run the JVM, so not all of 
>> them necessarily need to be marked
>> * It’s not really the user space that decides whether the PaX 
>> relaxation is needed - it’s the kernel. That means that when running 
>> in, say, Docker, even if the base image would be Alpine (or some 
>> other distribution which has PaX enabled by default), it’s really the 
>> configuration of the host system kernel which comes into play.
>>
>> I’m not sure what the right solution is here. Taking suggestions.
>>
>> Cheers,
>> Mikael
>>
>> [1] http://pax.grsecurity.net
>>