Re: [DynInst_API:] [Paradyn-staff] upcoming releases and potential API changes

[Josh Stone <jistone@xxxxxxxxxx>]

On 10/07/2014 04:39 PM, Matthew LeGendre wrote:
> 
> On Tue, 7 Oct 2014, Josh Stone wrote:
>> I've been thinking about improving the selinux story -- right now we
>> must allow execmem/execstack because of the RWX memory maps.  I'd like
>> to try separating this into proper code (R-X) and data (RW-) maps for
>> inferior allocs.  The API appears to already allow requests to specify
>> what they need, but I worry a little that someone might be lazily making
>> requests under the assumption that they'll get RWX.  Thoughts?
> 
> Off the top of my head, I don't think you'll see problems with Dyninst 
> users making assumptions about having RWX memory.  The DyninstAPI 
> interface is high-level enough that users can't specify their own memory 
> permissions nor treat data as code.  I can't easily picture out how users 
> could write DyninstAPI code that'd be sensitive to this off the top of my 
> head.

My initial concern is that anything which currently leads to a call like
"inferiorMalloc(..., anyHeap, ...)" might be relying on the fact that in
the status quo "anyHeap" gets you RWX.  If it wants something writable
it really ought to say dataHeap, or executable as textHeap.  But with
"anyHeap" you should really only rely on being readable.

But you're right, this distinction is all internal to DyninstAPI, so
that potential problem should be hidden from users.  At least I see
BPatch_addressSpace::malloc always uses dataHeap.

> But anyone who uses the PatchAPI interface to specify instrumentation 
> could conceivably intermix their data/code.  Though I don't think there's 
> a lot of users in this situation.  I use PatchAPI in one of my tools, but 
> it wouldn't be sensitive to these changes.

Right, this is only about DyninstAPI.  Underneath, you can map however
you like, and deal with your own consequences if you mix WX.

> A larger problem might be in the binary rewriter.  In the ideal case 
> DyninstAPI appends new program headers to the binary that contain the new 
> code/data.  But there were numerous limitations and bugs across 
> OSs/Loaders/libelf that limited this ability.  As work-arounds Dyninst 
> situationally adds code ahead of the binary, reuses existing program 
> headers, and other assorted hacks (see some comments in 
> symtabAPI/src/emitElf-64.C).  Some of these hacks may be incompatible with 
> making two new program headers.  You may have to situationally turn off 
> seperate RX and RW maps in these cases.

Thanks, I'll watch out for this.  In fact, BinaryEdit::inferiorMalloc
ignores its type and does everything as "anyHeap". :/

I'll probably start with the dynamic side of things and see how it goes.

Thanks,
Josh