LLVM/Clang research questions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

LLVM/Clang research questions

Brent Gregory Roth
Greetings,

First, my apologies if I have incorrectly used any of these lists.

I'm sending this email in order to get some help on where in the
codebases for LLVM and/or Clang I should be looking in order to
accomplish the following:

- create 4 additional memory segment
- - 2 to be used as "additional stacks"
- - 2 to be used as "additional heaps"

- modify the stack frame and stack pointer registers (in order to make
use of the 2 "additional stacks")

- modify segment descriptors, as needed, to support reads/writes to the
additional segments

- modify which stack variables go to which of the three stacks
- - same for heaps

Thank you.

Sincerely,

~Brent Roth~
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM/Clang research questions

Duncan Sands
Hi Brent, LLVM supports segmented stacks, I suggest you do a case
insensitive grep for segmented.stack in the source code (the . is
to match any character).

Ciao, Duncan.

On 03/06/13 00:35, Brent Gregory Roth wrote:

> Greetings,
>
> First, my apologies if I have incorrectly used any of these lists.
>
> I'm sending this email in order to get some help on where in the
> codebases for LLVM and/or Clang I should be looking in order to
> accomplish the following:
>
> - create 4 additional memory segment
> - - 2 to be used as "additional stacks"
> - - 2 to be used as "additional heaps"
>
> - modify the stack frame and stack pointer registers (in order to make
> use of the 2 "additional stacks")
>
> - modify segment descriptors, as needed, to support reads/writes to the
> additional segments
>
> - modify which stack variables go to which of the three stacks
> - - same for heaps
>
> Thank you.
>
> Sincerely,
>
> ~Brent Roth~
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM/Clang research questions

Brent Gregory Roth
Hi Duncan,

Are the segmented stacks actually on separate memory segments? My intended purpose for placing different datatypes on separate stacks is such that memory accesses to one datatype won't be allowed to overflow to another datatype.

If they aren't, in fact, on separate memory segments, are you aware of a way to place a non-readable/-writable segment in between two other stack segments?

Thanks,

~Brent Roth~

On Mon, Jun 3, 2013 at 3:20 AM, Duncan Sands <[hidden email]> wrote:
Hi Brent, LLVM supports segmented stacks, I suggest you do a case
insensitive grep for segmented.stack in the source code (the . is
to match any character).

Ciao, Duncan.


On 03/06/13 00:35, Brent Gregory Roth wrote:
Greetings,

First, my apologies if I have incorrectly used any of these lists.

I'm sending this email in order to get some help on where in the
codebases for LLVM and/or Clang I should be looking in order to
accomplish the following:

- create 4 additional memory segment
- - 2 to be used as "additional stacks"
- - 2 to be used as "additional heaps"

- modify the stack frame and stack pointer registers (in order to make
use of the 2 "additional stacks")

- modify segment descriptors, as needed, to support reads/writes to the
additional segments

- modify which stack variables go to which of the three stacks
- - same for heaps

Thank you.

Sincerely,

~Brent Roth~
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM/Clang research questions

Duncan Sands
Hi Brent,

On 03/06/13 14:32, Brent Gregory Roth wrote:
> Hi Duncan,
>
> Are the segmented stacks actually on separate memory segments? My intended
> purpose for placing different datatypes on separate stacks is such that memory
> accesses to one datatype won't be allowed to overflow to another datatype.
>
> If they aren't, in fact, on separate memory segments, are you aware of a way to
> place a non-readable/-writable segment in between two other stack segments?

it is essentially the same thing as GCC's split stacks:

http://gcc.gnu.org/wiki/SplitStacks

Ciao, Duncan.

>
> Thanks,
>
> ~Brent Roth~
>
> On Mon, Jun 3, 2013 at 3:20 AM, Duncan Sands <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi Brent, LLVM supports segmented stacks, I suggest you do a case
>     insensitive grep for segmented.stack in the source code (the . is
>     to match any character).
>
>     Ciao, Duncan.
>
>
>     On 03/06/13 00:35, Brent Gregory Roth wrote:
>
>         Greetings,
>
>         First, my apologies if I have incorrectly used any of these lists.
>
>         I'm sending this email in order to get some help on where in the
>         codebases for LLVM and/or Clang I should be looking in order to
>         accomplish the following:
>
>         - create 4 additional memory segment
>         - - 2 to be used as "additional stacks"
>         - - 2 to be used as "additional heaps"
>
>         - modify the stack frame and stack pointer registers (in order to make
>         use of the 2 "additional stacks")
>
>         - modify segment descriptors, as needed, to support reads/writes to the
>         additional segments
>
>         - modify which stack variables go to which of the three stacks
>         - - same for heaps
>
>         Thank you.
>
>         Sincerely,
>
>         ~Brent Roth~
>         _________________________________________________
>         LLVM Developers mailing list
>         [hidden email] <mailto:[hidden email]> http://llvm.cs.uiuc.edu
>         http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev
>         <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>
>
>     _________________________________________________
>     LLVM Developers mailing list
>     [hidden email] <mailto:[hidden email]> http://llvm.cs.uiuc.edu
>     http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev
>     <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM/Clang research questions

Brent Gregory Roth
Hi Duncan,

It doesn't appear to be what I'm looking for as there is copying of the old stack to the new stack. Additionally, according to the LLVM docs on segmented stacks (http://llvm.org/releases/3.0/docs/SegmentedStacks.html) the stacklings are allocated memory from the heap. Since this places them all on the same memory segment, a read/write from one stackling could technically overflow to read/write another stackling ... unless there is something I've overlooked or is undocumented.

What I've been looking at currently is a suggestion made to me last night to either
(1) modify the allocated space for local variables in LLVM so that there are multiples of them
(2) treat all local variables as globals and specify explicitly where each should be written

The primary goal I'm trying to achieve is such that a read/write to one or more variables on one stack cannot overflow to those on another stack due to either a protection page in between and/or implicit protections from being on different memory segments.

Thank you,

~Brent Roth~

On Mon, Jun 3, 2013 at 8:33 AM, Duncan Sands <[hidden email]> wrote:
Hi Brent,


On 03/06/13 14:32, Brent Gregory Roth wrote:
Hi Duncan,

Are the segmented stacks actually on separate memory segments? My intended
purpose for placing different datatypes on separate stacks is such that memory
accesses to one datatype won't be allowed to overflow to another datatype.

If they aren't, in fact, on separate memory segments, are you aware of a way to
place a non-readable/-writable segment in between two other stack segments?

it is essentially the same thing as GCC's split stacks:

http://gcc.gnu.org/wiki/SplitStacks

Ciao, Duncan.


Thanks,

~Brent Roth~

On Mon, Jun 3, 2013 at 3:20 AM, Duncan Sands <[hidden email]
<mailto:[hidden email]>> wrote:

    Hi Brent, LLVM supports segmented stacks, I suggest you do a case
    insensitive grep for segmented.stack in the source code (the . is
    to match any character).

    Ciao, Duncan.


    On 03/06/13 00:35, Brent Gregory Roth wrote:

        Greetings,

        First, my apologies if I have incorrectly used any of these lists.

        I'm sending this email in order to get some help on where in the
        codebases for LLVM and/or Clang I should be looking in order to
        accomplish the following:

        - create 4 additional memory segment
        - - 2 to be used as "additional stacks"
        - - 2 to be used as "additional heaps"

        - modify the stack frame and stack pointer registers (in order to make
        use of the 2 "additional stacks")

        - modify segment descriptors, as needed, to support reads/writes to the
        additional segments

        - modify which stack variables go to which of the three stacks
        - - same for heaps

        Thank you.

        Sincerely,

        ~Brent Roth~
        _________________________________________________
        LLVM Developers mailing list
        [hidden email] <mailto:[hidden email]> http://llvm.cs.uiuc.edu
        http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev
        <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>


    _________________________________________________
    LLVM Developers mailing list
    [hidden email] <mailto:[hidden email]> http://llvm.cs.uiuc.edu
    http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev
    <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>





_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM/Clang research questions

David Chisnall-5
Hi Brent,

You're correct.  The segmented stack model is intended for performance, not security.  Its goal is to allow lightweight threads to be very cheaply allocated and destroyed.

For your model, you would most likely want to use different address spaces for the different memory types.  Currently, clang does not allow you to define the address space of variables with automatic storage ('stack variables') and I'm not sure if this is a limitation of LLVM's alloca instruction or of the front end.

David

On 3 Jun 2013, at 14:02, Brent Gregory Roth <[hidden email]> wrote:

> Hi Duncan,
>
> It doesn't appear to be what I'm looking for as there is copying of the old stack to the new stack. Additionally, according to the LLVM docs on segmented stacks (http://llvm.org/releases/3.0/docs/SegmentedStacks.html) the stacklings are allocated memory from the heap. Since this places them all on the same memory segment, a read/write from one stackling could technically overflow to read/write another stackling ... unless there is something I've overlooked or is undocumented.
>
> What I've been looking at currently is a suggestion made to me last night to either
> (1) modify the allocated space for local variables in LLVM so that there are multiples of them
> (2) treat all local variables as globals and specify explicitly where each should be written
>
> The primary goal I'm trying to achieve is such that a read/write to one or more variables on one stack cannot overflow to those on another stack due to either a protection page in between and/or implicit protections from being on different memory segments.
>
> Thank you,
>
> ~Brent Roth~
>
> On Mon, Jun 3, 2013 at 8:33 AM, Duncan Sands <[hidden email]> wrote:
> Hi Brent,
>
>
> On 03/06/13 14:32, Brent Gregory Roth wrote:
> Hi Duncan,
>
> Are the segmented stacks actually on separate memory segments? My intended
> purpose for placing different datatypes on separate stacks is such that memory
> accesses to one datatype won't be allowed to overflow to another datatype.
>
> If they aren't, in fact, on separate memory segments, are you aware of a way to
> place a non-readable/-writable segment in between two other stack segments?
>
> it is essentially the same thing as GCC's split stacks:
>
> http://gcc.gnu.org/wiki/SplitStacks
>
> Ciao, Duncan.
>
>
> Thanks,
>
> ~Brent Roth~
>
> On Mon, Jun 3, 2013 at 3:20 AM, Duncan Sands <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi Brent, LLVM supports segmented stacks, I suggest you do a case
>     insensitive grep for segmented.stack in the source code (the . is
>     to match any character).
>
>     Ciao, Duncan.
>
>
>     On 03/06/13 00:35, Brent Gregory Roth wrote:
>
>         Greetings,
>
>         First, my apologies if I have incorrectly used any of these lists.
>
>         I'm sending this email in order to get some help on where in the
>         codebases for LLVM and/or Clang I should be looking in order to
>         accomplish the following:
>
>         - create 4 additional memory segment
>         - - 2 to be used as "additional stacks"
>         - - 2 to be used as "additional heaps"
>
>         - modify the stack frame and stack pointer registers (in order to make
>         use of the 2 "additional stacks")
>
>         - modify segment descriptors, as needed, to support reads/writes to the
>         additional segments
>
>         - modify which stack variables go to which of the three stacks
>         - - same for heaps
>
>         Thank you.
>
>         Sincerely,
>
>         ~Brent Roth~
>         _________________________________________________
>         LLVM Developers mailing list
>         [hidden email] <mailto:[hidden email]> http://llvm.cs.uiuc.edu
>         http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev
>         <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>
>
>     _________________________________________________
>     LLVM Developers mailing list
>     [hidden email] <mailto:[hidden email]> http://llvm.cs.uiuc.edu
>     http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev
>     <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM/Clang research questions

Brent Gregory Roth
Hi David,

Thank you for confirming that for me.

What about the plausibility of splitting the single alloca space (the one stack) into three sections, with a "guard page" between each of the sections? Does LLVM provide the capabilities required to do this or something similar?

I simply need "something" to ensure that if X is on stack1 and Y is on stack2 that an access to X cannot access Y.

Thank you,

~Brent Roth~

On Mon, Jun 3, 2013 at 9:25 AM, David Chisnall <[hidden email]> wrote:
Hi Brent,

You're correct.  The segmented stack model is intended for performance, not security.  Its goal is to allow lightweight threads to be very cheaply allocated and destroyed.

For your model, you would most likely want to use different address spaces for the different memory types.  Currently, clang does not allow you to define the address space of variables with automatic storage ('stack variables') and I'm not sure if this is a limitation of LLVM's alloca instruction or of the front end.

David

On 3 Jun 2013, at 14:02, Brent Gregory Roth <[hidden email]> wrote:

> Hi Duncan,
>
> It doesn't appear to be what I'm looking for as there is copying of the old stack to the new stack. Additionally, according to the LLVM docs on segmented stacks (http://llvm.org/releases/3.0/docs/SegmentedStacks.html) the stacklings are allocated memory from the heap. Since this places them all on the same memory segment, a read/write from one stackling could technically overflow to read/write another stackling ... unless there is something I've overlooked or is undocumented.
>
> What I've been looking at currently is a suggestion made to me last night to either
> (1) modify the allocated space for local variables in LLVM so that there are multiples of them
> (2) treat all local variables as globals and specify explicitly where each should be written
>
> The primary goal I'm trying to achieve is such that a read/write to one or more variables on one stack cannot overflow to those on another stack due to either a protection page in between and/or implicit protections from being on different memory segments.
>
> Thank you,
>
> ~Brent Roth~
>
> On Mon, Jun 3, 2013 at 8:33 AM, Duncan Sands <[hidden email]> wrote:
> Hi Brent,
>
>
> On 03/06/13 14:32, Brent Gregory Roth wrote:
> Hi Duncan,
>
> Are the segmented stacks actually on separate memory segments? My intended
> purpose for placing different datatypes on separate stacks is such that memory
> accesses to one datatype won't be allowed to overflow to another datatype.
>
> If they aren't, in fact, on separate memory segments, are you aware of a way to
> place a non-readable/-writable segment in between two other stack segments?
>
> it is essentially the same thing as GCC's split stacks:
>
> http://gcc.gnu.org/wiki/SplitStacks
>
> Ciao, Duncan.
>
>
> Thanks,
>
> ~Brent Roth~
>
> On Mon, Jun 3, 2013 at 3:20 AM, Duncan Sands <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi Brent, LLVM supports segmented stacks, I suggest you do a case
>     insensitive grep for segmented.stack in the source code (the . is
>     to match any character).
>
>     Ciao, Duncan.
>
>
>     On 03/06/13 00:35, Brent Gregory Roth wrote:
>
>         Greetings,
>
>         First, my apologies if I have incorrectly used any of these lists.
>
>         I'm sending this email in order to get some help on where in the
>         codebases for LLVM and/or Clang I should be looking in order to
>         accomplish the following:
>
>         - create 4 additional memory segment
>         - - 2 to be used as "additional stacks"
>         - - 2 to be used as "additional heaps"
>
>         - modify the stack frame and stack pointer registers (in order to make
>         use of the 2 "additional stacks")
>
>         - modify segment descriptors, as needed, to support reads/writes to the
>         additional segments
>
>         - modify which stack variables go to which of the three stacks
>         - - same for heaps
>
>         Thank you.
>
>         Sincerely,
>
>         ~Brent Roth~
>         _________________________________________________
>         LLVM Developers mailing list
>         [hidden email] <mailto:[hidden email]> http://llvm.cs.uiuc.edu
>         http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev
>         <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>
>
>     _________________________________________________
>     LLVM Developers mailing list
>     [hidden email] <mailto:[hidden email]> http://llvm.cs.uiuc.edu
>     http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev
>     <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev