-
Notifications
You must be signed in to change notification settings - Fork 444
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
Static code analysis #911
Comments
Hi @gabibguti. Thanks for the information and for doing the research on SAST options for Fortran. I believe we don't use any SAST currently. |
@weslleyspereira I looked at i-CodeCNES and it seems it suggests a lot of changes which are probably a bit unnecessary, e.g. avoiding multiple RETURN statements in routines (see output below). I'll let it run on the entire codebase (it's pretty slow) and collect all types of warnings it produces. Then we can discuss which of those if any really matter. On the topic of code analysis, do we use Gfortran's sanitizers somewhere (ASAN, UBSAN, MSAN, TSAN)? If not, we (NAG) have some CMake modules which I could add to LAPACK's CMake system and enable those checks in the pipelines.
|
This is all great @ACSimon33. Thanks a lot for the help on this topic!
I was already expecting these tools would suggest changes that would involve too much work on our side. Thanks for digging through it. It would be great to have a list of those suggestions. Then we could decide what we want to apply.
I believe we don't use any code sanitizer either. Please, feel welcomed to try them on! I recall we had a discussion about the usage of Valgrind tool with
Oh! This is a lot of information for a single file. I can imagine how slow the complete process can be. Thanks for sharing! |
@weslleyspereira I tried some of the static analysis tools now and here are some of the results. i-CodeCNESPro: Free, opensource, easy to install and use Warnings (only in Reference BLAS)
In the LAPACK sources there are mostly the same warnings but approx. 30 times as much. In my opinion there is nothing in here that is really a serious issue. plusFORTPro: Easy to install and use, summary of results, free for non-commercial projects Warnings in BLAS sources
Warnings in LAPACK sources
Warnings in complex LAPACK sources
Warnings in BLAS TESTING sources
Warnings in LAPACK TESTING sources
I think the interesting warnings here are those about fptPro: Nice summaries, a lot of features Warnings in BLAS and LAPACK
Warnings in TESTING sources
Here again, the Overall I think we can ignore most of these warnings, especially those in the testing frameworks, but I'd like to here other opinions. |
Raw result files (not all, some are too big): fpt_TESTING.log |
Sharing my point of view on i-CodeCNES: This tool implements a set of coding rules defined by CNES and are mostly generic coding "good-practice rules". What we want to know is if rule XYZ implies in a security vulnerability or not. But, these rules cannot be directly mapped to known vulnerability systems, such as those defined by CWE, so it's harder to understand the security implications of violating a rule. I will try to give a few examples given the warnings found.
So, all of these rules are "good-practice rules" and there's no security harm in violating them if the problem does not reach a relevant operation in a relevant context, such as doing a wrong calculation when performing an authorization or entering a memory buffer overflow when manipulating user data. But, if is a relevant operation in a relevant context then the rule is important. This is meant to explain how the warnings can represent serious issues, but really depends on the context the warning is being raised. |
Based on
The i-CodeCNES documentation lists the different warnings but does not always clarify why they exist. For example, why is passing constants to a function (line 235) being warned about? Without this reasoning I cannot identify a single useful warning for ZHERK. |
The i-CodeCNES documentation mentions three Fortran-specific warnings that are disabled by default but they seem useless for non-testing code since LAPACK neither opens files nor allocates memory.
|
Hey! Do you already use a static code analysis tool? Also known as SAST.
SAST is used to identify security vulnerabilities in your source code. Vulnerabilities such as buffer overflow where attackers can modify the application execution by writing to memory. Different than Fuzzing, where you have to setup your test cases, SAST tools have their own set of test cases that they'll check against your code.
So, adding SAST helps keep your code safe from vulnerabilities, but I understand it comes along additional work to handle the reports.
Referencing here some SAST options I found for Fortran:
Additional Context
Hi! I'm Gabriela and I work on behalf of Google and the OpenSSF suggesting supply-chain security changes :)
The text was updated successfully, but these errors were encountered: