FBSD & NX-Bit - BSD

This is a discussion on FBSD & NX-Bit - BSD ; I have a question. Is NX-bit enabled by default in FBSD using AMD64? The NX bit, which stands for No eXecute, is a technology used in CPUs to segregate areas of memory for use by either storage of processor instructions ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: FBSD & NX-Bit

  1. FBSD & NX-Bit

    I have a question. Is NX-bit enabled by default in FBSD using AMD64?

    The NX bit, which stands for No eXecute, is a technology used in CPUs to segregate areas of memory for use by either storage of processor instructions (or code) or for storage of data, a feature normally only found in Harvard architecture processors. However, the NX bit is being increasingly used in conventional von Neumann architecture processors, for security reasons.

    Any section of memory designated with the NX attribute means that it may only be used for storing data, so that processor instructions should not reside there, and cannot be executed if they do. The general technique, known as executable space protection, is used to prevent certain types of malicious software from taking over computers by inserting their code into another program's data storage area and running their own code from within this section; this is known as a buffer overflow attack.

    Intel has decided to market the feature as the XD bit, for eXecute
    Disable. However, Intel's XD bit and AMD's NX bit perform the same
    function and are different only in name.
    http://en.wikipedia.org/wiki/NX_bit

    FreeBSD

    Initial PG_NX support first appeared in FreeBSD -CURRENT on June 8,
    2004 and is a part of FreeBSD since 5.3 release.
    http://en.wikipedia.org/wiki/NX_bit#FreeBSD

    ===========================================
    If NX-bit appeared in 5X --- how do you enable?

    TIA



  2. Re: FBSD & NX-Bit

    On Wed, 16 Jul 2008 12:38:36 -0400, Timmy wrote:

    > If NX-bit appeared in 5X ---
    > how do you enable?


    I don't believe that it's there. I've just done a bunch of googling, and
    it seems that it hasn't been done, yet.

    There are some pretty good arguments against, by the way. The main
    stumbling block (from the mailing lists) seems to be that the signal
    handler trampoline code is copied to the top of the stack by the kernel
    (a known, fixed location) at process creation. I've read proposals to
    move this to somewhere else (and perhaps OpenBSD has done so?), but
    there's nothing that I can find in the lists to suggest that that's been
    done. The other good reason is that quite a few modern language features
    rely on on-the-fly code generation (look up "thunk", for example). The
    just-in-time compiler in a Java virtual machine is an extreme example,
    but there are plenty of others (C++ exceptions ring a bell). None of
    these can work when NX is enabled (in general).

    It's my impression that FreeBSD seems to be faring OK in the avoidance of
    buffer overflow attacks by dint of care and diligence.

    Cheers,

    --
    Andrew

  3. Re: FBSD & NX-Bit

    Timmy wrote:

    > I have a question. Is NX-bit enabled by default in FBSD using AMD64?


    I'm curious about this myself. I thought that it had gone into the system
    sometime back in the 5.x development days for 64 bit cpus, but was never
    quite certain. I seem to recall some discussion about ProPolice around that
    time.

    [snip]
    > If NX-bit appeared in 5X --- how do you enable?


    If my understanding is correct it just gets built automagically when gcc
    builds the system at compile time. If it is indeed built in and works this
    way there is nothing you really need to do to enable it; it is enabled out
    of the box on 64 bit platforms.

    Wish I knew something more definitive about this myself. Hopefully someone
    with clue will chime in. :-)

    -Jason



  4. Re: FBSD & NX-Bit

    On 17 Jul 2008 05:28:12 GMT,
    Andrew Reilly wrote:
    >
    > It's my impression that FreeBSD seems to be faring OK in the avoidance of
    > buffer overflow attacks by dint of care and diligence.


    That, but that doesn't protect you from overflows in broken application
    code. What FreeBSD, or unix in general, doesn't let a compromised
    application do is take over other user's applications, escalate
    privileges if it didn't already have that, and so on and so forth.

    On the face of it, that makes the possible gains of implementing NX bit
    support less interesting than it would be for that non-unix thing from
    redmond which never had a coherent security model and considering the
    evidence, never will. In that sense, it's one more cog in the security
    snake oil industry that has grown around the IT industry based on that.


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

  5. Re: FBSD & NX-Bit

    Andrew Reilly wrote:
    +---------------
    | Timmy wrote:
    | > If NX-bit appeared in 5X --- how do you enable?
    |
    | I don't believe that it's there. I've just done a bunch of googling,
    | and it seems that it hasn't been done, yet.
    |
    | There are some pretty good arguments against, by the way. The main
    | stumbling block (from the mailing lists) seems to be that the signal
    | handler trampoline code is copied to the top of the stack by the kernel
    | (a known, fixed location) at process creation. I've read proposals to
    | move this to somewhere else (and perhaps OpenBSD has done so?), but
    | there's nothing that I can find in the lists to suggest that that's been
    | done. The other good reason is that quite a few modern language features
    | rely on on-the-fly code generation (look up "thunk", for example). The
    | just-in-time compiler in a Java virtual machine is an extreme example,
    | but there are plenty of others (C++ exceptions ring a bell). None of
    | these can work when NX is enabled (in general).
    +---------------

    The same is true for any Scheme or Lisp implementation which compiles
    to machine code that lives in the "heap" (data space) -- and almost
    all Common Lisps compile exactly that way [such as CMUCL, which I use
    *extensively* for web apps, various systems daemons, "scripting", etc.].
    Turning on NX/XD would definitely break such implementations.


    -Rob

    -----
    Rob Warnock
    627 26th Avenue
    San Mateo, CA 94403 (650)572-2607


+ Reply to Thread