Re: Question on -fwrapv and -fwrapv-pointer

On Fri, Sep 15, 2023 at 05:47:08PM +, Qing Zhao wrote: > > > > On Sep 15, 2023, at 1:26 PM, Richard Biener > > wrote: > > > > > > > >> Am 15.09.2023 um 17:37 schrieb Qing Zhao : > >> > >>  > >> > On Sep 15, 2023, at 11:29 AM, Richard Biener > wrote: > > >

Re: Question on -fwrapv and -fwrapv-pointer

On Fri, Sep 15, 2023 at 08:18:28AM -0700, Andrew Pinski wrote: > On Fri, Sep 15, 2023 at 8:12 AM Qing Zhao wrote: > > > > > > > > > On Sep 15, 2023, at 3:43 AM, Xi Ruoyao wrote: > > > > > > On Thu, 2023-09-14 at 21:41 +, Qing Zhao wrote: > > CLANG already provided

Re: Question on -fwrapv and -fwrapv-pointer

On Thu, Sep 14, 2023 at 01:57:41PM -0700, Andrew Pinski wrote: > Now -fsanitize=pointer-overflow is already there for GCC which was > added in r8-2238-gc9b39a4955f56fe609ef5478 . LLVM/clang also provides > it in the same timeframe too . > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80998 Ah,

Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Fri, Aug 25, 2023 at 03:24:22PM +, Qing Zhao wrote: > This is the 3rd version of the patch, per our discussion based on the > review comments for the 1st and 2nd version, the major changes in this This tests out great for me; thanks you! I'm able to build the entire kernel tree with 201

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Thu, Aug 17, 2023 at 01:44:42PM +, Qing Zhao wrote: > Thanks for the testing case. > Yes, I noticed this issue too, and already fixed it in my private branch. > > With the latest patch, the compilation has no issue: > [opc@qinzhao-ol8u3-x86 108896]$ sh t >

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Wed, Aug 16, 2023 at 10:31:30PM -0700, Kees Cook wrote: > On Fri, Aug 04, 2023 at 07:44:28PM +, Qing Zhao wrote: > > This is the 2nd version of the patch, per our discussion based on the > > review comments for the 1st version, the major changes in this version > > I've been using

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Fri, Aug 04, 2023 at 07:44:28PM +, Qing Zhao wrote: > This is the 2nd version of the patch, per our discussion based on the > review comments for the 1st version, the major changes in this version I've been using Coccinelle to find and annotate[1] structures (193 so far...), and I've

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Mon, Aug 07, 2023 at 04:33:13PM +, Qing Zhao wrote: > What’s the testing case for the one that failed? > If it’s > > __builtin_dynamic_object_size(p->array, 0/2) without the allocation > information in the routine, > then with the current algorithm, gcc cannot deduce the size for the

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Tue, Aug 08, 2023 at 04:54:46PM +0200, Martin Uecker wrote: > > > I am sure this has been discussed before, but seeing that you > test for a specific formula, let me point out the following: > > There at least three different size expression which could > make sense. Consider > > short foo

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

On Fri, Aug 04, 2023 at 07:44:28PM +, Qing Zhao wrote: > This is the 2nd version of the patch, per our discussion based on the > review comments for the 1st version, the major changes in this version > are: Thanks for the update! > > 1. change the name "element_count" to "counted_by"; > 2.

Re: One question on the source code of tree-object-size.cc

On Thu, Aug 03, 2023 at 09:31:24PM +, Qing Zhao wrote: > So, the basic question is: > > Given the following: > > struct fix { > int others; > int array[10]; > } > > extern struct fix * alloc_buf (); > > int main () > { > struct fix *p = alloc_buf (); >

Re: One question on the source code of tree-object-size.cc

On Thu, Aug 03, 2023 at 07:55:54PM +, Qing Zhao wrote: > > > > On Aug 3, 2023, at 1:51 PM, Kees Cook wrote: > > > > On August 3, 2023 10:34:24 AM PDT, Qing Zhao wrote: > >> One thing I need to point out first is, currently, even for regular fixed > >> size array in the structure, > >> We

Re: One question on the source code of tree-object-size.cc

On August 3, 2023 10:34:24 AM PDT, 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 () >{ >

Re: One question on the source code of tree-object-size.cc

On Tue, Aug 01, 2023 at 09:35:30PM +, Qing Zhao wrote: > > > > On Jul 31, 2023, at 1:07 PM, Siddhesh Poyarekar wrote: > > > > 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

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

On Mon, Jul 31, 2023 at 08:14:42PM +, Qing Zhao wrote: > /* In general, Due to type casting, the type for the pointee of a pointer >does not say anything about the object it points to, >So, __builtin_object_size can not directly use the type of the pointee >to decide the size of

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

On Mon, Jul 17, 2023 at 09:17:48PM +, Qing Zhao wrote: > > > On Jul 13, 2023, at 4:31 PM, Kees Cook wrote: > > > > In the bug, the problem is that "p" isn't known to be allocated, if I'm > > reading that correctly? > > I think that the major point in PR109557 >

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

On Thu, Jul 06, 2023 at 06:56:21PM +, Qing Zhao wrote: > Hi, Kees, > > I have updated my V1 patch with the following changes: > A. changed the name to "counted_by" > B. changed the argument from a string to an identifier > C. updated the documentation and testing cases accordingly. Sounds

Re: [RFC/RFT,V2 0/3] Add compiler support for Kernel Control Flow Integrity

On Sat, Mar 25, 2023 at 01:11:14AM -0700, Dan Li wrote: > This series of patches is mainly used to support the control flow > integrity protection of the linux kernel [1], which is similar to > -fsanitize=kcfi in clang 16.0 [2,3]. > > Any suggestion please let me know :). Hi Dan, It's been a

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

On Thu, May 25, 2023 at 04:14:47PM +, Qing Zhao wrote: > GCC will pass the number of elements info from the attached attribute to both > __builtin_dynamic_object_size and bounds sanitizer to check the out-of-bounds > or dynamic object size issues during runtime for flexible array members. >

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

On Thu, May 25, 2023 at 04:14:47PM +, Qing Zhao wrote: > This patch set introduces a new attribute "element_count" to annotate bounds > for C99 flexible array member. Thank you for this work! I'm really excited to start using it in the Linux kernel. I'll give this a spin, but I know you've

Re: [V6][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

On Tue, Mar 28, 2023 at 03:49:43PM +, Qing Zhao wrote: > the C front-end has been approved by Joseph. > > Jacub, could you please eview the middle end part of the changes of this > patch? > > The major change is in tree-object-size.cc (addr_object_size). > (To use the new

Re: [V4][PATCH 0/2] Handle component_ref to a structure/union field including FAM for builtin_object_size

On Fri, Feb 24, 2023 at 06:35:03PM +, Qing Zhao wrote: > Hi, Joseph and Richard, > > Could you please review this patch and let me know whether it’s ready > for committing into GCC13? > > The fix to Bug PR101832 is an important patch for kernel security > purpose. it's better to be put into

Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

On Thu, Feb 09, 2023 at 02:40:57PM +, Qing Zhao wrote: > So, the major question here is: > > in addition to the C99 standard flexible array member [ ], shall we include > [0], [1] or even [4] into this extension, and treat the structure with a > trailing [0], [1], or [4] embedded into

Re: [PATCH 2/2] Documentation Update.

On Thu, Feb 02, 2023 at 02:31:53PM +, Qing Zhao wrote: > > > On Feb 2, 2023, at 3:33 AM, Richard Biener wrote: > > > > On Wed, 1 Feb 2023, Siddhesh Poyarekar wrote: > > > >> On 2023-02-01 13:24, Qing Zhao wrote: > >>> > >>> > On Feb 1, 2023, at 11:55 AM, Siddhesh Poyarekar >

Re: [V2][PATCH 1/1] Add a new warning option -Wstrict-flex-arrays.

On Thu, Dec 01, 2022 at 10:27:41PM +, Qing Zhao wrote: > Hi, Sid, > > Thanks a lot for the input. > > After more thinking based on your and Kees’ comments, I have the following > thought: > > 1. -fstrict-flex-arrays=level should control both GCC code gen and warnings > consistently; > 2.

Re: [V2][PATCH 1/1] Add a new warning option -Wstrict-flex-arrays.

On Thu, Dec 01, 2022 at 05:04:02PM +, Qing Zhao wrote: > > > > On Dec 1, 2022, at 11:42 AM, Kees Cook wrote: > > > > On Wed, Nov 30, 2022 at 02:25:56PM +, Qing Zhao wrote: > >> '-Wstrict-flex-arrays' > >> Warn about inproper usages of flexible array members according to > >>

Re: [V2][PATCH 1/1] Add a new warning option -Wstrict-flex-arrays.

On Wed, Nov 30, 2022 at 02:25:56PM +, Qing Zhao wrote: > '-Wstrict-flex-arrays' > Warn about inproper usages of flexible array members according to > the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to > the trailing array field of a structure if it's available, >

Re: [PATCH 2/2] Add a new warning option -Wstrict-flex-arrays.

On Tue, Nov 22, 2022 at 03:02:04PM +, Qing Zhao wrote: > > > > On Nov 22, 2022, at 9:10 AM, Qing Zhao via Gcc-patches > > wrote: > > > > > > > >> On Nov 22, 2022, at 3:16 AM, Richard Biener wrote: > >> > >> On Mon, 21 Nov 2022, Qing Zhao wrote: > >> > >>> > >>> > On Nov 18,

Re: [PATCH 2/2] Add a new warning option -Wstrict-flex-arrays.

On Fri, Nov 18, 2022 at 03:19:07PM +, Qing Zhao wrote: > Hi, Richard, > > Honestly, it’s very hard for me to decide what’s the best way to handle the > interaction > between -fstrict-flex-array=M and -Warray-bounds=N. > > Ideally, -fstrict-flex-array=M should completely control the

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

On Wed, Aug 31, 2022 at 08:35:12PM +, Qing Zhao wrote: > One of the major purposes of the new option -fstrict-flex-array is to > encourage standard conforming programming style. > > So, it might be reasonable to treat -fstrict-flex-array similar as -pedantic > (but only for flexible array

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

On Wed, Aug 31, 2022 at 08:16:49PM +, Qing Zhao wrote: > > > On Aug 31, 2022, at 4:09 PM, Joseph Myers wrote: > > > > On Wed, 31 Aug 2022, Qing Zhao wrote: > > > When -std=gnu89 + -fstrict-flex-array=3 (ONLY C99 flexible array member > [] is treated as a valid flexible array)

Re: [GCC13][Patch][V2][2/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836

On Tue, Jul 19, 2022 at 02:11:19PM +, Qing Zhao wrote: > From a09f39ded462611286a44d9e8273de8342673ba2 Mon Sep 17 00:00:00 2001 > From: Qing Zhao > Date: Mon, 18 Jul 2022 18:12:26 + > Subject: [PATCH 2/2] Use new flag DECL_NOT_FLEXARRAY in __builtin_object_size > [PR101836] > > Use new

Re: [GCC13][Patch][V2][1/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836

On Thu, Jul 28, 2022 at 07:26:57AM +, Richard Biener wrote: > On Tue, 19 Jul 2022, Qing Zhao wrote: > > [...] > > +@cindex @code{strict_flex_array} variable attribute > > +@item strict_flex_array (@var{level}) > > +The @code{strict_flex_array} attribute should be attached to the trailing > >

Re: [GCC13][Patch][V2][1/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836

On Tue, Jul 19, 2022 at 02:09:46PM +, Qing Zhao wrote: > [...] > diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc > index c8d96723f4c..10d16532f0d 100644 > --- a/gcc/c-family/c-attribs.cc > +++ b/gcc/c-family/c-attribs.cc > @@ -101,6 +101,8 @@ static tree

Re: [PATCH v3 1/1] [ARM] Add support for TLS register based stack protector canary access

On Tue, Oct 26, 2021 at 10:18:36AM +0200, Ard Biesheuvel wrote: > Add support for accessing the stack canary value via the TLS register, > so that multiple threads running in the same address space can use > distinct canary values. This is intended for the Linux kernel running in > SMP mode, where

Re: [RFC PATCH 0/1] implement TLS register based stack canary for ARM

On Thu, Oct 21, 2021 at 06:34:04PM +0200, Ard Biesheuvel wrote: > On Thu, 21 Oct 2021 at 12:23, Ard Biesheuvel wrote: > > > > Bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102352 > > > > In the Linux kernel, user processes calling into the kernel are > > essentially threads running in

Re: [patch][gcc12-changes] Add a new item about the support for automatic static variable initialization

On Wed, Sep 29, 2021 at 02:43:35PM +, Qing Zhao wrote: > FYI, just committed the change: > > https://gcc.gnu.org/gcc-12/changes.html Looks great to me; thanks! :) -Kees -- Kees Cook

Re: [patch][gcc12-changes] Add a new item about the support for automatic static variable initialization

On Tue, Sep 28, 2021 at 08:31:13PM +, Qing Zhao wrote: > Hi, > > This is the patch for the gcc12 changes per your request. > > Kees provided most of the wording. > > Please take a look and let’s know whether it’s good for commit? > > thanks. > > Qing > >

Re: [COMMITTED][patch][version 9]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Thu, Sep 09, 2021 at 10:49:11PM +, Qing Zhao wrote: > Hi, FYI > > I just committed the following patch to gcc upstream: > > > https://gcc.gnu.org/pipermail/gcc-cvs/2021-September/353195.html Hurray! Thank you so much for working on this, and thanks also to the reviewers and everyone

Re: [patch][version 7]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Thu, Jul 29, 2021 at 08:02:43PM +, Qing Zhao wrote: > This is the 7th version of the patch for the new security feature for GCC. > I have tested it with bootstrap on both x86 and aarch64, regression testing > on both x86 and aarch64. > Also compile CPU2017 (running is ongoing), without any

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Tue, Jul 27, 2021 at 03:26:00AM +, Qing Zhao wrote: > This is the 6th version of the patch for the new security feature for GCC. > > I have tested it with bootstrap on both x86 and aarch64, regression testing > on both x86 and aarch64. > Also compile CPU2017 (running is ongoing), without

Re: [patch][version 4]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Wed, Jul 14, 2021 at 07:30:45PM +, Qing Zhao wrote: > Hi, Kees, > > > > On Jul 14, 2021, at 2:11 PM, Kees Cook wrote: > > > > On Wed, Jul 14, 2021 at 02:09:50PM +, Qing Zhao wrote: > >> Hi, Richard, > >> > >>> On Jul 14, 2021, at 2:14 AM, Richard Biener > >>> wrote: > >>> > >>>

Re: [patch][version 4]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Wed, Jul 14, 2021 at 02:09:50PM +, Qing Zhao wrote: > Hi, Richard, > > > On Jul 14, 2021, at 2:14 AM, Richard Biener > > wrote: > > > > On Wed, Jul 14, 2021 at 1:17 AM Qing Zhao wrote: > >> > >> Hi, Kees, > >> > >> I took a look at the kernel testing case you attached in the previous

Re: [patch][version 4]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Tue, Jul 13, 2021 at 11:16:59PM +, Qing Zhao wrote: > Hi, Kees, > > I took a look at the kernel testing case you attached in the previous email, > and found the testing failed with the following case: > > #define INIT_STRUCT_static_all = { .one = arg->one,\ >

Re: [patch][version 4]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Tue, Jul 13, 2021 at 02:29:33PM -0700, Kees Cook wrote: > I've extracted the kernel test to build for userspace, and it behaves > the same way. See attached "stackinit.c". I've adjusted this slightly (the "static" tests weren't testing the correct thing, but the results remained the same).

Re: [patch][version 4]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Mon, Jul 12, 2021 at 08:28:55PM +, Qing Zhao wrote: > > On Jul 12, 2021, at 12:56 PM, Kees Cook wrote: > > On Wed, Jul 07, 2021 at 05:38:02PM +, Qing Zhao wrote: > >> This is the 4th version of the patch for the new security feature for GCC. > > > > It looks like padding

Re: [patch][version 4]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Wed, Jul 07, 2021 at 05:38:02PM +, Qing Zhao wrote: > Hi, > > This is the 4th version of the patch for the new security feature for GCC. > > I have tested it with bootstrap on both x86 and aarch64, regression testing > on both x86 and aarch64. > Also compile and run CPU2017, without any

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Tue, Jun 22, 2021 at 09:25:57AM +0100, Richard Sandiford wrote: > Kees Cook writes: > > On Mon, Jun 21, 2021 at 03:39:45PM +, Qing Zhao wrote: > >> So, if “pattern value” is “0x”, then it’s a valid > >> canonical virtual memory address. However, for most OS, > >>

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Mon, Jun 21, 2021 at 03:39:45PM +, Qing Zhao wrote: > So, if “pattern value” is “0x”, then it’s a valid canonical > virtual memory address. However, for most OS, “0x” should be > not in user space. > > My question is, is “0xF” good for

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Wed, Jun 16, 2021 at 07:39:02PM +, Qing Zhao wrote: > So, the major question now is: > > Is one single repeatable pattern enough for pattern initialization for all > different types of auto variables? > > If YES, then the implementation for pattern initialization will be much > easier

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Fri, Jun 11, 2021 at 01:04:09PM +0200, Richard Biener wrote: > On Tue, 8 Jun 2021, Kees Cook wrote: > > > On Tue, Jun 08, 2021 at 09:41:38AM +0200, Richard Biener wrote: > > > On Mon, 7 Jun 2021, Qing Zhao wrote: > > > > > > > Hi, > > > > > > > > > On Jun 7, 2021, at 2:53 AM, Richard Biener

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Fri, Jun 11, 2021 at 03:49:02PM +, Qing Zhao wrote: > > On Jun 11, 2021, at 6:12 AM, Richard Biener wrote: > > [...] > > > > The main point is that you need to avoid building the explicit initializer > > only to have it consumed by assignment expansion. If you want to keep > > all the

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Tue, Jun 08, 2021 at 05:32:32PM +, Qing Zhao wrote: > Thanks a lot. > > Kees. > > Do you have the same issue with my emails? Some of them, yes. This one was fine. > I see this problem with my email mostly to part of the emails that were sent > to gcc-patches alias. > Other emails are

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Tue, Jun 08, 2021 at 09:41:38AM +0200, Richard Biener wrote: > On Mon, 7 Jun 2021, Qing Zhao wrote: > > > Hi, > > > > > On Jun 7, 2021, at 2:53 AM, Richard Biener wrote: > > > > > >> > > >> To address the above suggestion: > > >> > > >> My study shows: the call to __builtin_clear_padding

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Tue, Jun 08, 2021 at 09:37:30AM +0200, Richard Biener wrote: > On Mon, 7 Jun 2021, Qing Zhao wrote: > > On Jun 7, 2021, at 2:48 AM, Richard Biener > > mailto:rguent...@suse.de>> wrote: > > > > Meh - can you try using a mailer that does proper quoting? It's difficult > > to spot your added

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Mon, Jun 07, 2021 at 04:18:46PM +, Qing Zhao wrote: > Hi, > > > On Jun 7, 2021, at 2:53 AM, Richard Biener wrote: > > > >> > >> To address the above suggestion: > >> > >> My study shows: the call to __builtin_clear_padding is expanded during > >> gimplification phase. > >> And there

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Mon, Jun 07, 2021 at 09:48:41AM +0200, Richard Biener wrote: > On Thu, 27 May 2021, Qing Zhao wrote: > > @@ -5001,6 +5185,17 @@ gimplify_init_constructor (tree *expr_p, gimple_seq > > *pre_p, gimple_seq *post_p, > > /* If a single access to the target must be ensured and all > >

Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Tue, Jun 01, 2021 at 04:35:53PM -0400, David Malcolm wrote: > [...] > Did this patch get reviewed/approved? It's still under review, but I think it's close. > Is the latest version still this one: > https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565581.html > or is there a more

Re: [patch for gcc12 stage1][version 2] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Fri, Apr 23, 2021 at 08:05:29PM +0100, Richard Sandiford wrote: > Finally getting to this now that the GCC 11 rush is over. Sorry for > the slow response. > > I've tried to review most of the code below, but skipped the testsuite > parts in the interests of time. I'll probably have more

Re: [patch for gcc12 stage1][version 2] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Wed, Mar 24, 2021 at 04:21:49PM -0500, Qing Zhao wrote: > This is the 2nd version of the patch for the new security feature for GCC. > > Could you please take a look at it and let me know any comments and issues. This behaves perfectly as far as I'm able to test in the Linux kernel! Thank

Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Fri, Mar 12, 2021 at 03:35:28PM -0600, Qing Zhao wrote: > Hi, Kees, > > I am looking at the structure padding initialization issue. And also have > some questions: > > > > On Feb 24, 2021, at 10:41 PM, Kees Cook wrote: > > > > It looks like there is still some issues with padding and

Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Thu, Mar 11, 2021 at 03:47:17PM -0600, Qing Zhao wrote: > Hi, Kees, > > Sorry for the late reply (I have been busy with other work recently). > > Currently, I am working on the issue of flexible length array as the last > field of the structure. > > In order to fix it correctly, I have the

Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Thu, Feb 25, 2021 at 05:56:38PM -0600, Qing Zhao wrote: > Just noticed that you didn’t add -fauto-var-init-approach=D to the command > line. Ah-ha! I didn't realize that was needed; thanks. However, now some of the sources crash in a different way. Here's the reproducer: $ cat poc.i struct

Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Thu, Feb 25, 2021 at 12:15:01PM -0600, Qing Zhao wrote: > > On Feb 24, 2021, at 10:41 PM, Kees Cook wrote: > > [...] > > test_stackinit: trailing_hole_none ok > > test_stackinit: packed_none ok > > test_stackinit: user ok > > test_stackinit: failures: 8 > > Does the above testing include

Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

(please keep me in CC, I'm not subscribed...) On Thu Feb 18, 2021 Qing Zhao said: > Initialize automatic variables with new first class option > -ftrivial-auto-var-init=[uninitialized|pattern|zero] Yay! I'm really excited to see this. Thank you for working on it! I've built GCC with this

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

[tried to clean up quoting...] On Tue, Sep 08, 2020 at 10:00:09AM -0500, Qing Zhao wrote: > > > On Sep 7, 2020, at 8:06 AM, Rodriguez Bahena, Victor > > wrote: > > > >>> On Thu, Sep 03, 2020 at 09:29:54AM -0500, Qing Zhao wrote: > >>> So, my question is: > >>> > >>> From the security point of

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

On Thu, Sep 03, 2020 at 09:29:54AM -0500, Qing Zhao wrote: > On average, all the options starting with “used_…” (i.e, only the registers > that are used in the routine will be zeroed) have very low runtime overheads, > at most 1.72% for integer benchmarks, and 1.17% for FP benchmarks. > If all

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

On Mon, Aug 10, 2020 at 11:39:26PM -0300, Alexandre Oliva wrote: > Erhm, I don't get why it's important that they be zeroed. It seems to > me that restoring their original values, or setting them to random > values, would be just as good defenses from having them set within the In the

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

On Thu, Aug 06, 2020 at 10:37:43AM +0200, Richard Biener wrote: > OK, so -fzero-call-used-regs is a ROP mitigation technique. To me > it sounded more like a mitigation against information leaks which > then would be highly incomplete w/o spill slot clearing. Like > we had that discussion on

Re: PING[STAGE 1][PATCH][x86][1/3]: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

On Mon, May 04, 2020 at 12:02:45PM -0700, H.J. Lu wrote: > On Mon, May 4, 2020 at 11:21 AM Kees Cook wrote: > > > > On Mon, May 04, 2020 at 11:51:49AM -0500, Qing Zhao wrote: > > > Hi, > > > > > > This is a PING for this patch for gcc11 stage 1. > > > > > >

Re: PING[STAGE 1][PATCH][x86][1/3]: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

On Mon, May 04, 2020 at 11:51:49AM -0500, Qing Zhao wrote: > Hi, > > This is a PING for this patch for gcc11 stage 1. > > https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544058.html > > > Please take a look on it. Hi! I

Re: [PATCH] [RFC] rs6000: -mreadonly-in-sdata (PR82411)

On Wed, Feb 28, 2018 at 4:39 PM, Segher Boessenkool wrote: > On Wed, Feb 28, 2018 at 04:15:23PM -0800, Kees Cook wrote: >> On Wed, Feb 28, 2018 at 3:23 PM, Segher Boessenkool >> wrote: >> > I'm trying to figure out how to get that file to

Re: [PATCH] [RFC] rs6000: -mreadonly-in-sdata (PR82411)

On Wed, Feb 28, 2018 at 3:23 PM, Segher Boessenkool wrote: > On Wed, Feb 28, 2018 at 01:46:33PM -0800, Kees Cook wrote: >> On Tue, Feb 27, 2018 at 2:01 PM, Segher Boessenkool >> wrote: >> > This adds a new option -mreadonly-in-sdata (on by

Re: [PATCH] [RFC] rs6000: -mreadonly-in-sdata (PR82411)

On Tue, Feb 27, 2018 at 2:01 PM, Segher Boessenkool wrote: > This adds a new option -mreadonly-in-sdata (on by default) that > controls whether readonly data can be put in sdata. (For EABI this > does nothing, readonly data is put in sdata2 as usual). Cool! Thanks