OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sarif message

[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&amp;data=01%7C01%7Cv-l
> gold%40microsoft.com%7Cb349bab6bb2a44c009ea08d6ccccb290%7C72f988bf86f1
> 41af91ab2d7cd011db47%7C1&amp;sdata=Vze8H22CyJb8ZWOybmNf6pHV6bCIvEYQB9F
> ymq1u0zM%3D&amp;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&amp;data=01
> %7C01%7Cv-lgold%40microsoft.com%7Cb349bab6bb2a44c009ea08d6ccccb290%7C7
> 2f988bf86f141af91ab2d7cd011db47%7C1&amp;sdata=gX%2BHBb4GtXAeBFmajZ051x
> LU7JVJbE5Ieq9JGjpJpMM%3D&amp;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&amp;data=0
> 1%7C01%7Cv-lgold%40microsoft.com%7Cb349bab6bb2a44c009ea08d6ccccb290%7C
> 72f988bf86f141af91ab2d7cd011db47%7C1&amp;sdata=gX%2BHBb4GtXAeBFmajZ051
> xLU7JVJbE5Ieq9JGjpJpMM%3D&amp;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&amp;data=01%7C01%7Cv-lgo
> ld%40microsoft.com%7Cb349bab6bb2a44c009ea08d6ccccb290%7C72f988bf86f141
> af91ab2d7cd011db47%7C1&amp;sdata=2mHcTNY7mAB439SIzOyDUa9LyQynm9GzWJHe9
> 9D1T7g%3D&amp;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&amp;data=01%7C01%7Cv-lg
> old%40microsoft.com%7Cb349bab6bb2a44c009ea08d6ccccb290%7C72f988bf86f14
> 1af91ab2d7cd011db47%7C1&amp;sdata=2mHcTNY7mAB439SIzOyDUa9LyQynm9GzWJHe
> 99D1T7g%3D&amp;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&amp;data=01%7C01%7Cv-lgol
> d%40microsoft.com%7Cb349bab6bb2a44c009ea08d6ccccb290%7C72f988bf86f141a
> f91ab2d7cd011db47%7C1&amp;sdata=Av%2BpFv%2FCvb%2FcVdPEuHQn0TDC%2Biv92J
> qPjGp66ej2%2FZY%3D&amp;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&amp;data=01%7C01%7Cv-lgo
> ld%40microsoft.com%7Cb349bab6bb2a44c009ea08d6ccccb290%7C72f988bf86f141
> af91ab2d7cd011db47%7C1&amp;sdata=Av%2BpFv%2FCvb%2FcVdPEuHQn0TDC%2Biv92
> JqPjGp66ej2%2FZY%3D&amp;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]