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 <
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