[LLVMdev] 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 <baldrick at free.fr> 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<http://gcc.gnu.org/wiki/SplitStacks>
>
> Ciao, Duncan.
>
>
>> Thanks,
>>
>> ~Brent Roth~
>>
>> On Mon, Jun 3, 2013 at 3:20 AM, Duncan Sands <baldrick at free.fr
>> <mailto:baldrick at free.fr>> 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
>>         LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>> http://llvm.cs.uiuc.edu
>>         http://lists.cs.uiuc.edu/__**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev>
>>         <http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>> >
>>
>>
>>     ______________________________**___________________
>>     LLVM Developers mailing list
>>     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>> http://llvm.cs.uiuc.edu
>>     http://lists.cs.uiuc.edu/__**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev>
>>     <http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>> >
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130603/65d3b054/attachment.html>