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


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>
Sent: Monday, April 29, 2019 8:40 AM
To: Michael Fanning <Michael.Fanning@microsoft.com>; 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

 

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

 

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, â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 😊) 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:
    • 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â
    • 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://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ProvisionalDrafts/sarif-v2.0-csd02-provisional.htm

 

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]