[Bug translator/11347] intra-tapset visibility scoping for embedded-c functions

[Bug translator/11347] intra-tapset visibility scoping for embedded-c functions

[mcermak at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11347

Martin Cermak <mcermak at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mcermak at redhat dot com

--- Comment #2 from Martin Cermak <mcermak at redhat dot com> ---
Improved separation level can now be achieved using the 'private' keyword per
PR19136. Following commits pull the 'private' keyword into the tapset code:

ed82a32 Mark selected internal tapset global vars as '@__private30'.
6b131ba Mark internal tapset functions as '@__private30' where possible.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/11347] intra-tapset visibility scoping for embedded-c functions

[mcermak at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11347

Martin Cermak <mcermak at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Martin Cermak <mcermak at redhat dot com> ---
Marking as resolved per the above comment.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/11347] intra-tapset visibility scoping for embedded-c functions

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2010-03-03 22:49 -------
(In reply to comment #0)
> There are cases where a tapset embedded-c function is known
> to be safe from the context of the probe that calls it, but
> cannot easily be made safe to call from arbitrary contexts.
> It would be desirable for such embedded-c functions to be
> only visible (resolvable) to probes/aliases within that tapset.

Even if hidden, "known to be safe" may be hard to prove.  If an embedded-c
function really can't be hardened, then we have to be SURE that all inputs are
fully controlled.  (And I wonder, if we know what inputs are safe anyway, why
can't the embedded-c assert that?)

> Since systemtap lacks a formal module system, this would be a
> baby step in this direction.  One simple possibility would be
> to have a policy/mechanism that treats embedded-c functions
> with a "__" prefix as being only visible to elements in the
> same tapset file as where they are defined.  (Treating
> globals, script functions, and probes as similarly visibility
> restricted might not provide any additional safety, but could
> be considered for sake of simplicity.)

An added benefit is that "internal" probe aliases could be hidden from the
suggestion list during probe syntax errors.

> mjw aux_syscalls.stp is used by multiple other tapsets
> fche cut & paste then

In cases where it's just a reuse between syscalls and syscalls2, they could be
refactored into a syscalls_foo common file.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11347

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.