On 2022-09-23 09:02, Jakub Jelinek wrote:
Oh, so can addr_object_size be simplified to use get_base_address too?
You can try. As you can see in get_base_address, that function
handles something that the above doesn't (looking through some MEM_REFs too).
I went down this rabbithole and it
On 2023-01-31 07:46, Jakub Jelinek wrote:
On Wed, Dec 21, 2022 at 05:25:54PM -0500, Siddhesh Poyarekar wrote:
The tree object size pass tries to fail when it detects a flex array in
the struct, but it ends up doing the right thing only when the flex
array is in the outermost struct. For nested
On 2023-02-01 13:24, Qing Zhao wrote:
On Feb 1, 2023, at 11:55 AM, Siddhesh Poyarekar wrote:
On 2023-01-31 09:11, Qing Zhao wrote:
Update documentation to clarify a GCC extension on structure with
flexible array member being nested in another structure.
gcc/ChangeLog:
* doc
-4.c: Likewise.
* gcc.dg/builtin-object-size-6.c: Likewise.
* gcc.dg/builtin-object-size-7.c: Likewise.
* gcc.dg/builtin-object-size-8.c: Likewise.
* gcc.dg/pr101836.c: Likewise.
* gcc.dg/strict-flex-array-3.c: Likewise.
Signed-off-by: Siddhesh Poyarekar
On 2023-01-31 09:11, Qing Zhao wrote:
Update documentation to clarify a GCC extension on structure with
flexible array member being nested in another structure.
gcc/ChangeLog:
* doc/extend.texi: Document GCC extension on a structure containing
a flexible array member to be a
On 2023-01-31 09:11, Qing Zhao wrote:
GCC extension accepts the case when a struct with a flexible array member
is embedded into another struct (possibly recursively).
__builtin_object_size should treat such struct as flexible size per
-fstrict-flex-arrays.
PR tree-optimization/101832
-Wall enables -Wuse-after-free=2 and not -Wuse-after-free=3.
gcc/ChangeLog:
* gcc/doc/invoke.texi (@item -Wall): Fix typo in
-Wuse-after-free.
Signed-off-by: Siddhesh Poyarekar
---
gcc/doc/invoke.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc
On 2023-02-17 14:43, Jeff Law wrote:
On 2/17/23 06:41, Siddhesh Poyarekar wrote:
-Wall enables -Wuse-after-free=2 and not -Wuse-after-free=3.
gcc/ChangeLog:
* gcc/doc/invoke.texi (@item -Wall): Fix typo in
-Wuse-after-free.
Looks obvious to me. If you haven't committed it already
On 2023-04-20 08:59, Jakub Jelinek via Gcc-patches wrote:
+r.set (type, dconstm1, dconst1);
See above, are we sure we can use [-1., 1.] range safely, or should that be
[-1.-Nulps, 1.+Nulps] for some kind of expected worse error margin of the
implementation? And ditto for -frounding-math,
On 2023-04-20 10:02, Jakub Jelinek wrote:
On x86_64-linux with glibc 2.35, I see
for i in FLOAT DOUBLE LDOUBLE FLOAT128; do for j in TONEAREST UPWARD DOWNWARD
TOWARDZERO; do gcc -D$i -DROUND=FE_$j -g -O1 -o /tmp/sincos{,.c} -lm;
/tmp/sincos || echo $i $j; done; done
Aborted (core dumped)
FLOAT
On 2023-04-20 11:52, Jakub Jelinek wrote:
Why? Unless an implementation guarantees <= 0.5ulps errors, it can be one
or more ulps off, why is an error at or near 1.0 or -1.0 error any worse
than similar errors for other values?
In a general sense, maybe not, but in the sense of breaching the
On 2023-04-20 13:57, Siddhesh Poyarekar wrote:
For bounds that aren't representable, one could get error bounds from
libm-test-ulps data in glibc, although I reckon those won't be
exhaustive. From a quick peek at the sin/cos data, the arc target seems
to be among the worst performers at about
On 2023-04-24 12:03, Jakub Jelinek wrote:
On Thu, Apr 20, 2023 at 01:57:55PM -0400, Siddhesh Poyarekar wrote:
Similarly for other functions which have other ranges, perhaps not with so
nice round numbers. Say asin has [-pi/2, pi/2] range, those numbers aren't
exactly representable
On 2023-04-21 02:52, Jakub Jelinek wrote:
On Thu, Apr 20, 2023 at 09:14:10PM -0400, Siddhesh Poyarekar wrote:
On 2023-04-20 13:57, Siddhesh Poyarekar wrote:
For bounds that aren't representable, one could get error bounds from
libm-test-ulps data in glibc, although I reckon those won't
On 2023-02-08 14:09, Joseph Myers wrote:
What must be avoided is -pedantic diagnostics for
struct flex1 { int n; int data[1]; };
struct out_flex_end1 { int m; struct flex1 flex_data; };
regardless of whether considered flexible or not, since that's clearly
valid in standard C.
Are you sure
On 2023-02-06 18:14, Joseph Myers wrote:
On Mon, 6 Feb 2023, Qing Zhao via Gcc-patches wrote:
In GCC14:
1. Include this new warning -Wgnu-varaible-sized-type-not-at-end to -Wall
2. Deprecate this extension from GCC. (Or delay this to next release?).
Any deprecation, or inclusion in -Wall,
On 2023-01-25 22:32, Siddhesh Poyarekar wrote:
Instead of using TREE_OPERAND (expr, 2) directly, use
component_ref_field_offset instead, which does scaling for us. The
function also substitutes PLACEHOLDER_EXPRs, which is probably what we
want anyway but I'm not sure if it's relevant
On 2023-02-02 03:33, Richard Biener wrote:
looking at PR77650 what seems missing there is the semantics of this
extension as expected/required by the glibc use. comment#5 seems
to suggest that for my example above its expected that
Y.x.data[0] aliases Y.end?! There must be a better way to
On 2023-07-31 13:03, Siddhesh Poyarekar wrote:
On 2023-07-31 12:47, Qing Zhao wrote:
Hi, Sid and Jakub,
I have a question in the following source portion of the routine
“addr_object_size” of gcc/tree-object-size.cc:
743 bytes = compute_object_offset (TREE_OPERAND (ptr, 0), var
On 2023-07-31 14:13, Qing Zhao wrote:
Okay. I see.
Then if the size info from the TYPE is smaller than the size info from the
malloc,
then based on the current code, we use the smaller one between these two,
i.e, the size info from the TYPE. (Even for the OST_MAXIMUM).
Is such behavior
On 2023-07-31 12:47, Qing Zhao wrote:
Hi, Sid and Jakub,
I have a question in the following source portion of the routine
“addr_object_size” of gcc/tree-object-size.cc:
743 bytes = compute_object_offset (TREE_OPERAND (ptr, 0), var);
744 if (bytes != error_mark_node)
745
On 2023-07-21 07:21, Martin Uecker via Gcc-patches wrote:
This patch adds a warning for allocations with insufficient size
based on the "alloc_size" attribute and the type of the pointer
the result is assigned to. While it is theoretically legal to
assign to the wrong pointer type and cast it
On 2023-08-02 10:02, Qing Zhao wrote:
/*when checking the observed access p->array, we only have info on the
observed access, i.e, the TYPE_SIZE info from the access. We don't have
info on the whole object. */
expect(__builtin_dynamic_object_size(q->array, 1), q->foo *
On 2023-08-03 12:43, Qing Zhao wrote:
Surely we could emit that for __bdos(q->array, 0) though, couldn't we?
For __bdos(q->array, 0), we only have the access info for the sub-object q->array,
we can surely decide the size of the sub-object q->array, but we still cannot
decide the whole
/object-size-dyn.c (dyn): New parameter RET.
(main): Use it.
Signed-off-by: Siddhesh Poyarekar
---
gcc/testsuite/gcc.dg/ubsan/object-size-dyn.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/ubsan/object-size-dyn.c
b/gcc/testsuite/gcc.dg/ubsan
On 2023-08-10 12:39, Jakub Jelinek wrote:
On Thu, Aug 10, 2023 at 12:30:06PM -0400, Siddhesh Poyarekar wrote:
The definition of __bos/__bdos allows us the freedom to *estimate* rather
than be precise, so I'd go for sizeof(x) + N * sizeof(*x.a) since it's bound
to give the more conservative
On 2023-08-10 10:47, Martin Uecker wrote:
Am Donnerstag, dem 10.08.2023 um 16:42 +0200 schrieb Jakub Jelinek:
On Thu, Aug 10, 2023 at 04:38:21PM +0200, Martin Uecker wrote:
Am Donnerstag, dem 10.08.2023 um 13:59 + schrieb Qing Zhao:
On Aug 10, 2023, at 2:58 AM, Martin Uecker wrote:
Am
On 2023-08-10 11:18, Martin Uecker wrote:
Am Donnerstag, dem 10.08.2023 um 10:58 -0400 schrieb Siddhesh Poyarekar:
On 2023-08-10 10:47, Martin Uecker wrote:
Am Donnerstag, dem 10.08.2023 um 16:42 +0200 schrieb Jakub Jelinek:
On Thu, Aug 10, 2023 at 04:38:21PM +0200, Martin Uecker wrote:
Am
On 2023-08-10 14:28, Richard Sandiford wrote:
Siddhesh Poyarekar writes:
On 2023-08-08 10:30, Siddhesh Poyarekar wrote:
Do you have a suggestion for the language to address libgcc,
libstdc++, etc. and libiberty, libbacktrace, etc.?
I'll work on this a bit and share a draft.
Hi David
On 2023-08-11 11:12, David Edelsohn wrote:
The text above states "bugs in these libraries may be evaluated for
security impact", but there is no comment about the criteria for a
security impact, unlike the GLIBC SECURITY.md document. The text seems
to imply the "What is a security bug?"
On 2023-08-10 14:50, Siddhesh Poyarekar wrote:
As a result, the only case for a potential security issue in all
these cases is when it ends up generating vulnerable output for
valid input source code.
I think this leaves open the interpretation "every wrong cod
On 2023-08-11 11:09, Paul Koning wrote:
On Aug 11, 2023, at 10:36 AM, Siddhesh Poyarekar wrote:
On 2023-08-10 14:50, Siddhesh Poyarekar wrote:
As a result, the only case for a potential security issue in all
these cases is when it ends up generating vulnerable output
On 2023-08-03 13:34, Qing Zhao wrote:
One thing I need to point out first is, currently, even for regular fixed size
array in the structure,
We have this same issue, for example:
#define LENGTH 10
struct fix {
size_t foo;
int array[LENGTH];
};
…
int main ()
{
struct fix *p;
p =
On 2023-08-04 10:40, Siddhesh Poyarekar wrote:
On 2023-08-03 13:34, Qing Zhao wrote:
One thing I need to point out first is, currently, even for regular
fixed size array in the structure,
We have this same issue, for example:
#define LENGTH 10
struct fix {
size_t foo;
int array[LENGTH
On 2023-08-04 11:27, Qing Zhao wrote:
On Aug 4, 2023, at 10:40 AM, Siddhesh Poyarekar wrote:
On 2023-08-03 13:34, Qing Zhao wrote:
One thing I need to point out first is, currently, even for regular fixed size
array in the structure,
We have this same issue, for example:
#define LENGTH 10
On 2023-08-04 15:06, Qing Zhao wrote:
Yes, that's what I'm thinking.
so `q` must be pointing to a single element. So you could deduce:
1. the minimum size of the whole object that q points to.
You mean that the TYPE will determine the minimum size of the whole object?
(Does this include
On 2023-08-08 10:14, David Edelsohn wrote:
On Tue, Aug 8, 2023 at 10:07 AM Siddhesh Poyarekar <mailto:siddh...@gotplt.org>> wrote:
On 2023-08-08 10:04, Richard Biener wrote:
> On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor mailto:i...@google.com>> wrote:
>&g
On 2023-08-08 04:16, Richard Biener wrote:
On Mon, Aug 7, 2023 at 7:30 PM David Edelsohn via Gcc-patches
wrote:
FOSS Best Practices recommends that projects have an official Security
policy stated in a SECURITY.md or SECURITY.txt file at the root of the
repository. GLIBC and Binutils have
On 2023-08-08 10:04, Richard Biener wrote:
On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor wrote:
On Tue, Aug 8, 2023 at 6:02 AM Jakub Jelinek via Gcc-patches
wrote:
On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-patches wrote:
There's probably external tools to do this,
On 2023-08-08 10:37, Jakub Jelinek wrote:
On Tue, Aug 08, 2023 at 10:30:10AM -0400, Siddhesh Poyarekar wrote:
Do you have a suggestion for the language to address libgcc, libstdc++,
etc. and libiberty, libbacktrace, etc.?
I'll work on this a bit and share a draft.
BTW, I think we should
On 2023-08-08 11:48, David Malcolm wrote:
On Tue, 2023-08-08 at 09:33 -0400, Paul Koning via Gcc-patches wrote:
On Aug 8, 2023, at 9:01 AM, Jakub Jelinek via Gcc-patches
wrote:
On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-
patches wrote:
There's probably external tools
On 2023-08-09 14:17, David Edelsohn wrote:
On Wed, Aug 9, 2023 at 1:33 PM Siddhesh Poyarekar <mailto:siddh...@gotplt.org>> wrote:
On 2023-08-08 10:30, Siddhesh Poyarekar wrote:
>> Do you have a suggestion for the language to address libgcc,
>> libstdc+
On 2023-08-08 10:30, Siddhesh Poyarekar wrote:
Do you have a suggestion for the language to address libgcc,
libstdc++, etc. and libiberty, libbacktrace, etc.?
I'll work on this a bit and share a draft.
Hi David,
Here's what I came up with for different parts of GCC, including the
runtime
On 2023-08-01 18:57, Kees Cook wrote:
return p;
}
/* in the following function, malloc allocated less space than size of the
struct fix. Then what's the correct behavior we expect
the __builtin_object_size should have for the following?
*/
static struct fix * noinline
On 2023-08-01 17:35, Qing Zhao wrote:
typedef struct
{
int a;
} A;
size_t f()
{
A *p = malloc (1);
return __builtin_object_size (p, 0);
Correction, that should be __builtin_object_size (p->a, 0).
Actually, it should be __builtin_object_size(p->a, 1).
For
Hi,
Here's the updated draft of the top part of the security policy with all
of the recommendations incorporated.
Thanks,
Sid
What is a GCC security bug?
===
A security bug is one that threatens the security of a system or
network, or might compromise the
On 2023-08-14 17:16, Alexander Monakov wrote:
On Mon, 14 Aug 2023, Siddhesh Poyarekar wrote:
1. It makes it clear to users of the project the scope in which the project
could be used and what safety it could reasonably expect from the project. In
the context of GCC for example, it cannot
On 2023-08-14 14:51, Richard Sandiford wrote:
I think it would help to clarify what the aim of the security policy is.
Specifically:
(1) What service do we want to provide to users by classifying one thing
as a security bug and another thing as not a security bug?
(2) What service do we
On 2024-02-12 10:00, Richard Biener wrote:
GCC driver support is then to the extent identifying the inputs and the outputs.
We already have -MM to generate a list of non-system dependencies, so
gcc should be able to pass on inputs to the tool, which could then map
those files (and the system
On 2024-02-09 10:38, Martin Jambor wrote:
If anyone is interested in scoping this and then mentoring this as a
Google Summer of Code project this year then now is the right time to
speak up!
I can help with mentoring and reviews, although I'll need someone to
assist with actual approvals.
On 2024-02-09 12:14, Joseph Myers wrote:
On Fri, 9 Feb 2024, Siddhesh Poyarekar wrote:
For privilege management we could add a --allow-root driver flag that allows
gcc to run as root. Without the flag one could either outright refuse to run
or drop privileges and run. Dropping privileges
On 2024-02-09 15:06, Joseph Myers wrote:
Ideally dependencies would be properly set up so that everything is built
in the original build, and ideally there would be no need to relink at
install time (I'm not sure of the exact circumstances in which it might be
needed, or on what OSes to e.g.
On 2024-02-12 08:16, Martin Jambor wrote:
This probably ties in somewhat with an idea David Malcolm had riffed on
with me earlier, of caching files for diagnostics. If we could unify
file accesses somehow, we could make this happen, i.e. open/read files
as root and then do all execution as
On 2023-12-06 09:21, Jakub Jelinek wrote:
On Wed, Dec 06, 2023 at 02:34:10PM +0100, Martin Uecker wrote:
Further I think
"size less than or equal to the size requested"
is quite ambiguous in the calloc case, isn't the size requested in the
calloc case actually nmemb * size rather than just
On 2023-12-06 09:41, Jakub Jelinek wrote:
On Wed, Dec 06, 2023 at 09:30:32AM -0500, Siddhesh Poyarekar wrote:
We have the -Wmemset-transposed-args warning, couldn't we
have a similar one for calloc, and perhaps do it solely in
the case where one uses sizeof of the type used in the cast
pointer
The "exploitable vulnerability" may lead to a misunderstanding that
missed hardening issues are considered vulnerabilities, just that
they're not exploitable. This is not true, since while hardening bugs
may be security-relevant, the absence of hardening does not make a
program any more
/113012
* tree-object-size.cc (compute_builtin_object_size): Expand
comment for dynamic object sizes.
(collect_object_sizes_for): Always set COMPUTED bitmap for
dynamic object sizes.
Signed-off-by: Siddhesh Poyarekar
---
Testing:
- Bootstrapped x86_64 and config=ubsan
UNKNOWNS.
Drop all references to it.
(object_sizes_set): Move unknowns propagation code to...
(gimplify_size_expressions): ... here. Also free reexamine
bitmap.
(propagate_unknowns): New parameter UNKNOWNS. Update callers.
Signed-off-by: Siddhesh Poyarekar
On 2023-12-19 17:57, Jakub Jelinek wrote:
On Mon, Dec 18, 2023 at 11:42:52AM -0500, Siddhesh Poyarekar wrote:
It is always safe to set the computed bit for dynamic object sizes at
the end of collect_object_sizes_for because even in case of a dependency
loop encountered in nested calls, we have
On 2023-12-20 00:23, Jeff Law wrote:
On 12/19/23 10:21, Siddhesh Poyarekar wrote:
Narrow down scope of the unknowns bitmap so that it is only accessible
within the reexamination process. This also removes any role of unknown
propagation from object_sizes_set, thus simplifying that code path
On 2023-12-18 09:35, Siddhesh Poyarekar wrote:
The "exploitable vulnerability" may lead to a misunderstanding that
missed hardening issues are considered vulnerabilities, just that
they're not exploitable. This is not true, since while hardening bugs
may be security-relevant, t
On 2023-12-04 16:31, Martin Uecker wrote:
If (assuming from them being called lambdas) they are primarily for
small functions without side-effects then it's already a significantly
stronger specification than what we have right now with C nested
functions. That would end up enforcing what you
On 2023-12-02 04:42, Martin Uecker wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
It came up that a good hardening strategy is to disable trampolines
which may require executable stack. Therefore the following patch
adds -Werror=trampolines to -fhardened.
This
On 2023-12-04 11:39, Andreas Schwab wrote:
On Dez 04 2023, Siddhesh Poyarekar wrote:
For hardened code in C, I think we really should look to step away from
nested functions instead of adding ways to continue supporting it. There's
probably a larger conversation to be had about the utility
[Branching this into a separate conversation to avoid derailing the
patch, which isn't directly related]
On 2023-12-04 12:21, Martin Uecker wrote:
I do not really agree with that. Nested functions can substantially
improve code quality and in C can avoid type unsafe use of
void* pointers in
On 2023-12-04 13:48, Martin Uecker wrote:
I empathize with Jakub's stated use case though of keeping the C
frontend support for testing purposes, but that could easily be done
behind a flag, or by putting nested C func deprecation behind a flag.
I am relatively sure C will get some form of
On 2023-12-04 13:51, Jakub Jelinek wrote:
Why? The syntax doesn't seem to be something unexpected, and as C doesn't
have lambdas, one can use the nested functions instead.
The only problem is if you need to pass function pointers somewhere else
(and target doesn't have function descriptors or
On 2023-12-07 10:42, Eric Botcazou wrote:
I think from a language standpoint, the general idea that nested
functions are just any functions inside functions (which is how the C
nested functions essentially behave) is too broad and they should be
restricted to minimal implementations that, e.g.
On 2024-03-29 12:07, Qing Zhao wrote:
to carry the TYPE of the flexible array.
Such information is needed during tree-object-size.cc.
We cannot use the result type or the type of the 1st argument
of the routine .ACCESS_WITH_SIZE to decide the element type
of the original array due to possible
On 2024-03-29 12:07, Qing Zhao wrote:
gcc/c-family/ChangeLog:
* c-ubsan.cc (get_bound_from_access_with_size): New function.
(ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE.
gcc/testsuite/ChangeLog:
* gcc.dg/ubsan/flex-array-counted-by-bounds-2.c: New test.
On 2024-03-29 12:07, Qing Zhao wrote:
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-common.h: Add a new macro EXPECT.
*
On 2024-04-25 10:06, Qing Zhao wrote:
gcc/testsuite/ChangeLog:
* c-c++-common/fam-in-union-alone-in-struct-1.c: New testcase.
* c-c++-common/fam-in-union-alone-in-struct-2.c: New testcase.
* c-c++-common/fam-in-union-alone-in-struct-3.c: New testcase.
---
Sorry I
On 2024-03-18 12:28, Qing Zhao wrote:
This should probably bail out if object_size_type & OST_DYNAMIC == 0.
Okay. Will add this.
When add this into access_with_size_object_size, I found some old bugs
in early_object_sizes_execute_one, and fixed them as well.
Would you be able to isolate
On 2024-02-16 14:47, Qing Zhao wrote:
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the C99 flexible
array member of a structure. It indicates that the number of the
elements of the array is given by the field named "COUNT" in the
same structure as
On 2024-02-16 14:47, Qing Zhao wrote:
Including the following changes:
* The definition of the new internal function .ACCESS_WITH_SIZE
in internal-fn.def.
* C FE converts every reference to a FAM with a "counted_by" attribute
to a call to the internal function .ACCESS_WITH_SIZE.
On 2024-02-16 14:47, Qing Zhao wrote:
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-common.h: Add a new macro EXPECT.
*
On 2024-02-16 14:47, Qing Zhao wrote:
gcc/c-family/ChangeLog:
* c-ubsan.cc (get_bound_from_access_with_size): New function.
(ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE.
gcc/testsuite/ChangeLog:
* gcc.dg/ubsan/flex-array-counted-by-bounds-2.c: New
301 - 377 of 377 matches
Mail list logo
