sarif — archive

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

From: Jim Kupsch
To: [email protected]
Date: Mon, 29 Apr 2019 21:19:00 -0000

If you add a relativeToAddressIndex, then instead of making it relative to the top-most parent, you can make it relative to this object, and -1 works here as it can indicate unknown. This also allows two addresses (only if the relativeToAddressIndex are identical and not -1) to be compared, and allows relativeness to other containers than the top most which might be more relevant. Below is an example. Empty values are unknown. name: STACK1 kind: stack length: -300000 offsetFromParent: parentIndex: relativeAddress: relativeToAddressIndex : absoluteAddress: 1250000 name: STACK1.frame4 kind: stackFrame length: -2000 offsetFromParent: -1000 parentIndex: 0 relativeAddress : -1000 relativeToAddressIndex : 0 absoluteAddress: 1249000 name: variable444 kind: intData length: 8 offsetFromParent: 32 parentIndex: 1 relativeAddress : -968 relativeToAddressIndex : 0 absoluteAddress: 1249030 On 4/29/19 3:20 PM, Larry Golding (Myriad Consulting Inc) wrote: There s a problem with relativeAddress , though. Here s what I currently have: 3.32.4 Relative address calculation Each address object has an associated value called its relative address which is the offset of the address from the address of the top-most object in its parent chain 3.32.7 relativeAddress property If parentIndex ( 3.32.13 ) is present, an address object MAY contain a property named relativeAddress whose value is an integer containing the relative address (see 3.32.4 ) of thisObject . If parentIndex is absent, then relativeAddress SHALL be absent. If relativeAddress is absent, it SHALL default to -1, which is otherwise not a valid value for this property . That s wrong. If your top-most address is a downward-growing stack, relativeAddress can be negative. And unlike offsetFromParent , we can t say (I mean, we can , but don t think we should) that relativeAddress SHALL be present if parentIndex is present, so we can t use 0 as the default. Ideas? I m going to have lunch now. Back in a while. Larry From: [email protected] <[email protected]> On Behalf Of Larry Golding (Myriad Consulting Inc) Sent: Monday, April 29, 2019 12:59 PM To: Michael Fanning <[email protected]> ; James Kupsch <[email protected]> ; OASIS SARIF TC Discussion List <[email protected]> Subject: RE: [sarif] #401: Improved design of address object design I approve this message! Much better than my solution. From: Michael Fanning < [email protected] > Sent: Monday, April 29, 2019 12:56 PM To: James Kupsch < [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 Here s my suggestion: For address.length, use a sentinel value of 0 meaning not provided . This makes sense, as Jim noted, a 0 length memory address isn t sensible. You don t posit describing an insertion point in memory that shoves everything to the right. ð For address.offsetFromParent, this property should only be consulted in cases where address.parentIndex >= 0. If address.parentIndex is -1, you ignore the offsetFromParent value (in all cases). If address.parentIndex >= 0, the address.offsetFromParent must be populated (and it is fine if its value is 0). This requires producers to always provided offsetFromParent when using the address parenting chain. IOW, you can t describe your parenting relationship and depend strictly on relativeAddress and/or absoluteAddress to render those final computed values. I think this trade-off is ok, particularly as compared to consulting a separate Boolean in order to know whether you re going backward in memory. Michael From: James Kupsch < [email protected] > Sent: Monday, April 29, 2019 12:46 PM To: Larry Golding (Myriad Consulting Inc) < [email protected] >; Michael Fanning < [email protected] >; OASIS SARIF TC Discussion List < [email protected] > Subject: Re: [sarif] #401: Improved design of address object design The unknown is only for this address to its parents. The same problem exists whether you use -1 or unknownOffset/Length. It is useful to know offsets up to the point of where it is unknown as you at least know it is relative to this address (grand..)parent object. The cleaner approach to working around the SDK not supporting nullable is to use the extra boolean. On 4/29/19 2:18 PM, Larry Golding (Myriad Consulting Inc) wrote: I really think my previous suggestion of growthDirection is the least bad alternative if we decide NOT to use Nullable<int> . I d modify my proposal to a Boolean growsTowardLowMemory , default false . From: [email protected] <[email protected]> On Behalf Of Larry Golding (Myriad Consulting Inc) Sent: Monday, April 29, 2019 11:46 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 Importance: High I m not as happy as I was a few moments ago. If the unknown properties default to false , then if you don t populate offsetFromParent (which happens at the top of every parent chain) or length (which can happen anywhere along the parent chain), then you have to remember to set the corresponding unknown property. You won t. Of if the unknown properties default to true , you have to set them to false whenever you do populate offsetFromParent or length . You won t. Michael (addressing this question specifically to him because of the SDK impact), I don t see a good alternative to Nullable<int> . Please let us know your opinion. Raising to red-bang. Larry From: Larry Golding (Myriad Consulting Inc) Sent: Monday, April 29, 2019 11:37 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 I could accept Boolean unknownLength and unknownOffsetFromParent, default false for both. I will write it this way and send a draft. I can always change this aspect of the design if the TC objects. Larry