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) <>
Sent: Monday, April 29, 2019 10:16 AM
To: Larry Golding (Myriad Consulting Inc) <>; James Kupsch <>; Michael Fanning <>; OASIS SARIF TC Discussion List <>
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:
<
>
On Behalf Of Larry Golding (Myriad Consulting Inc)
Sent: Monday, April 29, 2019 10:08 AM
To: James Kupsch < >; Michael Fanning < >; OASIS SARIF TC Discussion List <
>
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 <
>
Sent: Monday, April 29, 2019 8:40 AM
To: Michael Fanning < >; Larry Golding (Myriad Consulting Inc) < >; OASIS SARIF TC Discussion List <
>
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:
<>
On Behalf Of James Kupsch
Sent: Monday, April 29, 2019 8:06 AM
To: Larry Golding (Myriad Consulting Inc)
<> ; OASIS SARIF TC Discussion List
<>
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
