I'm not into the details of ELF and object file stacks, but Gentoo Linux gives me some QA warnings about executable writable sections. A Gentoo hacker helped me by writing a patch to dmd and the security warnings are now gone.

See http://d.puremagic.com/issues/show_bug.cgi?id=6387 for details.

I posted here to shed some light on the issue. GNU C closures need an executable stack, but D doesn't. Would there be any other feature that require executable stacks? If yes, then an option to disable these features and make the stacks non-executable would help. And why is it anyway that each object file has a stack of it's own? I thought stacks were a per-thread thing?

Best regards,
Marco

On 7/26/2011 6:45 PM, Marco Leise wrote:
> I'm not into the details of ELF and object file stacks, but Gentoo Linux gives
> me some QA warnings about executable writable sections. A Gentoo hacker helped
> me by writing a patch to dmd and the security warnings are now gone.
>
> See http://d.puremagic.com/issues/show_bug.cgi?id=6387 for details.
>
> I posted here to shed some light on the issue. GNU C closures need an executable
> stack, but D doesn't. Would there be any other feature that require executable
> stacks?

Not at the moment.

> If yes, then an option to disable these features and make the stacks
> non-executable would help. And why is it anyway that each object file has a
> stack of it's own? I thought stacks were a per-thread thing?

Object files don't have their own stacks. I don't know what you're referring to.

On 7/26/2011 6:45 PM, Marco Leise wrote:
> I'm not into the details of ELF and object file stacks, but Gentoo Linux gives
> me some QA warnings about executable writable sections. A Gentoo hacker helped
> me by writing a patch to dmd and the security warnings are now gone.
>
> See http://d.puremagic.com/issues/show_bug.cgi?id=6387 for details.

If you (or someone else) would like to do this as a pull request, I'd be happy to fold it in.

On 7/26/2011 6:51 PM, Walter Bright wrote:
> On 7/26/2011 6:45 PM, Marco Leise wrote:
>> I'm not into the details of ELF and object file stacks, but Gentoo Linux gives
>> me some QA warnings about executable writable sections. A Gentoo hacker helped
>> me by writing a patch to dmd and the security warnings are now gone.
>>
>> See http://d.puremagic.com/issues/show_bug.cgi?id=6387 for details.
>>
>> I posted here to shed some light on the issue. GNU C closures need an executable
>> stack, but D doesn't. Would there be any other feature that require executable
>> stacks?
>
> Not at the moment.


Hmm. D is supposed to link with gcc code, so that could be an issue.

Walter:

> Hmm. D is supposed to link with gcc code, so that could be an issue.

How?

Is the D GC eventually in need for some hardening? This is highly technical stuff: http://blogs.technet.com/b/srd/archive/2009/08/04/preventing-the-exploitation-of-user-mode-heap-corruption-vulnerabilities.aspx

Bye,
bearophile

Am 27.07.2011, 03:51 Uhr, schrieb Walter Bright <newshound2@digitalmars.com>:

> On 7/26/2011 6:45 PM, Marco Leise wrote:
>> I'm not into the details of ELF and object file stacks, but Gentoo Linux gives
>> me some QA warnings about executable writable sections. A Gentoo hacker helped
>> me by writing a patch to dmd and the security warnings are now gone.
>>
>> See http://d.puremagic.com/issues/show_bug.cgi?id=6387 for details.
>>
>> I posted here to shed some light on the issue. GNU C closures need an executable
>> stack, but D doesn't. Would there be any other feature that require executable
>> stacks?
>
> Not at the moment.

Thank you for the info. That means when compiling the source this is a valid patch.

>> If yes, then an option to disable these features and make the stacks
>> non-executable would help. And why is it anyway that each object file has a
>> stack of it's own? I thought stacks were a per-thread thing?
>
> Object files don't have their own stacks. I don't know what you're referring to.

I was wondering why scanelf was printing out lines for every object file in the libraries and read sentences like "Sure enough, these objects lack the .note.GNU-stack ELF section and they are linked into the final libsmpeg.so library." That made me assume that each object file can have this section and thus must have an own stack.
Anyway me and Andrei wanted to at least notify you about this and that's done now. It seemed somewhat me, like when an old lady sees a fake website pop-up a virus warning.

*[...] It seemed somewhat urgent to me, [...]

On 7/26/2011 7:06 PM, bearophile wrote:
> Walter:
>
>> Hmm. D is supposed to link with gcc code, so that could be an issue.
>
> How?

I believe Marco explained that: "GNU C closures need an executable stack"


> Is the D GC eventually in need for some hardening? This is highly technical stuff:

It's not that technical.


> http://blogs.technet.com/b/srd/archive/2009/08/04/preventing-the-exploitation-of-user-mode-heap-corruption-vulnerabilities.aspx

D relies more on memory safety guarantees of the language rather than after-the-fact damage control. A well written D program will have very little unsafe code in it, whereas it's pretty much impossible to do that in C or C++, as they rely so heavily on pointer arithmetic.

On 7/26/2011 9:12 PM, Walter Bright wrote:
> D relies more on memory safety guarantees of the language rather than
> after-the-fact damage control. A well written D program will have very little
> unsafe code in it, whereas it's pretty much impossible to do that in C or C++,
> as they rely so heavily on pointer arithmetic.

I should clarify that. If you write C style code in D, yes, your code is not verifiably safe and hence your programs could be susceptible to malicious attacks based on buffer overflow exploits.

But, if you write in D style, using arrays, ranges, and other safe data structures, the risk of your program being vulnerable to such exploits is reduced enormously.

Walter Bright Wrote:

> I should clarify that. If you write C style code in D, yes, your code is not verifiably safe and hence your programs could be susceptible to malicious attacks based on buffer overflow exploits.
> 
> But, if you write in D style, using arrays, ranges, and other safe data structures, the risk of your program being vulnerable to such exploits is reduced enormously.

Do you consider code working with arrays and compiled in release mode safe?