From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <xry111@mengyan1223.wang>
Received: from mengyan1223.wang (mengyan1223.wang [89.208.246.23])
 by sourceware.org (Postfix) with ESMTPS id A47753858D39
 for <gcc-help@gcc.gnu.org>; Wed,  2 Mar 2022 20:23:55 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A47753858D39
Received: from [IPv6:240e:358:11fa:cc00:dc73:854d:832e:4] (unknown
 [IPv6:240e:358:11fa:cc00:dc73:854d:832e:4])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature ECDSA (P-384))
 (Client did not present a certificate)
 (Authenticated sender: xry111@mengyan1223.wang)
 by mengyan1223.wang (Postfix) with ESMTPSA id C2E6465C98;
 Wed,  2 Mar 2022 15:23:51 -0500 (EST)
Message-ID: <204cd10c9d34c6c798e701f1d990c120c2d77897.camel@mengyan1223.wang>
Subject: Re: Fortify_source and stack-protector-strong
From: Xi Ruoyao <xry111@mengyan1223.wang>
To: Reinoud Koornstra <reinoudkoornstra@gmail.com>
Cc: Florian Weimer <fweimer@redhat.com>, Reinoud Koornstra via Gcc-help
 <gcc-help@gcc.gnu.org>
Date: Thu, 03 Mar 2022 04:23:40 +0800
In-Reply-To: <CAAA5faE_s_4LWSDcTJxhdNUdD5_ELgWx=pVmJorf57Koesp_xg@mail.gmail.com>
References: <CAAA5faFWb6xz2mJ0LzRTxRHARq9vdmF+4bChWWEZCuW+uCNB4Q@mail.gmail.com>
 <87o82ok616.fsf@oldenburg.str.redhat.com>
 <CAAA5faGBqtp0=00Mi+7Cvk3nLuV_CpD7jT4OAJ4k7NxaFcb-5g@mail.gmail.com>
 <2a574a7a0dbb4f1ef4472d2a43b029f0ceca9065.camel@mengyan1223.wang>
 <CAAA5faE_s_4LWSDcTJxhdNUdD5_ELgWx=pVmJorf57Koesp_xg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3031.5 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, KAM_SHORT,
 SPF_HELO_PASS, SPF_PASS, TXREP,
 T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
X-BeenThere: gcc-help@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-help mailing list <gcc-help.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-help/>
List-Post: <mailto:gcc-help@gcc.gnu.org>
List-Help: <mailto:gcc-help-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Mar 2022 20:23:56 -0000

On Wed, 2022-03-02 at 12:05 -0800, Reinoud Koornstra wrote:
> Hi Xi,
> 
> Thanks for your reply.
> Then what is the difference between -D_FORTIFY_SOURCE=1 and -D_FORTIFY_SOURCE=2 exactly?

-D_FORTIFY_SOURCE=1 uses __builtin_object_size(..., 0) as the buffer
size, but -D_FORTIFY_SOURCE=2 uses __builtin_object_size(..., 1).  Read
https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html for the
details.

One case is:

struct frame
{
  int size;
  char buf[0];
};

union
{
  struct frame f;
  char padding[100 + sizeof(struct frame)];
} u;

u.frame.size = strlen(s) + 1;
strcpy(u.frame.buf, s);

-D_FORTIFY_SOURCE=2 will abort this, but -D_FORTIFY_SOURCE=1 won't. 
(Yes, I know "char buf[0]" should be changed to a flexible array member
"char buf[]" to fix this, but it is just an example.)
-- 
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University