[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sarif] #401: Improved design of address object design
I'm going with "1" unless I hear otherwise (for both then minimum and default value of the length property). -----Original Message----- From: Larry Golding (Myriad Consulting Inc) Sent: Monday, April 29, 2019 11:03 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 So what should be the default for length, since it's optional? If there is no sensible default, then again we're looking at a Nullable<int>. There was no similar problem with physicalLocation.length because 0 _was_ a sensible default. -----Original Message----- From: James Kupsch <kupsch@cs.wisc.edu> Sent: Monday, April 29, 2019 11:01 AM To: Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com>; 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 Pratically, I don't think 0 length memory region makes sense other than as a pathological case. In C, malloc(0) returns a 0 length memory allocation with a unique memory address for each such call. Jim On 4/29/19 12:24 PM, Larry Golding (Myriad Consulting Inc) wrote: > Another question: What does a lengthof 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 > <mailto:v-lgold@microsoft.com>> > *Sent:* Monday, April 29, 2019 10:16 AM > *To:* Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com > <mailto:v-lgold@microsoft.com>>; James Kupsch <kupsch@cs.wisc.edu > <mailto:kupsch@cs.wisc.edu>>; Michael Fanning > <Michael.Fanning@microsoft.com > <mailto:Michael.Fanning@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 > > Another concern I have is around length. I want to be able to write > that if an addressobject occurs within a physicalLocationobject > thisObject, and if thisObject.lengthand thisObject.address.lengthare > both present, then then *SHALL* be equal. > > As the spec stands, I canât write this because > physicalLocation.lengthis non-negative. I can add words like this: > > If an addressobject occurs within a physicalLocationobject thisObject, > and if thisObject.lengthand thisObject.address.lengthare both present, > then then *SHALL* be equal. In that case, if > thisObject.address.lengthis negative, then thisObject.lengthwill also > be negative. In all other circumstances, lengthSHALL be non-negative. > > *Michael*, are you ok with that complication? > > 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 *Larry Golding (Myriad Consulting Inc) > *Sent:* Monday, April 29, 2019 10:08 AM > *To:* James Kupsch <kupsch@cs.wisc.edu <mailto:kupsch@cs.wisc.edu>>; > Michael Fanning <Michael.Fanning@microsoft.com > <mailto:Michael.Fanning@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 > > 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 <mailto:kupsch@cs.wisc.edu>> > *Sent:* Monday, April 29, 2019 8:40 AM > *To:* Michael Fanning <Michael.Fanning@microsoft.com > <mailto:Michael.Fanning@microsoft.com>>; 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 > > 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 <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%2Fgit > hub.com%2Foasis-tcs%2Fsarif-spec%2Fissues%2F401&data=01%7C01%7Cv-l > gold%40microsoft.com%7Cb349bab6bb2a44c009ea08d6ccccb290%7C72f988bf86f1 > 41af91ab2d7cd011db47%7C1&sdata=Vze8H22CyJb8ZWOybmNf6pHV6bCIvEYQB9F > ymq1u0zM%3D&reserved=0>, > âImproved address object designâ. > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > ub.com%2Foasis-tcs%2Fsarif-spec%2Fblob%2Fmaster%2FDocuments%2FChangeDr > afts%2FAccepted%2Fsarif-v2.0-issue-401-address-rework.docx&data=01 > %7C01%7Cv-lgold%40microsoft.com%7Cb349bab6bb2a44c009ea08d6ccccb290%7C7 > 2f988bf86f141af91ab2d7cd011db47%7C1&sdata=gX%2BHBb4GtXAeBFmajZ051x > LU7JVJbE5Ieq9JGjpJpMM%3D&reserved=0 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > hub.com%2Foasis-tcs%2Fsarif-spec%2Fblob%2Fmaster%2FDocuments%2FChangeD > rafts%2FAccepted%2Fsarif-v2.0-issue-401-address-rework.docx&data=0 > 1%7C01%7Cv-lgold%40microsoft.com%7Cb349bab6bb2a44c009ea08d6ccccb290%7C > 72f988bf86f141af91ab2d7cd011db47%7C1&sdata=gX%2BHBb4GtXAeBFmajZ051 > xLU7JVJbE5Ieq9JGjpJpMM%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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > ub.com%2Foasis-tcs%2Fsarif-spec%2Fblob%2Fmaster%2FDocuments%2FProvisio > nalDrafts%2Fsarif-v2.0-csd02-provisional.docx&data=01%7C01%7Cv-lgo > ld%40microsoft.com%7Cb349bab6bb2a44c009ea08d6ccccb290%7C72f988bf86f141 > af91ab2d7cd011db47%7C1&sdata=2mHcTNY7mAB439SIzOyDUa9LyQynm9GzWJHe9 > 9D1T7g%3D&reserved=0 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > hub.com%2Foasis-tcs%2Fsarif-spec%2Fblob%2Fmaster%2FDocuments%2FProvisi > onalDrafts%2Fsarif-v2.0-csd02-provisional.docx&data=01%7C01%7Cv-lg > old%40microsoft.com%7Cb349bab6bb2a44c009ea08d6ccccb290%7C72f988bf86f14 > 1af91ab2d7cd011db47%7C1&sdata=2mHcTNY7mAB439SIzOyDUa9LyQynm9GzWJHe > 99D1T7g%3D&reserved=0> > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > ub.com%2Foasis-tcs%2Fsarif-spec%2Fblob%2Fmaster%2FDocuments%2FProvisio > nalDrafts%2Fsarif-v2.0-csd02-provisional.htm&data=01%7C01%7Cv-lgol > d%40microsoft.com%7Cb349bab6bb2a44c009ea08d6ccccb290%7C72f988bf86f141a > f91ab2d7cd011db47%7C1&sdata=Av%2BpFv%2FCvb%2FcVdPEuHQn0TDC%2Biv92J > qPjGp66ej2%2FZY%3D&reserved=0 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > hub.com%2Foasis-tcs%2Fsarif-spec%2Fblob%2Fmaster%2FDocuments%2FProvisi > onalDrafts%2Fsarif-v2.0-csd02-provisional.htm&data=01%7C01%7Cv-lgo > ld%40microsoft.com%7Cb349bab6bb2a44c009ea08d6ccccb290%7C72f988bf86f141 > af91ab2d7cd011db47%7C1&sdata=Av%2BpFv%2FCvb%2FcVdPEuHQn0TDC%2Biv92 > JqPjGp66ej2%2FZY%3D&reserved=0> > > *Please take a look.* We still plan to open the CSD 2 ballot on Monday. > > Thanks, > > Larry >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]