sarif — archive

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

From: Jim Kupsch
To: [email protected]
Date: Mon, 29 Apr 2019 15:32:00 -0000

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:*[email protected] <[email protected]> *On > Behalf Of *Michael Fanning > *Sent:* Monday, April 29, 2019 8:21 AM > *To:* James Kupsch <[email protected]>; Larry Golding (Myriad > Consulting Inc) <[email protected]>; OASIS SARIF TC Discussion List > <[email protected]> > *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:*[email protected] < mailto:[email protected] > > <[email protected] < mailto:[email protected] >> *On > Behalf Of *James Kupsch > *Sent:* Monday, April 29, 2019 8:06 AM > *To:* Larry Golding (Myriad Consulting Inc) <[email protected] > < mailto:[email protected] >>; OASIS SARIF TC Discussion List > <[email protected] < mailto:[email protected] >> > *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 >