sarif — archive

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

From: Laurence Golding
To: [email protected]
Date: Mon, 29 Apr 2019 17:18:00 -0000

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) <[email protected]> Sent: Monday, April 29, 2019 10:16 AM To: Larry Golding (Myriad Consulting Inc) <[email protected]>; James Kupsch <[email protected]>; Michael Fanning <[email protected]>; OASIS SARIF TC Discussion List <[email protected]> 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 address object occurs within a physicalLocation object thisObject , and if thisObject.length and thisObject.address.length are both present, then then SHALL be equal. As the spec stands, I can t write this because physicalLocation.length is non-negative. I can add words like this: If an address object occurs within a physicalLocation object thisObject , and if thisObject.length and thisObject.address.length are both present, then then SHALL be equal. In that case, if thisObject.address.length is negative, then thisObject.length will also be negative. In all other circumstances, length SHALL be non-negative. Michael , are you ok with that complication? Larry From: [email protected] < [email protected] > On Behalf Of Larry Golding (Myriad Consulting Inc) Sent: Monday, April 29, 2019 10:08 AM To: James Kupsch < [email protected] >; Michael Fanning < [email protected] >; OASIS SARIF TC Discussion List < [email protected] > 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 < [email protected] > Sent: Monday, April 29, 2019 8:40 AM To: Michael Fanning < [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 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: [email protected] <[email protected]> On Behalf Of James Kupsch Sent: Monday, April 29, 2019 8:06 AM To: Larry Golding (Myriad Consulting Inc) <[email protected]> ; OASIS SARIF TC Discussion List <[email protected]> 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