I stumbled upon this Wikipedia page:
http://en.wikipedia.org/wiki/Compari...urity_features
and it mentions NX bit is supported in FreeBSD. Is this true? Is it
enabled by default?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiwpYIACgkQldnAQVacBcgJwACg7EIZWgJKjD iFxisNS5oi8eAS
bmEAoPUx8jpeJOJQ7AiYUXg6Bi1xU7mH
=uWfx
-----END PGP SIGNATURE-----

On Sat, Aug 23, 2008 at 5:04 PM, Ivan Voras wrote:
> I stumbled upon this Wikipedia page:
> http://en.wikipedia.org/wiki/Compari...urity_features
> and it mentions NX bit is supported in FreeBSD. Is this true? Is it
> enabled by default?

Yes. However, it is in the upper word so it only works with PAE or
amd64. "jemalloc" maps the heap NX and thread stacks are mapped NX.
The default process stack currently needs to be executable because
sigcode is placed at the start of the stack at the time of process
creation.

-Kip
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

On Sat, Aug 23, 2008 at 05:13:30PM -0700, Matthew Macy wrote:
> On Sat, Aug 23, 2008 at 5:04 PM, Ivan Voras wrote:
> > I stumbled upon this Wikipedia page:
> > http://en.wikipedia.org/wiki/Compari...urity_features
> > and it mentions NX bit is supported in FreeBSD. Is this true? Is it
> > enabled by default?
>
> Yes. However, it is in the upper word so it only works with PAE or
> amd64. "jemalloc" maps the heap NX and thread stacks are mapped NX.
> The default process stack currently needs to be executable because
> sigcode is placed at the start of the stack at the time of process
> creation.

Oh, I was looking into this a few months ago, and came to the
conclusion that NX wasn't turned on at all.

How do applications/languages that use JIT or other run-time
code generation get around the non-executable heap? Just not
use jemalloc?

I've been using 7-STABLE on amd64 for a long time, and haven't
noticed any problems with Java or SBCL lisp or PLT-scheme, all
of which use JIT code generation (but probably neither use
jemalloc?)

Cheers,

--
Andrew
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

* Andrew Reilly [080826 00:51] wrote:
> On Sat, Aug 23, 2008 at 05:13:30PM -0700, Matthew Macy wrote:
> > On Sat, Aug 23, 2008 at 5:04 PM, Ivan Voras wrote:
> > > I stumbled upon this Wikipedia page:
> > > http://en.wikipedia.org/wiki/Compari...urity_features
> > > and it mentions NX bit is supported in FreeBSD. Is this true? Is it
> > > enabled by default?
> >
> > Yes. However, it is in the upper word so it only works with PAE or
> > amd64. "jemalloc" maps the heap NX and thread stacks are mapped NX.
> > The default process stack currently needs to be executable because
> > sigcode is placed at the start of the stack at the time of process
> > creation.
>
> Oh, I was looking into this a few months ago, and came to the
> conclusion that NX wasn't turned on at all.
>
> How do applications/languages that use JIT or other run-time
> code generation get around the non-executable heap? Just not
> use jemalloc?
>
> I've been using 7-STABLE on amd64 for a long time, and haven't
> noticed any problems with Java or SBCL lisp or PLT-scheme, all
> of which use JIT code generation (but probably neither use
> jemalloc?)

mprotect(2)?

--
- Alfred Perlstein
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

On Tue, Aug 26, 2008 at 09:28:07AM -0700, Alfred Perlstein wrote:
> * Andrew Reilly [080826 00:51] wrote:
> > I've been using 7-STABLE on amd64 for a long time, and haven't
> > noticed any problems with Java or SBCL lisp or PLT-scheme, all
> > of which use JIT code generation (but probably neither use
> > jemalloc?)
>
> mprotect(2)?

Fair enough. Good to know that it's actually tweaking the NX
permissions, I guess. The man page seems a little vague about
when it might succeed, and what effect it might have...

Cheers,

--
Andrew
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

On Wed, 27 Aug 2008, Andrew Reilly wrote:

> On Tue, Aug 26, 2008 at 09:28:07AM -0700, Alfred Perlstein wrote:
>> * Andrew Reilly [080826 00:51]
>> wrote:
>>> I've been using 7-STABLE on amd64 for a long time, and haven't noticed any
>>> problems with Java or SBCL lisp or PLT-scheme, all of which use JIT code
>>> generation (but probably neither use jemalloc?)
>>
>> mprotect(2)?
>
> Fair enough. Good to know that it's actually tweaking the NX permissions, I
> guess. The man page seems a little vague about when it might succeed, and
> what effect it might have...

We're behind on the not-mapping-writable stuff, so for better (and worse)
quite a few such things in application have been faulted in by other operating
systems already. That doesn't mean there won't be issues, but does have the
redeeming aspect that things should be less bumpy for us going forward.
Hopefully we can start making that progress a bit more quickly...

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

On Wed, Aug 27, 2008 at 2:10 AM, Robert Watson wrote:
> On Wed, 27 Aug 2008, Andrew Reilly wrote:
>
>> On Tue, Aug 26, 2008 at 09:28:07AM -0700, Alfred Perlstein wrote:
>>>
>>> * Andrew Reilly [080826 00:51]
>>> wrote:
>>>>
>>>> I've been using 7-STABLE on amd64 for a long time, and haven't noticed
>>>> any problems with Java or SBCL lisp or PLT-scheme, all of which use JIT code
>>>> generation (but probably neither use jemalloc?)
>>>
>>> mprotect(2)?
>>
>> Fair enough. Good to know that it's actually tweaking the NX permissions,
>> I guess. The man page seems a little vague about when it might succeed, and
>> what effect it might have...
>
> We're behind on the not-mapping-writable stuff, so for better (and worse)
> quite a few such things in application have been faulted in by other
> operating systems already. That doesn't mean there won't be issues, but
> does have the redeeming aspect that things should be less bumpy for us going
> forward. Hopefully we can start making that progress a bit more quickly...

I recall seeing config.h code chunks to turn sections of the stack
on/off for execution on (I think) sparc64. It might have been for
netbsd. If my memory serves correctly, libgcc grew code to do
mprotect(), and the gcc code generator would call it as appropriate
when it needed to do its magic. I think this was for an older version
of gcc though.


--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"