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

[James Kupsch <kupsch@cs.wisc.edu>]

Yes, both the absolute and relative addresses can be computed from 
offsetFromParent.

Jim


On 4/29/19 10:28 AM, Michael Fanning wrote:
> OK, went to the whiteboard and I see your point. We need to rename 
> effectiveAddress to absoluteAddress and add relativeAddress (which is an 
> optional computed address relative to your root). I think 
> offsetFromParent is sufficient to drive computation of both these 
> properties.
> 
> *From:*sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> *On 
> Behalf Of *Michael Fanning
> *Sent:* Monday, April 29, 2019 8:21 AM
> *To:* James Kupsch <kupsch@cs.wisc.edu>; 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
> 
> 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 <mailto:sarif@lists.oasis-open.org> 
> <sarif@lists.oasis-open.org <mailto: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 
> <mailto:v-lgold@microsoft.com>>; OASIS SARIF TC Discussion List 
> <sarif@lists.oasis-open.org <mailto:sarif@lists.oasis-open.org>>
> *Subject:* Re: [sarif] #401: Improved design of address object design
> 
> After 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
>     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foasis-tcs%2Fsarif-spec%2Fissues%2F401&data=01%7C01%7Cmichael.fanning%40microsoft.com%7C4b02bd5b84c4405b421908d6ccb63ce7%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=KVBkeIh%2Fm8CyZYbU25PJKxxlEJI2UzHbxosovvLsSQg%3D&reserved=0>,
>     âImproved address object designâ.
> 
>     https://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ChangeDrafts/Accepted/sarif-v2.0-issue-401-address-rework.docx
>     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foasis-tcs%2Fsarif-spec%2Fblob%2Fmaster%2FDocuments%2FChangeDrafts%2FAccepted%2Fsarif-v2.0-issue-401-address-rework.docx&data=01%7C01%7Cmichael.fanning%40microsoft.com%7C4b02bd5b84c4405b421908d6ccb63ce7%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=dFHrDLIbKIJLL5p5moIec%2F2XXRxNs1ka%2FLj4J97GDZI%3D&reserved=0>
> 
>     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 ð) also added text
>         acknowledging that the meanings of these terms are OS-dependent,
>         and recommending that SARIF producers use the term most
>         appropriate for the target OS.
>       * Finally, an innovation: we introduced a property
>         effectiveAddress, which, when not present, can in certain
>         circumstances be calculated by adding the offsets all the way up
>         the ancestor chain. (The precise algorithm is in the spec.) This
>         has two benefits:
> 
>           o It allows the consumer to see the final address without
>             having to walk all the way up the ancestor chain. This at
>             first /seems/ duplicative in the same way that baseAddress
>             was (although even if that were true, effectiveAddress saves
>             the consumer more work than baseAddress did because
>             baseAddress duplicated information in a /single/ address
>             object rather than a whole chain of them). *BUT!* Itâs not
>             really duplicative, becauseâ
>           o The effectiveAddress property allows a consumer to see the
>             final address /even if some of the information required to
>             calculate it is missing from the ancestor addresses/. This
>             allows you to say, for example, âHere is the address of this
>             entry in the exception handler table; the table entry is a
>             child of the table, which is itself a child of some other
>             thingâ â without having to specify the address of the
>             exception handler table if you donât think thatâs relevant.
> 
>     This draft also includes a small amount of residual editorial feedback.
> 
>     As always, the provisional draft and its HTML version are up to date:
> 
>     https://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ProvisionalDrafts/sarif-v2.0-csd02-provisional.docx
>     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foasis-tcs%2Fsarif-spec%2Fblob%2Fmaster%2FDocuments%2FProvisionalDrafts%2Fsarif-v2.0-csd02-provisional.docx&data=01%7C01%7Cmichael.fanning%40microsoft.com%7C4b02bd5b84c4405b421908d6ccb63ce7%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=MIifFl%2FJbZHevGYyWubHRESH%2Fo7W00q%2BH4dj%2FMTljKA%3D&reserved=0>
> 
>     https://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ProvisionalDrafts/sarif-v2.0-csd02-provisional.htm
>     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foasis-tcs%2Fsarif-spec%2Fblob%2Fmaster%2FDocuments%2FProvisionalDrafts%2Fsarif-v2.0-csd02-provisional.htm&data=01%7C01%7Cmichael.fanning%40microsoft.com%7C4b02bd5b84c4405b421908d6ccb63ce7%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=LjLveoidpTBEzGK2fjyAoN3RHW9eLFVZHUI9F4q%2Fc2s%3D&reserved=0>
> 
>     *Please take a look.* We still plan to open the CSD 2 ballot on Monday.
> 
>     Thanks,
> 
>     Larry
>