From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69836 invoked by alias); 10 Dec 2019 06:22:43 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 69826 invoked by uid 89); 10 Dec 2019 06:22:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=D*hotmail.com, induce, Bounds-checking, Cll X-HELO: mail-ua1-f66.google.com Received: from mail-ua1-f66.google.com (HELO mail-ua1-f66.google.com) (209.85.222.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 10 Dec 2019 06:22:42 +0000 Received: by mail-ua1-f66.google.com with SMTP id f9so6424598ual.4 for ; Mon, 09 Dec 2019 22:22:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Pgg8mVFjCMvaoJuV1lOMTnnk8HMmjCcb5+oK8nT2eI0=; b=sV9L9j75gcVjxpxKbwOwL49DqnbIbyiPwAUE4FhyeL8Ff6wgNzNg8qp+H6cr7BgR3C HibKESoIWIQ4cp+t0EnnEBQxpwFEWzI7kr8kTHz066qp6Xfgph0qTI36ZU+vQ6a6bjjW dAxFZMkIsV+DLIWnHaUTfzjhAEcXMLZG+v1cbtph5YaxZDqDXK2IGQKFgphmlTN9j85B wiuEzEzQgIYF+cvgH+WmOpaIpsjOlQv933NUGChK7p70ba70hBczs7twx5n5tAvtEv+X B/l9JL22DSydO3N1pvKwgT/gaQdi/yIVVqOksYPU1f+Dp3xpVc7k1a43EzRCAyBM72yO HByQ== MIME-Version: 1.0 References: <4C695126-AB18-4629-A498-76617857DB78@hotmail.com> In-Reply-To: <4C695126-AB18-4629-A498-76617857DB78@hotmail.com> From: Andrew Pinski Date: Tue, 10 Dec 2019 06:22:00 -0000 Message-ID: Subject: Re: Usage of C11 Annex K Bounds-checking interfaces on GCC To: li zi Cc: "gcc@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00149.txt.bz2 On Mon, Dec 9, 2019 at 10:14 PM li zi wrote: > > Hi All, > We are using gcc in our projects and we found some of the C standard func= tions (like memcpy, strcpy) used in gcc may induce security vulnerablities = like buffer overflow. Currently we have not found any instances which cause= s such issues. Are you using GCC as a compiler or the sources of GCC to do something else? If you are using it as a compiler, GCC does NOT provide the libc functions, another project (e.g. glibc) provides those. > But we feel better to change these calls to Cll Annex K Bounds-checking i= nterfaces like memcpy_s, strcpy_s etc. By defining a secure calls method (l= ist of func pointers) and allowing application to register the method. I un= derstand that this affects performance because of return value check added = for xxxx_s calls, but this will relieve overflow kind of issues from code. = And also currently using bounds-checking interfaces is a general industry p= ractice. > Please share your opinion on it, and if any discussion happened in commun= ity to do some changes in future. Really the _s functions are not so good and right now are optional part of the C standard and not even implemented by glibc. Plus they not so useful and there are other methods of producing similar code without them. Thanks, Andrew > > Thanks. > li > >