OASIS Static Analysis Results Interchange Format (SARIF) TC

 View Only

RE: [sarif] #401: Improved design of address object design

  • 1.  RE: [sarif] #401: Improved design of address object design

    Posted 04-29-2019 17:25




    Another question: What does a
    length of zero mean? Is it an insertion point , a zero-length range preceding the location specified by
    offsetFromParent / absoluteAddress / relativeAddress ?
     


    From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
    On Behalf Of Larry Golding (Myriad Consulting Inc)
    Sent: Monday, April 29, 2019 10:18 AM
    To: James Kupsch <kupsch@cs.wisc.edu>; Michael Fanning <Michael.Fanning@microsoft.com>; OASIS SARIF TC Discussion List <sarif@lists.oasis-open.org>
    Subject: RE: [sarif] #401: Improved design of address object design


     
    Sorry, I shouldn t have directed those questions only to Michael. It was just because he proposed the original redesign in #403. Of course I want to hear feedback from the entire TC.
     


    From: Larry Golding (Myriad Consulting Inc) < v-lgold@microsoft.com >

    Sent: Monday, April 29, 2019 10:16 AM
    To: Larry Golding (Myriad Consulting Inc) < v-lgold@microsoft.com >; James Kupsch < kupsch@cs.wisc.edu >; Michael Fanning < Michael.Fanning@microsoft.com >;
    OASIS SARIF TC Discussion List < sarif@lists.oasis-open.org >
    Subject: RE: [sarif] #401: Improved design of address object design


     
    Another concern I have is around
    length . I want to be able to write that if an
    address object occurs within a
    physicalLocation object
    thisObject , and if
    thisObject.length and
    thisObject.address.length are both present, then then
    SHALL be equal.
     
    As the spec stands, I can t write this because
    physicalLocation.length is non-negative. I can add words like this:
     
    If an
    address object occurs within a
    physicalLocation object
    thisObject , and if
    thisObject.length and
    thisObject.address.length are both present, then then
    SHALL be equal. In that case, if thisObject.address.length is negative, then
    thisObject.length will also be negative. In all other circumstances,
    length SHALL be non-negative.
     
    Michael , are you ok with that complication?
     
    Larry
     


    From:
    sarif@lists.oasis-open.org < sarif@lists.oasis-open.org >
    On Behalf Of Larry Golding (Myriad Consulting Inc)
    Sent: Monday, April 29, 2019 10:08 AM
    To: James Kupsch < kupsch@cs.wisc.edu >; Michael Fanning < Michael.Fanning@microsoft.com >; OASIS SARIF TC Discussion List < sarif@lists.oasis-open.org >
    Subject: RE: [sarif] #401: Improved design of address object design


     
    Jim,
     
    From an SDK standpoint we have a problem with negative values because without -1 as a sentinel value, we need to make the .NET type
    Nullable<int> instead of
    int . So far we have avoided nullables in the API. Our code generation doesn t currently support them, but it wouldn t be hard to add.
     
    Michael , could you weigh in on this? The .NET Framework Design Guidelines ( 8.8) say:
     
    CONSIDER using
    Nullable<T> to represent values that might not be present ( i.e. , optional values).
     
    and a quick web search doesn t turn up recommendations to avoid them in this scenario.
     
    I d just be concerned that this is the only place we have nullables. Are there alternatives?
     
    In the meantime I ll write the words for the rest of Jim s feedback.
     
    Larry
     


    From: James Kupsch < kupsch@cs.wisc.edu >

    Sent: Monday, April 29, 2019 8:40 AM
    To: Michael Fanning < Michael.Fanning@microsoft.com >; Larry Golding (Myriad Consulting Inc) < v-lgold@microsoft.com >; OASIS SARIF TC Discussion List < sarif@lists.oasis-open.org >
    Subject: Re: [sarif] #401: Improved design of address object design


     
    For #2,I  was thinking the "stack" kind would be the whole stack.  Also having a "stackFrame" kind would also be useful as it also a defined memory region contained within the "stack" kind.
    JIm

    On 4/29/19 10:20 AM, Michael Fanning wrote:

    Right now, the effective address is absolute if unparented and relative to some other thing, if parented.
     
    If you chase to the root object, let s say it s a module, its effective address provides the ability to distinguish a child s relative address vs. physical memory location.
     
    IOW, the child s relative address is its offset + all offsets up to (but not including) the root object. If you add the effective address of the root object, you get the absolute memory address (if available).
     
    Make sense? What do you think?
     
    For #2 stack, is the kind a stack frame?

    For #3, I see the problem. Every address in a PLC has an associated region but the run.addresses cache does not provide this association. Let me have a word with Larry.

     


    From:
    sarif@lists.oasis-open.org
    <sarif@lists.oasis-open.org> On Behalf Of James Kupsch
    Sent: Monday, April 29, 2019 8:06 AM
    To: Larry Golding (Myriad Consulting Inc)
    <v-lgold@microsoft.com> ; OASIS SARIF TC Discussion List
    <sarif@lists.oasis-open.org>
    Subject: Re: [sarif] #401: Improved design of address object design


     
    A fter reading the address section changes.  I have a couple of comments:

    1) I would think that a common use of address would be something on the stack. To facilitate this, the offsetFromParent should be allowed to be negative as the "bottom" of stack is most logical place to be offset from, and since some stacks grow from higher
    to lower memory addresses, the offset is negative.  The use of -1 for unknown mechanism would have to be changed for this to work.

    2) Add stack as a kind

    3) There is a length in physical location, but not all addresses will appear in a physical location (probably just those without parentIndex) a length field would be useful.  This allows the producers to specify the lengths of the parent addresses that are
    regions in memory, and for consumers to determine them. The length should be allowed to be negative to handle the stack case cleanly and to indicate that it grows towards decreasing values (if length is negative the regions is from (address - offset) to address.
    For instance if I have an address in a physical object, a question that I might want to know is does this address overflow a containing memory region.

    4) effectiveAddress can be one of two types of addresses: a relative address to some logical memory/file region, and an absolute memory address.  These concepts are independent, are both useful, and should be distinguishable from one another.  Something like:

    offsetFromParent - offset from containing parent (same as existing)
    parentIndex   - direct container address region if there is one (same as existing)
    offsetFromLogicalAddressRegion   - offset from some base logical region of memory (like effectiveAddress)
    logicalAddressRegionIndex   - the base logical region of memory the above offset if relative to
    absoluteMemoryAddress - absolute memory address of address (physical or virtual, be consistent).  Optional, recommended to only be included on addresses without parentIndex.
    Right now the effectiveAddress is difficult to use as they can not be compared without first figuring out what they are relative to and it isn't clear if the effective address is relative to something or absolute.
    Jim
     
     
     

    On 4/28/19 2:25 PM, Larry Golding (Myriad Consulting Inc) wrote:

    I created and pushed a change draft for
    Issue #401 , Improved address object design .
     
    https://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ChangeDrafts/Accepted/sarif-v2.0-issue-401-address-rework.docx
     
    The original design was ambiguous about what
    address.offset was based on: the parent object, or
    address.baseAddress ?
     


    We renamed offset to
    offsetFromParent to clear up that ambiguity.
    We removed baseAddress because once it s clear that offset is based on the parent object, there s no need to duplicate the information in the child object.
    We added some more kind values ( "header" ,
    "table" ) and we (really Michael) made the definitions of
    "section" and
    "segment" more precise. We (this time, really me