Am Donnerstag, dem 18.07.2024 um 18:32 + schrieb Qing Zhao:
> Hi, Martin,
>
> I briefly reviewed these 4 patches this week.
>
> Overall, I think that this is a nice new security feature to be added into
> gcc.
Thank you! (not only for security! it currently helps me with
my numerics)
>
Hi, Martin,
I briefly reviewed these 4 patches this week.
Overall, I think that this is a nice new security feature to be added into gcc.
At the same time, I have the following questions about the patches:
1. Does the name of the option mismatch the description of the option?
-fvla-bounds
> On Jul 15, 2024, at 17:41, Martin Uecker wrote:
>
> Am Montag, dem 15.07.2024 um 21:26 + schrieb Qing Zhao:
>> Hi, Martin,
>> I didn’t see your v3 patches attached to the email, did you miss them?
>> (I really want to see them -:).
>
> Sorry, I should have CCed you. It was sent as a
Am Montag, dem 15.07.2024 um 21:26 + schrieb Qing Zhao:
> Hi, Martin,
> I didn’t see your v3 patches attached to the email, did you miss them?
> (I really want to see them -:).
Sorry, I should have CCed you. It was sent as a series of patches:
Hi, Martin,
I didn’t see your v3 patches attached to the email, did you miss them? (I
really want to see them -:).
> On Jul 15, 2024, at 16:58, Martin Uecker wrote:
>
> Am Montag, dem 15.07.2024 um 13:05 -0700 schrieb Kees Cook:
>> On Mon, Jul 15, 2024 at 07:20:31PM +0200, Martin Uecker
Am Montag, dem 15.07.2024 um 13:05 -0700 schrieb Kees Cook:
> On Mon, Jul 15, 2024 at 07:20:31PM +0200, Martin Uecker wrote:
> > No, there are still two many missing pieces. The following
> > works already
> >
> > int h(int n, int buf[n])
> > {
> > return __builtin_dynamic_object_size(buf,
On Mon, Jul 15, 2024 at 07:20:31PM +0200, Martin Uecker wrote:
> No, there are still two many missing pieces. The following
> works already
>
> int h(int n, int buf[n])
> {
> return __builtin_dynamic_object_size(buf, 1);
> }
Yeah, this is nice.
There are some interesting things happening
Am Montag, dem 15.07.2024 um 09:45 -0700 schrieb Kees Cook:
> On Mon, Jul 15, 2024 at 09:19:49AM +0200, Martin Uecker wrote:
> > The instrumentation is guarded by a new instrumentation flag -fvla-bounds,
> > but runtime overhead should generally be very low as most checks are
> > removed by the
On Mon, Jul 15, 2024 at 09:19:49AM +0200, Martin Uecker wrote:
> The instrumentation is guarded by a new instrumentation flag -fvla-bounds,
> but runtime overhead should generally be very low as most checks are
> removed by the optimizer, e.g.
>
> void foo(int x, char (*buf)[x])
> {
> bar(x,
correct email.
Am Montag, dem 15.07.2024 um 09:19 +0200 schrieb Martin Uecker:
> This is the third revision for my patch series to check bounds
> consistency at run-time when assigning VM types. Relative
> to the last version, mostly the tests were simplified and some
> coding style issues
Support instrumentation of function arguments for functions
called via a declaration. We can support only simple size
expressions without side effects, because the run-time
instrumentation is done before the call, but the expressions
are evaluated in the callee.
gcc/c:
* c-typeck.cc
Support instrumentation of functions called via pointers. To do so,
record the declaration with the parameter types, so that it can be
retrieved later.
gcc/c:
c-decl.cc (get_parm_info): Record function declaration
for arguments.
c-typeck.cc (process_vm_constraints): Instrument functions
Add warning for the case when a function call can not be instrumented
and add documentation for instrumentation of function calls.
gcc/c-family/:
* c.opt (Wvla-parameter-missing-check): Add warning.
gcc/c/:
* c-typeck.cc (process_vm_constraints): Add warning.
gcc/doc/:
* invoke.texi
When checking compatibility of types during assignment, collect
all pairs of types where the outermost bound needs to match at
run-time. This list is then processed to add runtime checks for
each bound.
gcc/c-family:
* c-opt (fvla-bounds): New flag.
gcc/c:
* c-typeck.cc (struct
This is the third revision for my patch series to check bounds
consistency at run-time when assigning VM types. Relative
to the last version, mostly the tests were simplified and some
coding style issues fixed.
It adds a new code instrumentation option that inserts
run-time checks to ensure
Add warning for the case when a function call can not be instrumened.
gcc/c-family/:
* c.opt (Wvla-parameter-missing-check): Add warning.
gcc/c/:
* c-typeck.cc (process_vm_constraints): Add warning.
gcc/doc/:
* invoke.texi (Wvla-parameter-missing-check): Document
Support instrumentation of functions called via pointers. To do so,
record the declaration with the parameter types, so that it can be
retrieved later.
gcc/c:
c-decl.cc (get_parm_info): Record function declaration
for arguments.
c-typeck.cc (process_vm_constraints):
Support instrumentation of function arguments for functions
called via a declaration. We can support only simple size
expressions without side effects, because the run-time
instrumentation is done before the call, but the expressions
are evaluated in the callee.
gcc/c:
* c-typeck.cc
When checking compatibility of types during assignment, collect
all pairs of types where the outermost bound needs to match at
run-time. This list is then processed to add runtime checks for
each bound.
gcc/c-family:
* c-opt (fvla-bounds): New flag.
gcc/c:
* c-typeck.cc
This is another revised series for checking for
bounds consistency when assigning VM types.
Based on feedback, I disentangled this from UBSan for
a three reasons:
- I think it makes sense as a stand-alone feature
similar to other run-time instrumentation features
GCC already has.
- Not all
20 matches
Mail list logo
