OASIS Static Analysis Results Interchange Format (SARIF) TC

When I made the location changes (#130), I wrote in the spec that codeFlowLocation.location is required. Seems sensible, right?   But when Chris made the SDK changes, he found that the SDV converter sometimes creates code flow locations with no location-related information. If we make codeFlowLocation.location   required, these code flow locations end up with an empty location   object:   Sarif.FunctionalTests/ConverterTestData/StaticDriverVerifier/checkadddevice_bug1.tt.sarif { { "step": 3, "step": 3, + "location": {}, "kind": "continuation", "kind": "continuation", "importance": "unimportant" "importance": "unimportant" },   Is this a converter bug, or does it really make sense for a codeFlowLocation to have no location property?   Larry

Well, the SDV team found it useful to capture the notion of a location-free ‘continuance’ kind. You can think of this record as a kind of location-free ‘edge’ between to interesting locations. You could imagine trying to produce an actual location for this part of the execution flow but the SDV team apparently didn’t find that helpful as far as building its viewer experience is concerned.   I’ve thought about this a bit and I wonder whether we shouldn’t loosen the restriction. If you think about concurrent analyses in particular, they might be developed against execution that has more to do with the synchronization/ordering of various things (like resource access) rather than a specific location. And so you can imagine a tool that might provide a speculative entry intended to represent, e.g., ‘at this point in time, an unknown external resource locks a file’. There would be no location for the code flow element to represent this. Obviously, other parts of the code flow (covering the code in question that needs to be proof against unexpected file locks) would have location details.   Michael From: Larry Golding (Comcast) <larrygolding@comcast.net> Sent: Saturday, April 7, 2018 10:38 AM To: Michael Fanning <Michael.Fanning@microsoft.com> Cc: sarif@lists.oasis-open.org Subject: codeFlowLocation.location not required   When I made the location changes (#130), I wrote in the spec that codeFlowLocation.location is required. Seems sensible, right?   But when Chris made the SDK changes, he found that the SDV converter sometimes creates code flow locations with no location-related information. If we make codeFlowLocation.location   required, these code flow locations end up with an empty location   object:   Sarif.FunctionalTests/ConverterTestData/StaticDriverVerifier/checkadddevice_bug1.tt.sarif { { "step": 3, "step": 3, + "location": {}, "kind": "continuation", "kind": "continuation", "importance": "unimportant" "importance": "unimportant" },   Is this a converter bug, or does it really make sense for a codeFlowLocation to have no location property?   Larry

“at this point in time, an unknown external resource locks a file”   … sounds like a plausible use for this. You can probably think of others. Unless anyone objects, I’ll make that change in the spec.   Larry   From: Michael Fanning <Michael.Fanning@microsoft.com> Sent: Monday, April 9, 2018 1:52 PM To: Larry Golding (Comcast) <larrygolding@comcast.net> Cc: sarif@lists.oasis-open.org Subject: RE: codeFlowLocation.location not required   Well, the SDV team found it useful to capture the notion of a location-free ‘continuance’ kind. You can think of this record as a kind of location-free ‘edge’ between to interesting locations. You could imagine trying to produce an actual location for this part of the execution flow but the SDV team apparently didn’t find that helpful as far as building its viewer experience is concerned.   I’ve thought about this a bit and I wonder whether we shouldn’t loosen the restriction. If you think about concurrent analyses in particular, they might be developed against execution that has more to do with the synchronization/ordering of various things (like resource access) rather than a specific location. And so you can imagine a tool that might provide a speculative entry intended to represent, e.g., ‘at this point in time, an unknown external resource locks a file’. There would be no location for the code flow element to represent this. Obviously, other parts of the code flow (covering the code in question that needs to be proof against unexpected file locks) would have location details.   Michael From: Larry Golding (Comcast) < larrygolding@comcast.net > Sent: Saturday, April 7, 2018 10:38 AM To: Michael Fanning < Michael.Fanning@microsoft.com > Cc: sarif@lists.oasis-open.org Subject: codeFlowLocation.location not required   When I made the location changes (#130), I wrote in the spec that codeFlowLocation.location is required. Seems sensible, right?   But when Chris made the SDK changes, he found that the SDV converter sometimes creates code flow locations with no location-related information. If we make codeFlowLocation.location   required, these code flow locations end up with an empty location   object:   Sarif.FunctionalTests/ConverterTestData/StaticDriverVerifier/checkadddevice_bug1.tt.sarif { { "step": 3, "step": 3, + "location": {}, "kind": "continuation", "kind": "continuation", "importance": "unimportant" "importance": "unimportant" },   Is this a converter bug, or does it really make sense for a codeFlowLocation to have no location property?   Larry

TL;DR: We can make codeFlowLocation optional, but then we need codeFlowLocation.message (and stackFrame.message).   In Michael’s scenario, we’d want to associate a message like “Resource was locked” with a codeFlowLocation . Now, when we did the location redesign (#130), we removed annotatedCodeLocation.message , because we reasoned “ codeFlowLocation has a location property, and the location object has a message property, so we don’t need codeFlowLocation.message .”   But in Michael’s scenario,   codeFlowLocation can’t rely on location.message ,  so codeFlowLocation needs a message of its own. In fact, we should never have allowed codeFlowLocation to rely on location.message , because the same code flow could hit the same location multiple times. And the same is true for stackFrame , if the stack has a recursive call.   I filed two CSD.1 issues:   #139 : Don’t require codeFlowLocation.location . #140 : Restore codeFlowLocation.message and stackFrame.message .   Larry   From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Comcast) Sent: Monday, April 9, 2018 2:18 PM To: 'Michael Fanning' <Michael.Fanning@microsoft.com> Cc: sarif@lists.oasis-open.org Subject: [sarif] RE: codeFlowLocation.location not required   “at this point in time, an unknown external resource locks a file”   … sounds like a plausible use for this. You can probably think of others. Unless anyone objects, I’ll make that change in the spec.   Larry   From: Michael Fanning < Michael.Fanning@microsoft.com > Sent: Monday, April 9, 2018 1:52 PM To: Larry Golding (Comcast) < larrygolding@comcast.net > Cc: sarif@lists.oasis-open.org Subject: RE: codeFlowLocation.location not required   Well, the SDV team found it useful to capture the notion of a location-free ‘continuance’ kind. You can think of this record as a kind of location-free ‘edge’ between to interesting locations. You could imagine trying to produce an actual location for this part of the execution flow but the SDV team apparently didn’t find that helpful as far as building its viewer experience is concerned.   I’ve thought about this a bit and I wonder whether we shouldn’t loosen the restriction. If you think about concurrent analyses in particular, they might be developed against execution that has more to do with the synchronization/ordering of various things (like resource access) rather than a specific location. And so you can imagine a tool that might provide a speculative entry intended to represent, e.g., ‘at this point in time, an unknown external resource locks a file’. There would be no location for the code flow element to represent this. Obviously, other parts of the code flow (covering the code in question that needs to be proof against unexpected file locks) would have location details.   Michael From: Larry Golding (Comcast) < larrygolding@comcast.net > Sent: Saturday, April 7, 2018 10:38 AM To: Michael Fanning < Michael.Fanning@microsoft.com > Cc: sarif@lists.oasis-open.org Subject: codeFlowLocation.location not required   When I made the location changes (#130), I wrote in the spec that codeFlowLocation.location is required. Seems sensible, right?   But when Chris made the SDK changes, he found that the SDV converter sometimes creates code flow locations with no location-related information. If we make codeFlowLocation.location   required, these code flow locations end up with an empty location   object:   Sarif.FunctionalTests/ConverterTestData/StaticDriverVerifier/checkadddevice_bug1.tt.sarif { { "step": 3, "step": 3, + "location": {}, "kind": "continuation", "kind": "continuation", "importance": "unimportant" "importance": "unimportant" },   Is this a converter bug, or does it really make sense for a codeFlowLocation to have no location property?   Larry

Come to think of it, two different code flows could refer to the same location, and likewise two different stack frames, so we don’t even need to appeal to recursion to justify restoring stackFrame.message .   From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Comcast) Sent: Wednesday, April 11, 2018 3:17 PM To: 'Michael Fanning' <Michael.Fanning@microsoft.com> Cc: sarif@lists.oasis-open.org Subject: RE: [sarif] RE: codeFlowLocation.location not required   TL;DR: We can make codeFlowLocation optional, but then we need codeFlowLocation.message (and stackFrame.message).   In Michael’s scenario, we’d want to associate a message like “Resource was locked” with a codeFlowLocation . Now, when we did the location redesign (#130), we removed annotatedCodeLocation.message , because we reasoned “ codeFlowLocation has a location property, and the location object has a message property, so we don’t need codeFlowLocation.message .”   But in Michael’s scenario,   codeFlowLocation can’t rely on location.message ,  so codeFlowLocation needs a message of its own. In fact, we should never have allowed codeFlowLocation to rely on location.message , because the same code flow could hit the same location multiple times. And the same is true for stackFrame , if the stack has a recursive call.   I filed two CSD.1 issues:   #139 : Don’t require codeFlowLocation.location . #140 : Restore codeFlowLocation.message and stackFrame.message .   Larry   From: sarif@lists.oasis-open.org < sarif@lists.oasis-open.org > On Behalf Of Larry Golding (Comcast) Sent: Monday, April 9, 2018 2:18 PM To: 'Michael Fanning' < Michael.Fanning@microsoft.com > Cc: sarif@lists.oasis-open.org Subject: [sarif] RE: codeFlowLocation.location not required   “at this point in time, an unknown external resource locks a file”   … sounds like a plausible use for this. You can probably think of others. Unless anyone objects, I’ll make that change in the spec.   Larry   From: Michael Fanning < Michael.Fanning@microsoft.com > Sent: Monday, April 9, 2018 1:52 PM To: Larry Golding (Comcast) < larrygolding@comcast.net > Cc: sarif@lists.oasis-open.org Subject: RE: codeFlowLocation.location not required   Well, the SDV team found it useful to capture the notion of a location-free ‘continuance’ kind. You can think of this record as a kind of location-free ‘edge’ between to interesting locations. You could imagine trying to produce an actual location for this part of the execution flow but the SDV team apparently didn’t find that helpful as far as building its viewer experience is concerned.   I’ve thought about this a bit and I wonder whether we shouldn’t loosen the restriction. If you think about concurrent analyses in particular, they might be developed against execution that has more to do with the synchronization/ordering of various things (like resource access) rather than a specific location. And so you can imagine a tool that might provide a speculative entry intended to represent, e.g., ‘at this point in time, an unknown external resource locks a file’. There would be no location for the code flow element to represent this. Obviously, other parts of the code flow (covering the code in question that needs to be proof against unexpected file locks) would have location details.   Michael From: Larry Golding (Comcast) < larrygolding@comcast.net > Sent: Saturday, April 7, 2018 10:38 AM To: Michael Fanning < Michael.Fanning@microsoft.com > Cc: sarif@lists.oasis-open.org Subject: codeFlowLocation.location not required   When I made the location changes (#130), I wrote in the spec that codeFlowLocation.location is required. Seems sensible, right?   But when Chris made the SDK changes, he found that the SDV converter sometimes creates code flow locations with no location-related information. If we make codeFlowLocation.location   required, these code flow locations end up with an empty location   object:   Sarif.FunctionalTests/ConverterTestData/StaticDriverVerifier/checkadddevice_bug1.tt.sarif { { "step": 3, "step": 3, + "location": {}, "kind": "continuation", "kind": "continuation", "importance": "unimportant" "importance": "unimportant" },   Is this a converter bug, or does it really make sense for a codeFlowLocation to have no location property?   Larry

Please ignore the nonsense I wrote in my last two messages, about codeFlowLocation and stackFrame not being able to rely on location.message because the same location might appear more than once in a result’s code flows or stacks.   I was imagining that codeFlowLocation s and stackFrame s referred to locations by reference, which of course isn’t true – each codeFlowLocation and stackFrame embeds its own location object, even if some of them refer to the same location.   So we’re back to my original argument, except without the silly parts:   In Michael’s scenario, we’d want to associate a message like “Resource was locked” with a codeFlowLocation . Now, when we did the location redesign (#130), we removed annotatedCodeLocation.message , because we reasoned “ codeFlowLocation has a location property, and the location object has a message property, so we don’t need codeFlowLocation.message .”   But in Michael’s scenario,   codeFlowLocation can’t rely on location.message ,  so codeFlowLocation needs a message of its own.   And frankly I’m reluctant to add codeFlowLocation.message just to cover this corner case.   What are your thoughts?   Larry   From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Comcast) Sent: Wednesday, April 11, 2018 3:23 PM To: 'Michael Fanning' <Michael.Fanning@microsoft.com> Cc: sarif@lists.oasis-open.org Subject: RE: [sarif] RE: codeFlowLocation.location not required   Come to think of it, two different code flows could refer to the same location, and likewise two different stack frames, so we don’t even need to appeal to recursion to justify restoring stackFrame.message .   From: sarif@lists.oasis-open.org < sarif@lists.oasis-open.org > On Behalf Of Larry Golding (Comcast) Sent: Wednesday, April 11, 2018 3:17 PM To: 'Michael Fanning' < Michael.Fanning@microsoft.com > Cc: sarif@lists.oasis-open.org Subject: RE: [sarif] RE: codeFlowLocation.location not required   TL;DR: We can make codeFlowLocation optional, but then we need codeFlowLocation.message (and stackFrame.message).   In Michael’s scenario, we’d want to associate a message like “Resource was locked” with a codeFlowLocation . Now, when we did the location redesign (#130), we removed annotatedCodeLocation.message , because we reasoned “ codeFlowLocation has a location property, and the location object has a message property, so we don’t need codeFlowLocation.message .”   But in Michael’s scenario,   codeFlowLocation can’t rely on location.message ,  so codeFlowLocation needs a message of its own. In fact, we should never have allowed codeFlowLocation to rely on location.message , because the same code flow could hit the same location multiple times. And the same is true for stackFrame , if the stack has a recursive call.   I filed two CSD.1 issues:   #139 : Don’t require codeFlowLocation.location . #140 : Restore codeFlowLocation.message and stackFrame.message .   Larry   From: sarif@lists.oasis-open.org < sarif@lists.oasis-open.org > On Behalf Of Larry Golding (Comcast) Sent: Monday, April 9, 2018 2:18 PM To: 'Michael Fanning' < Michael.Fanning@microsoft.com > Cc: sarif@lists.oasis-open.org Subject: [sarif] RE: codeFlowLocation.location not required   “at this point in time, an unknown external resource locks a file”   … sounds like a plausible use for this. You can probably think of others. Unless anyone objects, I’ll make that change in the spec.   Larry   From: Michael Fanning < Michael.Fanning@microsoft.com > Sent: Monday, April 9, 2018 1:52 PM To: Larry Golding (Comcast) < larrygolding@comcast.net > Cc: sarif@lists.oasis-open.org Subject: RE: codeFlowLocation.location not required   Well, the SDV team found it useful to capture the notion of a location-free ‘continuance’ kind. You can think of this record as a kind of location-free ‘edge’ between to interesting locations. You could imagine trying to produce an actual location for this part of the execution flow but the SDV team apparently didn’t find that helpful as far as building its viewer experience is concerned.   I’ve thought about this a bit and I wonder whether we shouldn’t loosen the restriction. If you think about concurrent analyses in particular, they might be developed against execution that has more to do with the synchronization/ordering of various things (like resource access) rather than a specific location. And so you can imagine a tool that might provide a speculative entry intended to represent, e.g., ‘at this point in time, an unknown external resource locks a file’. There would be no location for the code flow element to represent this. Obviously, other parts of the code flow (covering the code in question that needs to be proof against unexpected file locks) would have location details.   Michael From: Larry Golding (Comcast) < larrygolding@comcast.net > Sent: Saturday, April 7, 2018 10:38 AM To: Michael Fanning < Michael.Fanning@microsoft.com > Cc: sarif@lists.oasis-open.org Subject: codeFlowLocation.location not required   When I made the location changes (#130), I wrote in the spec that codeFlowLocation.location is required. Seems sensible, right?   But when Chris made the SDK changes, he found that the SDV converter sometimes creates code flow locations with no location-related information. If we make codeFlowLocation.location   required, these code flow locations end up with an empty location   object:   Sarif.FunctionalTests/ConverterTestData/StaticDriverVerifier/checkadddevice_bug1.tt.sarif { { "step": 3, "step": 3, + "location": {}, "kind": "continuation", "kind": "continuation", "importance": "unimportant" "importance": "unimportant" },   Is this a converter bug, or does it really make sense for a codeFlowLocation to have no location property?   Larry

And to clarify, I say that in this case, “ codeFlowLocation can’t rely on location.message ” because I don’t want to allow a location object that consists of nothing but a message:   {                     # A codeFlowLocation object   "step": 1,   "location": {     "message": {       "text": "Resource was locked."     }   } }   But perhaps we could allow it.   Larry   From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Comcast) Sent: Thursday, April 12, 2018 9:04 AM To: 'Michael Fanning' <Michael.Fanning@microsoft.com> Cc: sarif@lists.oasis-open.org Subject: RE: [sarif] RE: codeFlowLocation.location not required   Please ignore the nonsense I wrote in my last two messages, about codeFlowLocation and stackFrame not being able to rely on location.message because the same location might appear more than once in a result’s code flows or stacks.   I was imagining that codeFlowLocation s and stackFrame s referred to locations by reference, which of course isn’t true – each codeFlowLocation and stackFrame embeds its own location object, even if some of them refer to the same location.   So we’re back to my original argument, except without the silly parts:   In Michael’s scenario, we’d want to associate a message like “Resource was locked” with a codeFlowLocation . Now, when we did the location redesign (#130), we removed annotatedCodeLocation.message , because we reasoned “ codeFlowLocation has a location property, and the location object has a message property, so we don’t need codeFlowLocation.message .”   But in Michael’s scenario,   codeFlowLocation can’t rely on location.message ,  so codeFlowLocation needs a message of its own.   And frankly I’m reluctant to add codeFlowLocation.message just to cover this corner case.   What are your thoughts?   Larry   From: sarif@lists.oasis-open.org < sarif@lists.oasis-open.org > On Behalf Of Larry Golding (Comcast) Sent: Wednesday, April 11, 2018 3:23 PM To: 'Michael Fanning' < Michael.Fanning@microsoft.com > Cc: sarif@lists.oasis-open.org Subject: RE: [sarif] RE: codeFlowLocation.location not required   Come to think of it, two different code flows could refer to the same location, and likewise two different stack frames, so we don’t even need to appeal to recursion to justify restoring stackFrame.message .   From: sarif@lists.oasis-open.org < sarif@lists.oasis-open.org > On Behalf Of Larry Golding (Comcast) Sent: Wednesday, April 11, 2018 3:17 PM To: 'Michael Fanning' < Michael.Fanning@microsoft.com > Cc: sarif@lists.oasis-open.org Subject: RE: [sarif] RE: codeFlowLocation.location not required   TL;DR: We can make codeFlowLocation optional, but then we need codeFlowLocation.message (and stackFrame.message).   In Michael’s scenario, we’d want to associate a message like “Resource was locked” with a codeFlowLocation . Now, when we did the location redesign (#130), we removed annotatedCodeLocation.message , because we reasoned “ codeFlowLocation has a location property, and the location object has a message property, so we don’t need codeFlowLocation.message .”   But in Michael’s scenario,   codeFlowLocation can’t rely on location.message ,  so codeFlowLocation needs a message of its own. In fact, we should never have allowed codeFlowLocation to rely on location.message , because the same code flow could hit the same location multiple times. And the same is true for stackFrame , if the stack has a recursive call.   I filed two CSD.1 issues:   #139 : Don’t require codeFlowLocation.location . #140 : Restore codeFlowLocation.message and stackFrame.message .   Larry   From: sarif@lists.oasis-open.org < sarif@lists.oasis-open.org > On Behalf Of Larry Golding (Comcast) Sent: Monday, April 9, 2018 2:18 PM To: 'Michael Fanning' < Michael.Fanning@microsoft.com > Cc: sarif@lists.oasis-open.org Subject: [sarif] RE: codeFlowLocation.location not required   “at this point in time, an unknown external resource locks a file”   … sounds like a plausible use for this. You can probably think of others. Unless anyone objects, I’ll make that change in the spec.   Larry   From: Michael Fanning < Michael.Fanning@microsoft.com > Sent: Monday, April 9, 2018 1:52 PM To: Larry Golding (Comcast) < larrygolding@comcast.net > Cc: sarif@lists.oasis-open.org Subject: RE: codeFlowLocation.location not required   Well, the SDV team found it useful to capture the notion of a location-free ‘continuance’ kind. You can think of this record as a kind of location-free ‘edge’ between to interesting locations. You could imagine trying to produce an actual location for this part of the execution flow but the SDV team apparently didn’t find that helpful as far as building its viewer experience is concerned.   I’ve thought about this a bit and I wonder whether we shouldn’t loosen the restriction. If you think about concurrent analyses in particular, they might be developed against execution that has more to do with the synchronization/ordering of various things (like resource access) rather than a specific location. And so you can imagine a tool that might provide a speculative entry intended to represent, e.g., ‘at this point in time, an unknown external resource locks a file’. There would be no location for the code flow element to represent this. Obviously, other parts of the code flow (covering the code in question that needs to be proof against unexpected file locks) would have location details.   Michael From: Larry Golding (Comcast) < larrygolding@comcast.net > Sent: Saturday, April 7, 2018 10:38 AM To: Michael Fanning < Michael.Fanning@microsoft.com > Cc: sarif@lists.oasis-open.org Subject: codeFlowLocation.location not required   When I made the location changes (#130), I wrote in the spec that codeFlowLocation.location is required. Seems sensible, right?   But when Chris made the SDK changes, he found that the SDV converter sometimes creates code flow locations with no location-related information. If we make codeFlowLocation.location   required, these code flow locations end up with an empty location   object:   Sarif.FunctionalTests/ConverterTestData/StaticDriverVerifier/checkadddevice_bug1.tt.sarif { { "step": 3, "step": 3, + "location": {}, "kind": "continuation", "kind": "continuation", "importance": "unimportant" "importance": "unimportant" },   Is this a converter bug, or does it really make sense for a codeFlowLocation to have no location property?   Larry

So, any thoughts on this? If you go all the way back to the bottom of this thread, and then look at the sample at the very top, do we conclude:   codeFlowLocation.location is still required, but It’s ok for the location object to just have a message property Then we’d have to express constraints like “the location has to have either a physical location, or a logical location, or both – but if it has neither, at least it has to have a message”. Confusing!   Or do we conclude:   codeFlowLocation.location is optional after all, but then… codeFlowLocation should have its own message property, in case the producer wants to say something about this step even in the absence of a location. Then if there’s a “real” location, can codeFlowLocation.message and codeFlowLocation.location.message both be present? How should we explain to producers which one to use. Confusing!   Or… something else?   All this comes about because Static Driver Verifies emits these “steps” that don’t have associated locations. And then, sure, Michael comes up with a scenario where that’s a good thing

Yes, this seems to resolve the problem. We have a notional location but are not exactly sure what it’s physical or logical details are, but we have some text to explain what it refers to, conceptually. Fine.

Glad you approve. It will take a little more text to explain this usage of “location”, but I’ll try to keep it brief