* [committed] gcc-12: analyzer changes
@ 2022-04-12 14:03 David Malcolm
2022-04-12 14:04 ` [wwwdocs] " David Malcolm
0 siblings, 1 reply; 2+ messages in thread
From: David Malcolm @ 2022-04-12 14:03 UTC (permalink / raw)
To: gcc-patches
I've pushed the following change to the website, covering -fanalyzer
changes in GCC 12.
---
htdocs/gcc-12/changes.html | 115 +++++++++++++++++++++++++++++++++++++
1 file changed, 115 insertions(+)
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 4652304d..d907ed22 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -749,6 +749,121 @@ function Multiply (S1, S2 : Sign) return Sign is
<!-- .................................................................. -->
<!-- <h2>Documentation improvements</h2> -->
+<h2 id="analyzer">Improvements to Static Analyzer</h2>
+<ul>
+ <li>The analyzer has gained a <a href="https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-use-of-uninitialized-value"><code>-Wanalyzer-use-of-uninitialized-value</code></a>
+ warning, similar to
+ <a href="https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wuninitialized"><code>-Wuninitialized</code></a>
+ and
+ <a href="https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wmaybe-uninitialized"><code>-Wmaybe-uninitialized</code></a>,
+ but based on an interprocedural path-sensitive analysis
+ (<a href="https://gcc.gnu.org/PR95006">PR95006</a>).
+ <p>Such warnings are not disabled by the new
+ <a href="https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-ftrivial-auto-var-init"><code>-ftrivial-auto-var-init</code></a>
+ (see below), as the latter is considered a mitigation option.</p>
+ </li>
+ <li><a href="https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-write-to-const"><code>-Wanalyzer-write-to-const</code></a>
+ and
+ <a href="https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-write-to-string-literal"><code>-Wanalyzer-write-to-string-literal</code></a>
+ will now check for
+ <a href="https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html"><code>__attribute__ ((access, ....))</code></a>
+ on calls to externally-defined functions, and complain about read-only
+ regions pointed to by arguments marked with a <code>write_only</code>
+ or <code>read_write</code> attribute
+ (<a href="https://gcc.gnu.org/PR104793">PR104793</a>).
+ </li>
+ <li>The analyzer's "taint" mode, activated by
+ <a href="https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-fanalyzer-checker"><code>-fanalyzer-checker=taint</code></a>
+ (in addition to <a href="https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-fanalyzer"><code>-fanalyzer</code></a>),
+ has gained four new taint-based warnings:
+ <ul>
+ <li><a href="https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-tainted-allocation-size"><code>-Wanalyzer-tainted-allocation-size</code></a>
+ for e.g. attacker-controlled <code>malloc</code>
+ and <code>alloca</code>,
+ </li>
+ <li><a href="https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-tainted-divisor"><code>-Wanalyzer-tainted-divisor</code></a>
+ for detecting where an attacker can inject a divide-by-zero,
+ </li>
+ <li><a href="https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-tainted-offset"><code>-Wanalyzer-tainted-offset</code></a>
+ for attacker-controlled pointer offsets,
+ </li>
+ <li><a href="https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-tainted-size"><code>-Wanalyzer-tainted-size</code></a>
+ for attacker-controlled values being used as a size parameter to
+ calls to <code>memset</code> or to functions marked with
+ <a href="https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html"><code>__attribute__ ((access, ....))</code></a>.
+ </li>
+ </ul>
+ <p>The existing
+ <a href="https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-tainted-array-index"><code>-Wanalyzer-tainted-array-index</code></a>
+ has been reworded to talk about "attacker-controlled" rather than
+ "tainted" values, for consistency with the new warnings.
+ </p>
+ <p>A new <a href="https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-tainted_005fargs-function-attribute"><code>__attribute__ ((tainted_args))</code></a> has been
+ added to the C and C++ frontends, usable on functions, and on
+ function pointer callback fields in structs. The analyzer's taint
+ mode will treat all parameters and buffers pointed to by parameters
+ of such functions as being attacked-controlled, such as for
+ annotating system calls in an operating system kernel as being an
+ "attack surface".
+ </p>
+ </li>
+ <li>The analyzer now respects
+ <a href="https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-const-function-attribute"><code>__attribute__((const))</code></a>:
+ it will treat such functions as returning the same value when given
+ the same inputs (<a href="https://gcc.gnu.org/PR104434">PR104434</a>),
+ and as having no side effects (<a href="https://gcc.gnu.org/PR104576">PR104576</a>).
+ </li>
+ <li>The analyzer is now able to split its analysis into multiple
+ execution paths in places where there isn't a split in the control
+ flow graph. For example, it now handles <code>realloc</code> calls by
+ splitting the execution path into three possible outcomes for the
+ call:
+ <ul>
+ <li>failure, returning <code>NULL</code></li>
+ <li>success, growing the buffer in-place without moving it</li>
+ <li>success, allocating a new buffer, copying the content of the old
+ buffer to it, and freeing the old buffer</li>
+ </ul>
+ </li>
+ <li>The analyzer's interprocedural path exploration logic is now able to
+ track calls through function pointers.
+ </li>
+ <li>The analyzer now makes the assumption that if we know PTR is non-NULL,
+ then (PTR + OFFSET) is also non-NULL. This isn't strictly true, but
+ eliminates false positives in practice
+ (<a href="https://gcc.gnu.org/PR101962">PR101962</a>).
+ </li>
+ <li>The analyzer has gained some initial support for inline assembler
+ code. This is extremely limited, and is purely to help suppress
+ false positives when analyzing the Linux kernel, which makes heavy
+ use of inline assembler (<a href="https://gcc.gnu.org/PR101570">PR101570</a>).
+ </li>
+ <li>The way the analyzer tracks the state of memory along an execution
+ path has been improved in various ways for GCC 12:
+ <ul>
+ <li>An optimization for representing bulk updates to memory (e.g.
+ zero fills) has been removed as it never worked well. In GCC 12
+ it has been replaced with a simpler and more accurate approach,
+ eliminating many false positives
+ (<a href="https://gcc.gnu.org/PR95006">PR95006</a>).
+ </li>
+ <li>Various optimizations have been added, speeding up the analysis
+ on a particularly problematic source file from 4 minutes down to
+ 17 seconds
+ (<a href="https://gcc.gnu.org/PR104943">PR104943</a>,
+ <a href="https://gcc.gnu.org/PR104954">PR104954</a>, and
+ <a href="https://gcc.gnu.org/PR104955">PR104955</a>).
+ </li>
+ <li>The analyzer now tracks the sizes of dynamically-allocated regions,
+ both on the heap (via <code>malloc</code> etc) and stack
+ (via <code>alloca</code>), though none of the analyzer warnings make
+ use of this yet in GCC 12.</li>
+ </ul>
+ </li>
+ <li>The analyzer's handling of switch statements has been rewritten,
+ fixing various bugs.
+ </li>
+</ul>
<!-- .................................................................. -->
<!-- <h2 id="plugins">Improvements for plugin authors</h2> -->
--
2.30.2
^ permalink raw reply [flat|nested] 2+ messages in thread
* [wwwdocs] Re: [committed] gcc-12: analyzer changes
2022-04-12 14:03 [committed] gcc-12: analyzer changes David Malcolm
@ 2022-04-12 14:04 ` David Malcolm
0 siblings, 0 replies; 2+ messages in thread
From: David Malcolm @ 2022-04-12 14:04 UTC (permalink / raw)
To: gcc-patches
On Tue, 2022-04-12 at 10:03 -0400, David Malcolm wrote:
> I've pushed the following change to the website, covering -fanalyzer
> changes in GCC 12.
(sorry, forgot to put wwwdocs in the subject)
>
> ---
> htdocs/gcc-12/changes.html | 115
> +++++++++++++++++++++++++++++++++++++
> 1 file changed, 115 insertions(+)
>
> diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
> index 4652304d..d907ed22 100644
> --- a/htdocs/gcc-12/changes.html
> +++ b/htdocs/gcc-12/changes.html
> @@ -749,6 +749,121 @@ function Multiply (S1, S2 : Sign) return Sign
> is
> <!--
> .................................................................. --
> >
> <!-- <h2>Documentation improvements</h2> -->
>
> +<h2 id="analyzer">Improvements to Static Analyzer</h2>
> +<ul>
> + <li>The analyzer has gained a <a href="
> https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-use-of-uninitialized-value
> "><code>-Wanalyzer-use-of-uninitialized-value</code></a>
> + warning, similar to
> + <a href="
> https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wuninitialized
> "><code>-Wuninitialized</code></a>
> + and
> + <a href="
> https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wmaybe-uninitialized
> "><code>-Wmaybe-uninitialized</code></a>,
> + but based on an interprocedural path-sensitive analysis
> + (<a href="https://gcc.gnu.org/PR95006">PR95006</a>).
> + <p>Such warnings are not disabled by the new
> + <a href="
> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
> "><code>-ftrivial-auto-var-init</code></a>
> + (see below), as the latter is considered a mitigation
> option.</p>
> + </li>
> + <li><a href="
> https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-write-to-const
> "><code>-Wanalyzer-write-to-const</code></a>
> + and
> + <a href="
> https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-write-to-string-literal
> "><code>-Wanalyzer-write-to-string-literal</code></a>
> + will now check for
> + <a href="
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html"><
> code>__attribute__ ((access, ....))</code></a>
> + on calls to externally-defined functions, and complain about
> read-only
> + regions pointed to by arguments marked with a
> <code>write_only</code>
> + or <code>read_write</code> attribute
> + (<a href="https://gcc.gnu.org/PR104793">PR104793</a>).
> + </li>
> + <li>The analyzer's "taint" mode, activated by
> + <a href="
> https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-fanalyzer-checker
> "><code>-fanalyzer-checker=taint</code></a>
> + (in addition to <a href="
> https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-fanalyzer
> "><code>-fanalyzer</code></a>),
> + has gained four new taint-based warnings:
> + <ul>
> + <li><a href="
> https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-tainted-allocation-size
> "><code>-Wanalyzer-tainted-allocation-size</code></a>
> + for e.g. attacker-controlled <code>malloc</code>
> + and <code>alloca</code>,
> + </li>
> + <li><a href="
> https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-tainted-divisor
> "><code>-Wanalyzer-tainted-divisor</code></a>
> + for detecting where an attacker can inject a divide-by-zero,
> + </li>
> + <li><a href="
> https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-tainted-offset
> "><code>-Wanalyzer-tainted-offset</code></a>
> + for attacker-controlled pointer offsets,
> + </li>
> + <li><a href="
> https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-tainted-size
> "><code>-Wanalyzer-tainted-size</code></a>
> + for attacker-controlled values being used as a size
> parameter to
> + calls to <code>memset</code> or to functions marked with
> + <a href="
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html"><
> code>__attribute__ ((access, ....))</code></a>.
> + </li>
> + </ul>
> + <p>The existing
> + <a href="
> https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-tainted-array-index
> "><code>-Wanalyzer-tainted-array-index</code></a>
> + has been reworded to talk about "attacker-controlled" rather
> than
> + "tainted" values, for consistency with the new warnings.
> + </p>
> + <p>A new <a href="
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-tainted_005fargs-function-attribute
> "><code>__attribute__ ((tainted_args))</code></a> has been
> + added to the C and C++ frontends, usable on functions, and on
> + function pointer callback fields in structs. The analyzer's
> taint
> + mode will treat all parameters and buffers pointed to by
> parameters
> + of such functions as being attacked-controlled, such as for
> + annotating system calls in an operating system kernel as being
> an
> + "attack surface".
> + </p>
> + </li>
> + <li>The analyzer now respects
> + <a href="
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-const-function-attribute
> "><code>__attribute__((const))</code></a>:
> + it will treat such functions as returning the same value when
> given
> + the same inputs (<a
> href="https://gcc.gnu.org/PR104434">PR104434</a>),
> + and as having no side effects (<a href="
> https://gcc.gnu.org/PR104576">PR104576</a>).
> + </li>
> + <li>The analyzer is now able to split its analysis into multiple
> + execution paths in places where there isn't a split in the
> control
> + flow graph. For example, it now handles <code>realloc</code>
> calls by
> + splitting the execution path into three possible outcomes for
> the
> + call:
> + <ul>
> + <li>failure, returning <code>NULL</code></li>
> + <li>success, growing the buffer in-place without moving
> it</li>
> + <li>success, allocating a new buffer, copying the content of
> the old
> + buffer to it, and freeing the old buffer</li>
> + </ul>
> + </li>
> + <li>The analyzer's interprocedural path exploration logic is now
> able to
> + track calls through function pointers.
> + </li>
> + <li>The analyzer now makes the assumption that if we know PTR is
> non-NULL,
> + then (PTR + OFFSET) is also non-NULL. This isn't strictly true,
> but
> + eliminates false positives in practice
> + (<a href="https://gcc.gnu.org/PR101962">PR101962</a>).
> + </li>
> + <li>The analyzer has gained some initial support for inline
> assembler
> + code. This is extremely limited, and is purely to help suppress
> + false positives when analyzing the Linux kernel, which makes
> heavy
> + use of inline assembler (<a
> href="https://gcc.gnu.org/PR101570">PR101570</a>).
> + </li>
> + <li>The way the analyzer tracks the state of memory along an
> execution
> + path has been improved in various ways for GCC 12:
> + <ul>
> + <li>An optimization for representing bulk updates to memory
> (e.g.
> + zero fills) has been removed as it never worked well. In GCC
> 12
> + it has been replaced with a simpler and more accurate
> approach,
> + eliminating many false positives
> + (<a href="https://gcc.gnu.org/PR95006">PR95006</a>).
> + </li>
> + <li>Various optimizations have been added, speeding up the
> analysis
> + on a particularly problematic source file from 4 minutes down
> to
> + 17 seconds
> + (<a href="https://gcc.gnu.org/PR104943">PR104943</a>,
> + <a href="https://gcc.gnu.org/PR104954">PR104954</a>, and
> + <a href="https://gcc.gnu.org/PR104955">PR104955</a>).
> + </li>
> + <li>The analyzer now tracks the sizes of dynamically-allocated
> regions,
> + both on the heap (via <code>malloc</code> etc) and stack
> + (via <code>alloca</code>), though none of the analyzer
> warnings make
> + use of this yet in GCC 12.</li>
> + </ul>
> + </li>
> + <li>The analyzer's handling of switch statements has been
> rewritten,
> + fixing various bugs.
> + </li>
> +</ul>
>
> <!--
> .................................................................. --
> >
> <!-- <h2 id="plugins">Improvements for plugin authors</h2> -->
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-04-12 14:04 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-12 14:03 [committed] gcc-12: analyzer changes David Malcolm
2022-04-12 14:04 ` [wwwdocs] " David Malcolm
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).