Re: Linux + Clang + execstack

[Magnus Ihse Bursie]

On 2018-09-19 02:01, Martin Buchholz wrote:

Unfortunately, my gmail marked Arthur's emails to this thread as spam,
with ensuing confusion.

I retargeted this fix to the new bug

8209817: stack is executable when building with Clang on Linux
http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/
https://bugs.openjdk.java.net/browse/JDK-8209817

and it made it through the submit repo tests.

Ready to submit this.

Please do.

/Magnus



On Thu, Sep 13, 2018 at 2:10 PM, Magnus Ihse Bursie
 wrote:

We're not entirely happy either.

A much higher interface might look like

TRY_ADD_LINKER_FLAGS -z noexecstack

Agreed. I'm working towards a solution like that.

which would add -Wl,-z,noexecstack to LDFLAGS when appropriate
 hmmm ...
I only just noticed that both gcc and clang accept simply
$CC -z noexecstack
(it's even documented!)
Should we switch to that instead?

No, I think it's better to keep -Wl,-z for consistency for all linker flags.
Otherwise it just looks confusing.

/Magnus





Do you have a JBS issue?

I have
https://bugs.openjdk.java.net/browse/JDK-8205457 gcc and clang should
use the same ld flags
but the proposed patch only addresses part of that.  I could create a
sub-task (but I've never done that before) or a new bug or change the
description of this bug.  What do you think?

Re: Linux + Clang + execstack

[Martin Buchholz]

Unfortunately, my gmail marked Arthur's emails to this thread as spam,
with ensuing confusion.

I retargeted this fix to the new bug

8209817: stack is executable when building with Clang on Linux
http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/
https://bugs.openjdk.java.net/browse/JDK-8209817

and it made it through the submit repo tests.

Ready to submit this.

On Thu, Sep 13, 2018 at 2:10 PM, Magnus Ihse Bursie
 wrote:
>
>> We're not entirely happy either.
>>
>> A much higher interface might look like
>>
>> TRY_ADD_LINKER_FLAGS -z noexecstack
>
> Agreed. I'm working towards a solution like that.
>>
>> which would add -Wl,-z,noexecstack to LDFLAGS when appropriate
>>  hmmm ...
>> I only just noticed that both gcc and clang accept simply
>> $CC -z noexecstack
>> (it's even documented!)
>> Should we switch to that instead?
>
> No, I think it's better to keep -Wl,-z for consistency for all linker flags.
> Otherwise it just looks confusing.
>
> /Magnus
>
>
>>
>>
>>> Do you have a JBS issue?
>>
>> I have
>> https://bugs.openjdk.java.net/browse/JDK-8205457 gcc and clang should
>> use the same ld flags
>> but the proposed patch only addresses part of that.  I could create a
>> sub-task (but I've never done that before) or a new bug or change the
>> description of this bug.  What do you think?
>
>

Re: Linux + Clang + execstack

[Magnus Ihse Bursie]

We're not entirely happy either.

A much higher interface might look like

TRY_ADD_LINKER_FLAGS -z noexecstack

Agreed. I'm working towards a solution like that.

which would add -Wl,-z,noexecstack to LDFLAGS when appropriate
 hmmm ...
I only just noticed that both gcc and clang accept simply
$CC -z noexecstack
(it's even documented!)
Should we switch to that instead?
No, I think it's better to keep -Wl,-z for consistency for all linker 
flags. Otherwise it just looks confusing.


/Magnus





Do you have a JBS issue?

I have
https://bugs.openjdk.java.net/browse/JDK-8205457 gcc and clang should
use the same ld flags
but the proposed patch only addresses part of that.  I could create a
sub-task (but I've never done that before) or a new bug or change the
description of this bug.  What do you think?

Re: Linux + Clang + execstack

[Martin Buchholz]

On Thu, Sep 13, 2018 at 12:48 PM, Magnus Ihse Bursie
 wrote:

>>
>> http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/noexecstack.patch
>
> I'm not entirely happy, but it'll have to do. The problem here is that the
> underlying structure of the flags handling is still not good so this
> probably cannot be expressed better than this.

We're not entirely happy either.

A much higher interface might look like

TRY_ADD_LINKER_FLAGS -z noexecstack
which would add -Wl,-z,noexecstack to LDFLAGS when appropriate
 hmmm ...
I only just noticed that both gcc and clang accept simply
$CC -z noexecstack
(it's even documented!)
Should we switch to that instead?


> Do you have a JBS issue?

I have
https://bugs.openjdk.java.net/browse/JDK-8205457 gcc and clang should
use the same ld flags
but the proposed patch only addresses part of that.  I could create a
sub-task (but I've never done that before) or a new bug or change the
description of this bug.  What do you think?

Re: Linux + Clang + execstack

[Magnus Ihse Bursie]

On 2018-09-12 18:35, Martin Buchholz wrote:

On Wed, Sep 12, 2018 at 4:01 AM, Magnus Ihse Bursie
 wrote:

On 2018-09-05 20:59, Martin Buchholz wrote:

So ... Magnus, are you happy with the current state of the proposed patch?

I'm sorry Martin, but I can't figure out what the current state is. I tried
backtracking the discussion but failed. :( Can you please repost the
currently proposed patch?

http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/noexecstack.patch
I'm not entirely happy, but it'll have to do. The problem here is that 
the underlying structure of the flags handling is still not good so this 
probably cannot be expressed better than this.


Do you have a JBS issue?

/Magnus




On Tue, Sep 4, 2018 at 11:50 PM, Magnus Ihse Bursie
 wrote:


For the gcc toolchain this can not be the case:
# Minimum supported linker versions, empty means unspecified
TOOLCHAIN_MINIMUM_LD_VERSION_gcc="2.18"

We make sure we have an ld that supports the basic flags we assume.


feature tests are better than version tests.

I've heard that argument many times, and I've never agreed with it. In some
cases, feature tests work. They typically work if someone has designed a
clear API and included a feature test in it. A lot of additional POSIX
functionality works that way. This means that you can rest assure that if
the feature is present, then you know what you are going to get.

In most of the rest of the world, functionality does not raise to that
golden standard. Gcc adds a flag in one version, but it's buggy. A later
version fixes the bugs. A later version still changes the behavior of the
flag. Functionality that we depend on works or does not works depending on
the intersection of things like our code, compiler version, operating
system, and so on.

In my experience, it's a rare thing for a feature test to actually work.
Version tests, on the other hand, tests against a specific setup, that can
be tested and proven to work. The downside of version tests is that they are
often open-ended; we say that "anything above this version is supposed to
work", even though we have not tested with gcc 8 or 9. The alternative is to
say that "we've tested this between gcc 4.7 and 7.3 and will only support it
for this version span", but that is in most cases more likely to break when
gcc 8 comes along.

Specific version tests are in principle more accurate, but they
require a level of testing and maintenance that is unlikely to be seen
in the real world.  The received wisdom is that one should prefer
feature tests whenever possible and I agree with that as well, based
on decades of experience.

Sometimes you need something in between, e.g. replacing a
configure-time check with a run-time check.

Re: Linux + Clang + execstack

[Martin Buchholz]

On Wed, Sep 12, 2018 at 4:01 AM, Magnus Ihse Bursie
 wrote:
> On 2018-09-05 20:59, Martin Buchholz wrote:
>
> So ... Magnus, are you happy with the current state of the proposed patch?
>
> I'm sorry Martin, but I can't figure out what the current state is. I tried
> backtracking the discussion but failed. :( Can you please repost the
> currently proposed patch?

http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/noexecstack.patch

> On Tue, Sep 4, 2018 at 11:50 PM, Magnus Ihse Bursie
>  wrote:
>>
>>
>> For the gcc toolchain this can not be the case:
>> # Minimum supported linker versions, empty means unspecified
>> TOOLCHAIN_MINIMUM_LD_VERSION_gcc="2.18"
>>
>> We make sure we have an ld that supports the basic flags we assume.
>
>
> feature tests are better than version tests.
>
> I've heard that argument many times, and I've never agreed with it. In some
> cases, feature tests work. They typically work if someone has designed a
> clear API and included a feature test in it. A lot of additional POSIX
> functionality works that way. This means that you can rest assure that if
> the feature is present, then you know what you are going to get.
>
> In most of the rest of the world, functionality does not raise to that
> golden standard. Gcc adds a flag in one version, but it's buggy. A later
> version fixes the bugs. A later version still changes the behavior of the
> flag. Functionality that we depend on works or does not works depending on
> the intersection of things like our code, compiler version, operating
> system, and so on.
>
> In my experience, it's a rare thing for a feature test to actually work.
> Version tests, on the other hand, tests against a specific setup, that can
> be tested and proven to work. The downside of version tests is that they are
> often open-ended; we say that "anything above this version is supposed to
> work", even though we have not tested with gcc 8 or 9. The alternative is to
> say that "we've tested this between gcc 4.7 and 7.3 and will only support it
> for this version span", but that is in most cases more likely to break when
> gcc 8 comes along.

Specific version tests are in principle more accurate, but they
require a level of testing and maintenance that is unlikely to be seen
in the real world.  The received wisdom is that one should prefer
feature tests whenever possible and I agree with that as well, based
on decades of experience.

Sometimes you need something in between, e.g. replacing a
configure-time check with a run-time check.

Re: Linux + Clang + execstack

[Magnus Ihse Bursie]

On 2018-09-05 20:59, Martin Buchholz wrote:

So ... Magnus, are you happy with the current state of the proposed patch?
I'm sorry Martin, but I can't figure out what the current state is. I 
tried backtracking the discussion but failed. :( Can you please repost 
the currently proposed patch?





On Tue, Sep 4, 2018 at 11:50 PM, Magnus Ihse Bursie 
mailto:magnus.ihse.bur...@oracle.com>> 
wrote:



For the gcc toolchain this can not be the case:
# Minimum supported linker versions, empty means unspecified
TOOLCHAIN_MINIMUM_LD_VERSION_gcc="2.18"

We make sure we have an ld that supports the basic flags we assume.


feature tests are better than version tests.
I've heard that argument many times, and I've never agreed with it. In 
some cases, feature tests work. They typically work if someone has 
designed a clear API and included a feature test in it. A lot of 
additional POSIX functionality works that way. This means that you can 
rest assure that if the feature is present, then you know what you are 
going to get.


In most of the rest of the world, functionality does not raise to that 
golden standard. Gcc adds a flag in one version, but it's buggy. A later 
version fixes the bugs. A later version still changes the behavior of 
the flag. Functionality that we depend on works or does not works 
depending on the intersection of things like our code, compiler version, 
operating system, and so on.


In my experience, it's a rare thing for a feature test to actually work. 
Version tests, on the other hand, tests against a specific setup, that 
can be tested and proven to work. The downside of version tests is that 
they are often open-ended; we say that "anything above this version is 
supposed to work", even though we have not tested with gcc 8 or 9. The 
alternative is to say that "we've tested this between gcc 4.7 and 7.3 
and will only support it for this version span", but that is in most 
cases more likely to break when gcc 8 comes along.



Because there are various linkers in play (old GNU ld, gold, lld, 
macosx ld, BSD ld) and we'd like our compilers to work the same way on 
various platforms, I'm vaguely unhappy with 
TOOLCHAIN_MINIMUM_LD_VERSION_gcc. It looks 
like TOOLCHAIN_EXTRACT_LD_VERSION is another place where we conflate 
toolchains and operating systems.


The linker is often in a situation where it's conflated between 
toolchain and operating system. :-) I think it's more due to how the 
linker is positioned/perceived, than due to a fault of ours. On Windows, 
for instance, the linker is clearly a part of the toolchain. On solaris, 
there's a system linker and the solstudio does not distribute any linker 
on their own. On linux, the gcc toolchain actually allows you to select 
linker (gold, etc), but arguably they belong to the gcc toolchain rather 
than the OS.



We can add a similar check for the clang toolchain, if you want.

Mixing and matching compilers and linkers willy-nilly is not a
supported build option


As always, I am for portability and for toolchain competition.  I'd 
like to be able to build with Intel's icc toolchain.


That might be a noble goal, but it's not realistic. There's a huge cost 
involved with supporting different combinations; the combinatorial 
matrix blows up quickly, and if these different combinations are not 
regularly tested, they *will* break.


That being said, I'm too in general in favor of supporting more rather 
than less. But only as long as there's no high price to pay for the 
common/reasonable combinations.


/Magnus

Re: Linux + Clang + execstack

[Martin Buchholz]

So ... Magnus, are you happy with the current state of the proposed patch?

On Tue, Sep 4, 2018 at 11:50 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

>
> For the gcc toolchain this can not be the case:
> # Minimum supported linker versions, empty means unspecified
> TOOLCHAIN_MINIMUM_LD_VERSION_gcc="2.18"
>
> We make sure we have an ld that supports the basic flags we assume.
>

feature tests are better than version tests.  Because there are various
linkers in play (old GNU ld, gold, lld, macosx ld, BSD ld) and we'd like
our compilers to work the same way on various platforms, I'm vaguely
unhappy with TOOLCHAIN_MINIMUM_LD_VERSION_gcc.  It looks
like TOOLCHAIN_EXTRACT_LD_VERSION is another place where we conflate
toolchains and operating systems.


> We can add a similar check for the clang toolchain, if you want.
>
> Mixing and matching compilers and linkers willy-nilly is not a supported
> build option
>

As always, I am for portability and for toolchain competition.  I'd like to
be able to build with Intel's icc toolchain.

Re: Linux + Clang + execstack

[Magnus Ihse Bursie]

On 2018-09-05 04:06, Martin Buchholz wrote:

Here's Arthur's patch:

8205457: gcc and clang should use the same ld flags
http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/ 


https://bugs.openjdk.java.net/browse/JDK-8205457

This applies -Wl,-z,noexecstack uniformly to all linker invocations 
where applicable.


TODO:
All ld flags on Linux should be treated equally by gcc and clang


Just FYI: I'm on a long-term mission to clean up the flag handling in 
the entire build. There's a lot of weird stuff going on with the flags, 
like "why do we do like this on this platform, and like that on that 
platform? shouldn't they be the same?". And most of the time, yes, they 
probably should be the same. But at other times, there's a reason they 
are different and the difference is a deliberate bug fix. It takes time, 
effort and a lot of repository archeology to figure that out.


/Magnus

The test TestCheckJDK and supporting infrastructure should stop 
advertising itself as only dealing with libraries.

Maybe add GNU-stack annotations to all the Linux .s files as well?


On Tue, Sep 4, 2018 at 4:01 PM, Martin Buchholz > wrote:


I think we can all agree that passing flags to the linker to
ensure non-executable stack is the right thing to do.  But there's
a question whether *also* adding something to our assembly
language source files will be worth doing.  Neither mechanism is
sure to work.  For the linker flag, we need to be aware of and
test for the presence of the linker flag, but we might be using
some other linker... Similarly, we might end up using some other
assembler, or we might need to mark the assembly source file in a
different way than "GNU-stack".

On Tue, Aug 21, 2018 at 4:14 AM, Magnus Ihse Bursie
mailto:magnus.ihse.bur...@oracle.com>> wrote:

On 2018-08-21 02:03, David Holmes wrote:

On 21/08/2018 9:39 AM, Arthur Eubanks wrote:

On Mon, Aug 20, 2018 at 4:18 PM David Holmes
mailto:david.hol...@oracle.com>
>> wrote:

    Hi Arthur,

    cc'ing build-dev as this is currently a build issue.

    On 21/08/2018 3:11 AM, Arthur Eubanks wrote:
 > Hi,
 >
 > At Google we're trying to build hotspot on
Linux with clang. One
    thing that
 > happens is that the resulting libjvm.so is
stack executable. When
    running
 > hotspot we get warnings about the stack being
executable.
 >
 > Compiling an assembly file into the final .so
results in the
    stack being
 > executable. In this case the file is
linux_x86_64.s. This doesn't
    happen
 > with gcc because "-Wl,-z,noexecstack" is passed
as a hotspot
    linker flag
 > with gcc in flags-ldflags.m4. When using clang
that linker flag isn't
 > passed.
 >
 > Doing something like the solution in
 >
https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks

 > fixes the problem without the use of linker flags.

    You mean the source code directives for the linker?

Sorry, I wasn't specific enough, I meant the flags for
the assembler.
#if defined(__linux__) && defined(__ELF__)
.section        .note.GNU-stack, "", %progbits
#endif


    I think I prefer to see this handled explicitly in
the build as is
    currently done. Can we just adjust
./make/autoconf/flags-ldflags.m4 to
    pass the linker flags for gcc and clang?

I don't mind this solution, but it seems like the
right thing to do is to fix things at the source level
and remove extra unnecessary linker flags.


Personally I see this as source code pollution. The
concept of executable stacks has nothing to do with what
is being expressed by the source code, or the language
used for it.

Just my 2c. I'll defer to build folk ... though they are
still on vacation at the moment.


I agree with David. The executable stack is a build option.
Even if you change the source code so the 

Re: Linux + Clang + execstack

[Magnus Ihse Bursie]

On 2018-09-05 01:01, Martin Buchholz wrote:
I think we can all agree that passing flags to the linker to ensure 
non-executable stack is the right thing to do. But there's a question 
whether *also* adding something to our assembly language source files 
will be worth doing.  Neither mechanism is sure to work.  For the 
linker flag, we need to be aware of and test for the presence of the 
linker flag, but we might be using some other linker...


For the gcc toolchain this can not be the case:
# Minimum supported linker versions, empty means unspecified
TOOLCHAIN_MINIMUM_LD_VERSION_gcc="2.18"

We make sure we have an ld that supports the basic flags we assume.

We can add a similar check for the clang toolchain, if you want.

Mixing and matching compilers and linkers willy-nilly is not a supported 
build option, and there's no point in adding extra guards against such a 
thing. If you do that, and it turns out your build ended up broken, 
tough sh*t.


So I'll insist that adding the linker flag is sufficient to make sure 
this works, and that modifying the .s files are not necessary and will 
provide no benefit.


/Magnus


Similarly, we might end up using some other assembler, or we might 
need to mark the assembly source file in a different way than "GNU-stack".


On Tue, Aug 21, 2018 at 4:14 AM, Magnus Ihse Bursie 
mailto:magnus.ihse.bur...@oracle.com>> 
wrote:


On 2018-08-21 02:03, David Holmes wrote:

On 21/08/2018 9:39 AM, Arthur Eubanks wrote:

On Mon, Aug 20, 2018 at 4:18 PM David Holmes
mailto:david.hol...@oracle.com>
>> wrote:

    Hi Arthur,

    cc'ing build-dev as this is currently a build issue.

    On 21/08/2018 3:11 AM, Arthur Eubanks wrote:
 > Hi,
 >
 > At Google we're trying to build hotspot on Linux
with clang. One
    thing that
 > happens is that the resulting libjvm.so is stack
executable. When
    running
 > hotspot we get warnings about the stack being
executable.
 >
 > Compiling an assembly file into the final .so
results in the
    stack being
 > executable. In this case the file is
linux_x86_64.s. This doesn't
    happen
 > with gcc because "-Wl,-z,noexecstack" is passed as
a hotspot
    linker flag
 > with gcc in flags-ldflags.m4. When using clang that
linker flag isn't
 > passed.
 >
 > Doing something like the solution in
 >
https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks

 > fixes the problem without the use of linker flags.

    You mean the source code directives for the linker?

Sorry, I wasn't specific enough, I meant the flags for the
assembler.
#if defined(__linux__) && defined(__ELF__)
.section        .note.GNU-stack, "", %progbits
#endif


    I think I prefer to see this handled explicitly in the
build as is
    currently done. Can we just adjust
./make/autoconf/flags-ldflags.m4 to
    pass the linker flags for gcc and clang?

I don't mind this solution, but it seems like the right
thing to do is to fix things at the source level and
remove extra unnecessary linker flags.


Personally I see this as source code pollution. The concept of
executable stacks has nothing to do with what is being
expressed by the source code, or the language used for it.

Just my 2c. I'll defer to build folk ... though they are still
on vacation at the moment.


I agree with David. The executable stack is a build option. Even
if you change the source code so the compiler/assember does the
right thing, we would still want to keep the compiler option.
(Otherwise one day you'll end up with executable stacks due to
someone adding a new asm file and forgetting the "magic incantation".)

And, since we will keep the compiler option, there seems little
point in also adding this stuff to the asm files.

To address your concerns on clang: we should reasonably be giving
the same options to clang. There is no good reason, except for
oversight, that this is not done already. (Cleaning up and
unifying the compiler flags is an ongoing, but slowly moving,
process.) So the correct fix is to update flags-ldflags.m4.

/Magnus





I removed "-Wl,-z,noexecstack" from the flags after adding
the 

Re: Linux + Clang + execstack

[Mikael Vidstedt]

> On Sep 4, 2018, at 7:06 PM, Martin Buchholz  wrote:
> 
> Here's Arthur's patch:
> 
> 8205457: gcc and clang should use the same ld flags
> http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/
> https://bugs.openjdk.java.net/browse/JDK-8205457
> 
> This applies -Wl,-z,noexecstack uniformly to all linker invocations where
> applicable.
> 
> TODO:
> All ld flags on Linux should be treated equally by gcc and clang
> The test TestCheckJDK and supporting infrastructure should stop advertising
> itself as only dealing with libraries.
> Maybe add GNU-stack annotations to all the Linux .s files as well?

I like to think that our .s files are effectively incomplete, and that adding 
the annotations makes them less incomplete. I am, however, not emotionally 
attached to this so I’ll leave it up to you and others to decide what to do 
with it :)

(it would also be interesting to see if we can perhaps move some of the .s code 
to C++ instead)

Cheers,
Mikael

> 
> 
> On Tue, Sep 4, 2018 at 4:01 PM, Martin Buchholz  wrote:
> 
>> I think we can all agree that passing flags to the linker to ensure
>> non-executable stack is the right thing to do.  But there's a question
>> whether *also* adding something to our assembly language source files will
>> be worth doing.  Neither mechanism is sure to work.  For the linker flag,
>> we need to be aware of and test for the presence of the linker flag, but we
>> might be using some other linker... Similarly, we might end up using some
>> other assembler, or we might need to mark the assembly source file in a
>> different way than "GNU-stack".
>> 
>> On Tue, Aug 21, 2018 at 4:14 AM, Magnus Ihse Bursie <
>> magnus.ihse.bur...@oracle.com> wrote:
>> 
>>> On 2018-08-21 02:03, David Holmes wrote:
>>> 
 On 21/08/2018 9:39 AM, Arthur Eubanks wrote:
 
> On Mon, Aug 20, 2018 at 4:18 PM David Holmes  > wrote:
> 
>Hi Arthur,
> 
>cc'ing build-dev as this is currently a build issue.
> 
>On 21/08/2018 3:11 AM, Arthur Eubanks wrote:
>> Hi,
>> 
>> At Google we're trying to build hotspot on Linux with clang. One
>thing that
>> happens is that the resulting libjvm.so is stack executable. When
>running
>> hotspot we get warnings about the stack being executable.
>> 
>> Compiling an assembly file into the final .so results in the
>stack being
>> executable. In this case the file is linux_x86_64.s. This doesn't
>happen
>> with gcc because "-Wl,-z,noexecstack" is passed as a hotspot
>linker flag
>> with gcc in flags-ldflags.m4. When using clang that linker flag
> isn't
>> passed.
>> 
>> Doing something like the solution in
>> https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
>> fixes the problem without the use of linker flags.
> 
>You mean the source code directives for the linker?
> 
> Sorry, I wasn't specific enough, I meant the flags for the assembler.
> #if defined(__linux__) && defined(__ELF__)
> .section.note.GNU-stack, "", %progbits
> #endif
> 
> 
>I think I prefer to see this handled explicitly in the build as is
>currently done. Can we just adjust ./make/autoconf/flags-ldflags.m4
> to
>pass the linker flags for gcc and clang?
> 
> I don't mind this solution, but it seems like the right thing to do is
> to fix things at the source level and remove extra unnecessary linker 
> flags.
> 
 
 Personally I see this as source code pollution. The concept of
 executable stacks has nothing to do with what is being expressed by the
 source code, or the language used for it.
 
 Just my 2c. I'll defer to build folk ... though they are still on
 vacation at the moment.
 
>>> 
>>> I agree with David. The executable stack is a build option. Even if you
>>> change the source code so the compiler/assember does the right thing, we
>>> would still want to keep the compiler option. (Otherwise one day you'll end
>>> up with executable stacks due to someone adding a new asm file and
>>> forgetting the "magic incantation".)
>>> 
>>> And, since we will keep the compiler option, there seems little point in
>>> also adding this stuff to the asm files.
>>> 
>>> To address your concerns on clang: we should reasonably be giving the
>>> same options to clang. There is no good reason, except for oversight, that
>>> this is not done already. (Cleaning up and unifying the compiler flags is
>>> an ongoing, but slowly moving, process.) So the correct fix is to update
>>> flags-ldflags.m4.
>>> 
>>> /Magnus
>>> 
>>> 
>>> 
>>> 
>>> 
 I removed "-Wl,-z,noexecstack" from the flags after adding the above
> assembler flags and libjvm.so is still correctly not stack executable. I
> don't really mind either way though. Maybe it's good to have an extra
> safeguard in the linker flags.
> 

Re: Linux + Clang + execstack

[Martin Buchholz]

Here's Arthur's patch:

8205457: gcc and clang should use the same ld flags
http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/
https://bugs.openjdk.java.net/browse/JDK-8205457

This applies -Wl,-z,noexecstack uniformly to all linker invocations where
applicable.

TODO:
All ld flags on Linux should be treated equally by gcc and clang
The test TestCheckJDK and supporting infrastructure should stop advertising
itself as only dealing with libraries.
Maybe add GNU-stack annotations to all the Linux .s files as well?


On Tue, Sep 4, 2018 at 4:01 PM, Martin Buchholz  wrote:

> I think we can all agree that passing flags to the linker to ensure
> non-executable stack is the right thing to do.  But there's a question
> whether *also* adding something to our assembly language source files will
> be worth doing.  Neither mechanism is sure to work.  For the linker flag,
> we need to be aware of and test for the presence of the linker flag, but we
> might be using some other linker... Similarly, we might end up using some
> other assembler, or we might need to mark the assembly source file in a
> different way than "GNU-stack".
>
> On Tue, Aug 21, 2018 at 4:14 AM, Magnus Ihse Bursie <
> magnus.ihse.bur...@oracle.com> wrote:
>
>> On 2018-08-21 02:03, David Holmes wrote:
>>
>>> On 21/08/2018 9:39 AM, Arthur Eubanks wrote:
>>>
 On Mon, Aug 20, 2018 at 4:18 PM David Holmes >>> > wrote:

 Hi Arthur,

 cc'ing build-dev as this is currently a build issue.

 On 21/08/2018 3:11 AM, Arthur Eubanks wrote:
  > Hi,
  >
  > At Google we're trying to build hotspot on Linux with clang. One
 thing that
  > happens is that the resulting libjvm.so is stack executable. When
 running
  > hotspot we get warnings about the stack being executable.
  >
  > Compiling an assembly file into the final .so results in the
 stack being
  > executable. In this case the file is linux_x86_64.s. This doesn't
 happen
  > with gcc because "-Wl,-z,noexecstack" is passed as a hotspot
 linker flag
  > with gcc in flags-ldflags.m4. When using clang that linker flag
 isn't
  > passed.
  >
  > Doing something like the solution in
  > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
  > fixes the problem without the use of linker flags.

 You mean the source code directives for the linker?

 Sorry, I wasn't specific enough, I meant the flags for the assembler.
 #if defined(__linux__) && defined(__ELF__)
 .section.note.GNU-stack, "", %progbits
 #endif


 I think I prefer to see this handled explicitly in the build as is
 currently done. Can we just adjust ./make/autoconf/flags-ldflags.m4
 to
 pass the linker flags for gcc and clang?

 I don't mind this solution, but it seems like the right thing to do is
 to fix things at the source level and remove extra unnecessary linker 
 flags.

>>>
>>> Personally I see this as source code pollution. The concept of
>>> executable stacks has nothing to do with what is being expressed by the
>>> source code, or the language used for it.
>>>
>>> Just my 2c. I'll defer to build folk ... though they are still on
>>> vacation at the moment.
>>>
>>
>> I agree with David. The executable stack is a build option. Even if you
>> change the source code so the compiler/assember does the right thing, we
>> would still want to keep the compiler option. (Otherwise one day you'll end
>> up with executable stacks due to someone adding a new asm file and
>> forgetting the "magic incantation".)
>>
>> And, since we will keep the compiler option, there seems little point in
>> also adding this stuff to the asm files.
>>
>> To address your concerns on clang: we should reasonably be giving the
>> same options to clang. There is no good reason, except for oversight, that
>> this is not done already. (Cleaning up and unifying the compiler flags is
>> an ongoing, but slowly moving, process.) So the correct fix is to update
>> flags-ldflags.m4.
>>
>> /Magnus
>>
>>
>>
>>
>>
>>> I removed "-Wl,-z,noexecstack" from the flags after adding the above
 assembler flags and libjvm.so is still correctly not stack executable. I
 don't really mind either way though. Maybe it's good to have an extra
 safeguard in the linker flags.


  > The jtreg test test/hotspot/jtreg/runtime/exe
 cstack/TestCheckJDK.java
  > checks for the stack being executable.
  >
  > Any thoughts? If there are no objections, I can propose a patch
 that works
  > for both gcc and clang on Linux. Also, I'm not sure how/if macOS
 handles
  > this problem given that it uses clang.

 We don't seem to handle it at all on OS X. Does OS X prevent
 

Re: Linux + Clang + execstack

[Martin Buchholz]

I think we can all agree that passing flags to the linker to ensure
non-executable stack is the right thing to do.  But there's a question
whether *also* adding something to our assembly language source files will
be worth doing.  Neither mechanism is sure to work.  For the linker flag,
we need to be aware of and test for the presence of the linker flag, but we
might be using some other linker... Similarly, we might end up using some
other assembler, or we might need to mark the assembly source file in a
different way than "GNU-stack".

On Tue, Aug 21, 2018 at 4:14 AM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> On 2018-08-21 02:03, David Holmes wrote:
>
>> On 21/08/2018 9:39 AM, Arthur Eubanks wrote:
>>
>>> On Mon, Aug 20, 2018 at 4:18 PM David Holmes >> > wrote:
>>>
>>> Hi Arthur,
>>>
>>> cc'ing build-dev as this is currently a build issue.
>>>
>>> On 21/08/2018 3:11 AM, Arthur Eubanks wrote:
>>>  > Hi,
>>>  >
>>>  > At Google we're trying to build hotspot on Linux with clang. One
>>> thing that
>>>  > happens is that the resulting libjvm.so is stack executable. When
>>> running
>>>  > hotspot we get warnings about the stack being executable.
>>>  >
>>>  > Compiling an assembly file into the final .so results in the
>>> stack being
>>>  > executable. In this case the file is linux_x86_64.s. This doesn't
>>> happen
>>>  > with gcc because "-Wl,-z,noexecstack" is passed as a hotspot
>>> linker flag
>>>  > with gcc in flags-ldflags.m4. When using clang that linker flag
>>> isn't
>>>  > passed.
>>>  >
>>>  > Doing something like the solution in
>>>  > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
>>>  > fixes the problem without the use of linker flags.
>>>
>>> You mean the source code directives for the linker?
>>>
>>> Sorry, I wasn't specific enough, I meant the flags for the assembler.
>>> #if defined(__linux__) && defined(__ELF__)
>>> .section.note.GNU-stack, "", %progbits
>>> #endif
>>>
>>>
>>> I think I prefer to see this handled explicitly in the build as is
>>> currently done. Can we just adjust ./make/autoconf/flags-ldflags.m4
>>> to
>>> pass the linker flags for gcc and clang?
>>>
>>> I don't mind this solution, but it seems like the right thing to do is
>>> to fix things at the source level and remove extra unnecessary linker flags.
>>>
>>
>> Personally I see this as source code pollution. The concept of executable
>> stacks has nothing to do with what is being expressed by the source code,
>> or the language used for it.
>>
>> Just my 2c. I'll defer to build folk ... though they are still on
>> vacation at the moment.
>>
>
> I agree with David. The executable stack is a build option. Even if you
> change the source code so the compiler/assember does the right thing, we
> would still want to keep the compiler option. (Otherwise one day you'll end
> up with executable stacks due to someone adding a new asm file and
> forgetting the "magic incantation".)
>
> And, since we will keep the compiler option, there seems little point in
> also adding this stuff to the asm files.
>
> To address your concerns on clang: we should reasonably be giving the same
> options to clang. There is no good reason, except for oversight, that this
> is not done already. (Cleaning up and unifying the compiler flags is an
> ongoing, but slowly moving, process.) So the correct fix is to update
> flags-ldflags.m4.
>
> /Magnus
>
>
>
>
>
>> I removed "-Wl,-z,noexecstack" from the flags after adding the above
>>> assembler flags and libjvm.so is still correctly not stack executable. I
>>> don't really mind either way though. Maybe it's good to have an extra
>>> safeguard in the linker flags.
>>>
>>>
>>>  > The jtreg test test/hotspot/jtreg/runtime/exe
>>> cstack/TestCheckJDK.java
>>>  > checks for the stack being executable.
>>>  >
>>>  > Any thoughts? If there are no objections, I can propose a patch
>>> that works
>>>  > for both gcc and clang on Linux. Also, I'm not sure how/if macOS
>>> handles
>>>  > this problem given that it uses clang.
>>>
>>> We don't seem to handle it at all on OS X. Does OS X prevent
>>> executable
>>> stacks itself?
>>>
>>> A quick search, according to Wikipedia (https://en.wikipedia.org/wiki
>>> /Executable_space_protection#macOS), 64-bit executables on macOS aren't
>>> stack or heap executable. Not sure if that information is accurate though.
>>>
>>
>> Seems to be:
>>
>> https://developer.apple.com/library/archive/documentation/Se
>> curity/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html
>>
>> "macOS and iOS provide two features that can make it harder to exploit
>> stack and buffer overflows: address space layout randomization (ASLR) and a
>> non-executable stack and heap."
>>
>> Cheers,
>> David
>>
>>
>>> David
>>>
>>>
>

Re: Linux + Clang + execstack

[Arthur Eubanks]

Adding the linker flag sounds good.

Opened JDK-8209817.

webrev coming soon.

On Tue, Aug 21, 2018 at 4:14 AM Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> On 2018-08-21 02:03, David Holmes wrote:
> > On 21/08/2018 9:39 AM, Arthur Eubanks wrote:
> >> On Mon, Aug 20, 2018 at 4:18 PM David Holmes  >> > wrote:
> >>
> >> Hi Arthur,
> >>
> >> cc'ing build-dev as this is currently a build issue.
> >>
> >> On 21/08/2018 3:11 AM, Arthur Eubanks wrote:
> >>  > Hi,
> >>  >
> >>  > At Google we're trying to build hotspot on Linux with clang. One
> >> thing that
> >>  > happens is that the resulting libjvm.so is stack executable. When
> >> running
> >>  > hotspot we get warnings about the stack being executable.
> >>  >
> >>  > Compiling an assembly file into the final .so results in the
> >> stack being
> >>  > executable. In this case the file is linux_x86_64.s. This doesn't
> >> happen
> >>  > with gcc because "-Wl,-z,noexecstack" is passed as a hotspot
> >> linker flag
> >>  > with gcc in flags-ldflags.m4. When using clang that linker
> >> flag isn't
> >>  > passed.
> >>  >
> >>  > Doing something like the solution in
> >>  > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
> >>  > fixes the problem without the use of linker flags.
> >>
> >> You mean the source code directives for the linker?
> >>
> >> Sorry, I wasn't specific enough, I meant the flags for the assembler.
> >> #if defined(__linux__) && defined(__ELF__)
> >> .section.note.GNU-stack, "", %progbits
> >> #endif
> >>
> >>
> >> I think I prefer to see this handled explicitly in the build as is
> >> currently done. Can we just adjust
> >> ./make/autoconf/flags-ldflags.m4 to
> >> pass the linker flags for gcc and clang?
> >>
> >> I don't mind this solution, but it seems like the right thing to do
> >> is to fix things at the source level and remove extra unnecessary
> >> linker flags.
> >
> > Personally I see this as source code pollution. The concept of
> > executable stacks has nothing to do with what is being expressed by
> > the source code, or the language used for it.
> >
> > Just my 2c. I'll defer to build folk ... though they are still on
> > vacation at the moment.
>
> I agree with David. The executable stack is a build option. Even if you
> change the source code so the compiler/assember does the right thing, we
> would still want to keep the compiler option. (Otherwise one day you'll
> end up with executable stacks due to someone adding a new asm file and
> forgetting the "magic incantation".)
>
> And, since we will keep the compiler option, there seems little point in
> also adding this stuff to the asm files.
>
> To address your concerns on clang: we should reasonably be giving the
> same options to clang. There is no good reason, except for oversight,
> that this is not done already. (Cleaning up and unifying the compiler
> flags is an ongoing, but slowly moving, process.) So the correct fix is
> to update flags-ldflags.m4.
>
> /Magnus
>
>
>
> >
> >> I removed "-Wl,-z,noexecstack" from the flags after adding the above
> >> assembler flags and libjvm.so is still correctly not stack
> >> executable. I don't really mind either way though. Maybe it's good to
> >> have an extra safeguard in the linker flags.
> >>
> >>
> >>  > The jtreg test
> >> test/hotspot/jtreg/runtime/execstack/TestCheckJDK.java
> >>  > checks for the stack being executable.
> >>  >
> >>  > Any thoughts? If there are no objections, I can propose a patch
> >> that works
> >>  > for both gcc and clang on Linux. Also, I'm not sure how/if macOS
> >> handles
> >>  > this problem given that it uses clang.
> >>
> >> We don't seem to handle it at all on OS X. Does OS X prevent
> >> executable
> >> stacks itself?
> >>
> >> A quick search, according to Wikipedia
> >> (https://en.wikipedia.org/wiki/Executable_space_protection#macOS),
> >> 64-bit executables on macOS aren't stack or heap executable. Not sure
> >> if that information is accurate though.
> >
> > Seems to be:
> >
> >
> https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html
> >
> >
> > "macOS and iOS provide two features that can make it harder to exploit
> > stack and buffer overflows: address space layout randomization (ASLR)
> > and a non-executable stack and heap."
> >
> > Cheers,
> > David
> >
> >>
> >> David
> >>
>
>

Re: Linux + Clang + execstack

[Magnus Ihse Bursie]

On 2018-08-21 02:03, David Holmes wrote:

On 21/08/2018 9:39 AM, Arthur Eubanks wrote:
On Mon, Aug 20, 2018 at 4:18 PM David Holmes > wrote:


    Hi Arthur,

    cc'ing build-dev as this is currently a build issue.

    On 21/08/2018 3:11 AM, Arthur Eubanks wrote:
 > Hi,
 >
 > At Google we're trying to build hotspot on Linux with clang. One
    thing that
 > happens is that the resulting libjvm.so is stack executable. When
    running
 > hotspot we get warnings about the stack being executable.
 >
 > Compiling an assembly file into the final .so results in the
    stack being
 > executable. In this case the file is linux_x86_64.s. This doesn't
    happen
 > with gcc because "-Wl,-z,noexecstack" is passed as a hotspot
    linker flag
 > with gcc in flags-ldflags.m4. When using clang that linker 
flag isn't

 > passed.
 >
 > Doing something like the solution in
 > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
 > fixes the problem without the use of linker flags.

    You mean the source code directives for the linker?

Sorry, I wasn't specific enough, I meant the flags for the assembler.
#if defined(__linux__) && defined(__ELF__)
.section        .note.GNU-stack, "", %progbits
#endif


    I think I prefer to see this handled explicitly in the build as is
    currently done. Can we just adjust 
./make/autoconf/flags-ldflags.m4 to

    pass the linker flags for gcc and clang?

I don't mind this solution, but it seems like the right thing to do 
is to fix things at the source level and remove extra unnecessary 
linker flags.


Personally I see this as source code pollution. The concept of 
executable stacks has nothing to do with what is being expressed by 
the source code, or the language used for it.


Just my 2c. I'll defer to build folk ... though they are still on 
vacation at the moment.


I agree with David. The executable stack is a build option. Even if you 
change the source code so the compiler/assember does the right thing, we 
would still want to keep the compiler option. (Otherwise one day you'll 
end up with executable stacks due to someone adding a new asm file and 
forgetting the "magic incantation".)


And, since we will keep the compiler option, there seems little point in 
also adding this stuff to the asm files.


To address your concerns on clang: we should reasonably be giving the 
same options to clang. There is no good reason, except for oversight, 
that this is not done already. (Cleaning up and unifying the compiler 
flags is an ongoing, but slowly moving, process.) So the correct fix is 
to update flags-ldflags.m4.


/Magnus





I removed "-Wl,-z,noexecstack" from the flags after adding the above 
assembler flags and libjvm.so is still correctly not stack 
executable. I don't really mind either way though. Maybe it's good to 
have an extra safeguard in the linker flags.



 > The jtreg test 
test/hotspot/jtreg/runtime/execstack/TestCheckJDK.java

 > checks for the stack being executable.
 >
 > Any thoughts? If there are no objections, I can propose a patch
    that works
 > for both gcc and clang on Linux. Also, I'm not sure how/if macOS
    handles
 > this problem given that it uses clang.

    We don't seem to handle it at all on OS X. Does OS X prevent 
executable

    stacks itself?

A quick search, according to Wikipedia 
(https://en.wikipedia.org/wiki/Executable_space_protection#macOS), 
64-bit executables on macOS aren't stack or heap executable. Not sure 
if that information is accurate though.


Seems to be:

https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html 



"macOS and iOS provide two features that can make it harder to exploit 
stack and buffer overflows: address space layout randomization (ASLR) 
and a non-executable stack and heap."


Cheers,
David



    David

Re: Linux + Clang + execstack

[David Holmes]

On 21/08/2018 4:29 PM, Mikael Vidstedt wrote:
On Aug 20, 2018, at 5:03 PM, David Holmes > wrote:


On 21/08/2018 9:39 AM, Arthur Eubanks wrote:
On Mon, Aug 20, 2018 at 4:18 PM David Holmes  > wrote:

   Hi Arthur,
   cc'ing build-dev as this is currently a build issue.
   On 21/08/2018 3:11 AM, Arthur Eubanks wrote:
> Hi,
>
> At Google we're trying to build hotspot on Linux with clang. One
   thing that
> happens is that the resulting libjvm.so is stack executable. When
   running
> hotspot we get warnings about the stack being executable.
>
> Compiling an assembly file into the final .so results in the
   stack being
> executable. In this case the file is linux_x86_64.s. This doesn't
   happen
> with gcc because "-Wl,-z,noexecstack" is passed as a hotspot
   linker flag
> with gcc in flags-ldflags.m4. When using clang that linker flag 
isn't

> passed.
>
> Doing something like the solution in
> https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
> fixes the problem without the use of linker flags.
   You mean the source code directives for the linker?
Sorry, I wasn't specific enough, I meant the flags for the assembler.
#if defined(__linux__) && defined(__ELF__)
.section        .note.GNU-stack, "", %progbits
#endif
   I think I prefer to see this handled explicitly in the build as is
   currently done. Can we just adjust ./make/autoconf/flags-ldflags.m4 to
   pass the linker flags for gcc and clang?
I don't mind this solution, but it seems like the right thing to do 
is to fix things at the source level and remove extra unnecessary 
linker flags.


Personally I see this as source code pollution. The concept of 
executable stacks has nothing to do with what is being expressed by 
the source code, or the language used for it.


Just my 2c. I'll defer to build folk ... though they are still on 
vacation at the moment.


Control question: why doesn’t the compiled .cpp files provoke the 
executable stack problem? After all, they’re also an assembly file 
somewhere on the way from .cpp to object file.


Either gcc does something or else ld does something based on the 
noexecstack build flags we use.


I’m guessing it’s because gcc does insert the .note.GNU-stack directive. 
If so, it seems reasonable to me to require/expect our assembly files to 
include that directive as well?


If gcc inserts something in a .o from a .cpp file then I would expect 
the assembler (gas? or still gcc?) to insert something in a .o from a .s 
file.


David


Cheers,
Mikael



I removed "-Wl,-z,noexecstack" from the flags after adding the above 
assembler flags and libjvm.so is still correctly not stack 
executable. I don't really mind either way though. Maybe it's good to 
have an extra safeguard in the linker flags.
> The jtreg test 
test/hotspot/jtreg/runtime/execstack/TestCheckJDK.java

> checks for the stack being executable.
>
> Any thoughts? If there are no objections, I can propose a patch
   that works
> for both gcc and clang on Linux. Also, I'm not sure how/if macOS
   handles
> this problem given that it uses clang.
   We don't seem to handle it at all on OS X. Does OS X prevent 
executable

   stacks itself?
A quick search, according to Wikipedia 
(https://en.wikipedia.org/wiki/Executable_space_protection#macOS), 
64-bit executables on macOS aren't stack or heap executable. Not sure 
if that information is accurate though.


Seems to be:

https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html

"macOS and iOS provide two features that can make it harder to exploit 
stack and buffer overflows: address space layout randomization (ASLR) 
and a non-executable stack and heap."


Cheers,
David


   David

Re: Linux + Clang + execstack

[Mikael Vidstedt]

> On Aug 20, 2018, at 5:03 PM, David Holmes  wrote:
> 
> On 21/08/2018 9:39 AM, Arthur Eubanks wrote:
>> On Mon, Aug 20, 2018 at 4:18 PM David Holmes > > wrote:
>>Hi Arthur,
>>cc'ing build-dev as this is currently a build issue.
>>On 21/08/2018 3:11 AM, Arthur Eubanks wrote:
>> > Hi,
>> >
>> > At Google we're trying to build hotspot on Linux with clang. One
>>thing that
>> > happens is that the resulting libjvm.so is stack executable. When
>>running
>> > hotspot we get warnings about the stack being executable.
>> >
>> > Compiling an assembly file into the final .so results in the
>>stack being
>> > executable. In this case the file is linux_x86_64.s. This doesn't
>>happen
>> > with gcc because "-Wl,-z,noexecstack" is passed as a hotspot
>>linker flag
>> > with gcc in flags-ldflags.m4. When using clang that linker flag isn't
>> > passed.
>> >
>> > Doing something like the solution in
>> > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
>> > fixes the problem without the use of linker flags.
>>You mean the source code directives for the linker?
>> Sorry, I wasn't specific enough, I meant the flags for the assembler.
>> #if defined(__linux__) && defined(__ELF__)
>> .section.note.GNU-stack, "", %progbits
>> #endif
>>I think I prefer to see this handled explicitly in the build as is
>>currently done. Can we just adjust ./make/autoconf/flags-ldflags.m4 to
>>pass the linker flags for gcc and clang?
>> I don't mind this solution, but it seems like the right thing to do is to 
>> fix things at the source level and remove extra unnecessary linker flags.
> 
> Personally I see this as source code pollution. The concept of executable 
> stacks has nothing to do with what is being expressed by the source code, or 
> the language used for it.
> 
> Just my 2c. I'll defer to build folk ... though they are still on vacation at 
> the moment.

Control question: why doesn’t the compiled .cpp files provoke the executable 
stack problem? After all, they’re also an assembly file somewhere on the way 
from .cpp to object file.

I’m guessing it’s because gcc does insert the .note.GNU-stack directive. If so, 
it seems reasonable to me to require/expect our assembly files to include that 
directive as well?

Cheers,
Mikael

> 
>> I removed "-Wl,-z,noexecstack" from the flags after adding the above 
>> assembler flags and libjvm.so is still correctly not stack executable. I 
>> don't really mind either way though. Maybe it's good to have an extra 
>> safeguard in the linker flags.
>> > The jtreg test test/hotspot/jtreg/runtime/execstack/TestCheckJDK.java
>> > checks for the stack being executable.
>> >
>> > Any thoughts? If there are no objections, I can propose a patch
>>that works
>> > for both gcc and clang on Linux. Also, I'm not sure how/if macOS
>>handles
>> > this problem given that it uses clang.
>>We don't seem to handle it at all on OS X. Does OS X prevent executable
>>stacks itself?
>> A quick search, according to Wikipedia 
>> (https://en.wikipedia.org/wiki/Executable_space_protection#macOS 
>> ), 64-bit 
>> executables on macOS aren't stack or heap executable. Not sure if that 
>> information is accurate though.
> 
> Seems to be:
> 
> https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html
>  
> 
> 
> "macOS and iOS provide two features that can make it harder to exploit stack 
> and buffer overflows: address space layout randomization (ASLR) and a 
> non-executable stack and heap."
> 
> Cheers,
> David
> 
>>David

Re: Linux + Clang + execstack

[David Holmes]

On 21/08/2018 9:39 AM, Arthur Eubanks wrote:
On Mon, Aug 20, 2018 at 4:18 PM David Holmes > wrote:


Hi Arthur,

cc'ing build-dev as this is currently a build issue.

On 21/08/2018 3:11 AM, Arthur Eubanks wrote:
 > Hi,
 >
 > At Google we're trying to build hotspot on Linux with clang. One
thing that
 > happens is that the resulting libjvm.so is stack executable. When
running
 > hotspot we get warnings about the stack being executable.
 >
 > Compiling an assembly file into the final .so results in the
stack being
 > executable. In this case the file is linux_x86_64.s. This doesn't
happen
 > with gcc because "-Wl,-z,noexecstack" is passed as a hotspot
linker flag
 > with gcc in flags-ldflags.m4. When using clang that linker flag isn't
 > passed.
 >
 > Doing something like the solution in
 > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
 > fixes the problem without the use of linker flags.

You mean the source code directives for the linker?

Sorry, I wasn't specific enough, I meant the flags for the assembler.
#if defined(__linux__) && defined(__ELF__)
.section        .note.GNU-stack, "", %progbits
#endif


I think I prefer to see this handled explicitly in the build as is
currently done. Can we just adjust ./make/autoconf/flags-ldflags.m4 to
pass the linker flags for gcc and clang?

I don't mind this solution, but it seems like the right thing to do is 
to fix things at the source level and remove extra unnecessary linker 
flags.


Personally I see this as source code pollution. The concept of 
executable stacks has nothing to do with what is being expressed by the 
source code, or the language used for it.


Just my 2c. I'll defer to build folk ... though they are still on 
vacation at the moment.


I removed "-Wl,-z,noexecstack" from the flags after adding the 
above assembler flags and libjvm.so is still correctly not stack 
executable. I don't really mind either way though. Maybe it's good to 
have an extra safeguard in the linker flags.



 > The jtreg test test/hotspot/jtreg/runtime/execstack/TestCheckJDK.java
 > checks for the stack being executable.
 >
 > Any thoughts? If there are no objections, I can propose a patch
that works
 > for both gcc and clang on Linux. Also, I'm not sure how/if macOS
handles
 > this problem given that it uses clang.

We don't seem to handle it at all on OS X. Does OS X prevent executable
stacks itself?

A quick search, according to Wikipedia 
(https://en.wikipedia.org/wiki/Executable_space_protection#macOS), 
64-bit executables on macOS aren't stack or heap executable. Not sure if 
that information is accurate though.


Seems to be:

https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html

"macOS and iOS provide two features that can make it harder to exploit 
stack and buffer overflows: address space layout randomization (ASLR) 
and a non-executable stack and heap."


Cheers,
David



David

Re: Linux + Clang + execstack

[David Holmes]

Hi Arthur,

cc'ing build-dev as this is currently a build issue.

On 21/08/2018 3:11 AM, Arthur Eubanks wrote:

Hi,

At Google we're trying to build hotspot on Linux with clang. One thing that
happens is that the resulting libjvm.so is stack executable. When running
hotspot we get warnings about the stack being executable.

Compiling an assembly file into the final .so results in the stack being
executable. In this case the file is linux_x86_64.s. This doesn't happen
with gcc because "-Wl,-z,noexecstack" is passed as a hotspot linker flag
with gcc in flags-ldflags.m4. When using clang that linker flag isn't
passed.

Doing something like the solution in
https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
fixes the problem without the use of linker flags.


You mean the source code directives for the linker?

I think I prefer to see this handled explicitly in the build as is 
currently done. Can we just adjust ./make/autoconf/flags-ldflags.m4 to 
pass the linker flags for gcc and clang?



The jtreg test test/hotspot/jtreg/runtime/execstack/TestCheckJDK.java
checks for the stack being executable.

Any thoughts? If there are no objections, I can propose a patch that works
for both gcc and clang on Linux. Also, I'm not sure how/if macOS handles
this problem given that it uses clang.


We don't seem to handle it at all on OS X. Does OS X prevent executable 
stacks itself?


David