-
Notifications
You must be signed in to change notification settings - Fork 514
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
✨ New Probe: Memory safety #4499
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: balteravishay <[email protected]>
The intention was always to sort, but the wrong sort function was used. This led to an unsorted list, which was dependent on map iteration order, leading to flaky unit tests. This was reproducible with go test when passing a large --count option. Signed-off-by: Spencer Schrock <[email protected]> Signed-off-by: balteravishay <[email protected]>
Signed-off-by: balteravishay <[email protected]>
Signed-off-by: balteravishay <[email protected]>
Since upgrading to v1.9.1 we've had performance issues in the weekly analysis, which may be related to one of the Maven features here. Signed-off-by: Spencer Schrock <[email protected]> Signed-off-by: balteravishay <[email protected]>
…sf#4467) Signed-off-by: balteravishay <[email protected]>
Signed-off-by: balteravishay <[email protected]>
Signed-off-by: balteravishay <[email protected]>
Signed-off-by: balteravishay <[email protected]>
Signed-off-by: balteravishay <[email protected]>
Signed-off-by: balteravishay <[email protected]>
a159254
to
56f3ef7
Compare
Signed-off-by: balteravishay <[email protected]>
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4499 +/- ##
==========================================
+ Coverage 66.80% 68.61% +1.80%
==========================================
Files 230 247 +17
Lines 16602 18573 +1971
==========================================
+ Hits 11091 12743 +1652
- Misses 4808 4997 +189
- Partials 703 833 +130 |
Signed-off-by: balteravishay <[email protected]>
Signed-off-by: balteravishay <[email protected]>
Signed-off-by: balteravishay <[email protected]>
here are some repos to test the code: go run main.go --repo github.com/microsoft/midi --probes memorysafe --format probe (.net unsafe code) |
Signed-off-by: balteravishay <[email protected]>
Hoping to have some time to look at this tomorrow. Quick question about organization:
Probes are usually one specific behavior. In this case, the probe is concerned with looking for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
didn't quite go through the tests yet, since the semantics of the probe will probably change through this discussion.
id: memorysafe | ||
lifecycle: experimental | ||
short: Flags non memory safe practices in this project. | ||
motivation: > | ||
Memory safety in software should be considered a continuum, rather than being binary. | ||
This probe does not consider a specific ecosystem more or less memory safe than another, but rather tries to surface non memory safe code or practices in the project, in the context of the ecosystems it is using. | ||
implementation: > | ||
The probe is ecosystem-specific and tries to flag non memory safe code blocks in the project by looking at the code and practices used in the project. | ||
It may look for specific memory safety practices, such as the use tools or non memory-safe patterns and code. | ||
The probe supports multiple checks for each ecosystem, and the outcome is based on the results of these checks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this would need to be altered to focus on just unsafe
detection if the probe does just one thing. Though unsafe
is too generic.
So maybe something like unsafeblock
? Open to suggestions/brainstorming.
probes/memorysafe/impl.go
Outdated
"Golang code uses the unsafe package", &finding.Location{ | ||
Path: path, | ||
}, finding.OutcomeFalse) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we have much more info than path available if we use :
https://pkg.go.dev/go/ast#ImportSpec.Pos and https://pkg.go.dev/go/ast#ImportSpec.End
Something like:
position := fset.Position(i.Pos())
and then we have access to line info too and can set finding. LineStart
. https://pkg.go.dev/go/token#Position
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added linestart. do you think any other information should be added?
the intention of this probe is to save the end user the need to know which best practices they are expected to have in the repo, and to give them a kind of a one stop shop for finding out if there's anything they're missing. Our goal was to try and implement the different practices that are suggested in the memory safety guides for memory-safe-by-default and non-memory-safe-by-default guides into this single probe. |
Signed-off-by: balteravishay <[email protected]>
What kind of change does this PR introduce?
This PR provides the foundation for addressing issue #3736 by adding a new probe that checks if the code uses non memory safe practices for the repository languages.
The goal is to automate the detection of as many of the practices that the memory safety SIG provides under the Best Practices - Memory-Safe By Default Languages and the Best Practices - Non Memory-Safe By Default Languages guides.
What is the current behavior?
Today scorecard does not detect memory safe practices in it's core features or in any of the probes.
What is the new behavior (if this is a feature change)?**
Probe detects the following:
for golang it detects if the code imports the unsafe package and points to the locations where it is used.
for c# it detects if the projects allow for unsafe blocks which is a requirement for any project that would use any form of .Net unsafe code, pointer types, and function pointers
Tests for the changes have been added (for bug fixes/features)
Which issue(s) this PR fixes
This code change addresses issue #3736 but does not close it (to be discussed)
Special notes for your reviewer
This code change and the implementation of it were discussed in scorecard community calls with @spencerschrock
Does this PR introduce a user-facing change?
For user-facing changes, please add a concise, human-readable release note to
the
release-note
(In particular, describe what changes users might need to make in their
application as a result of this pull request.)