From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77962 invoked by alias); 15 Aug 2017 13:43:03 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 67423 invoked by uid 89); 15 Aug 2017 13:42:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=directs, malware, Hx-languages-length:3774 X-HELO: mail-wm0-f43.google.com Received: from mail-wm0-f43.google.com (HELO mail-wm0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 15 Aug 2017 13:42:39 +0000 Received: by mail-wm0-f43.google.com with SMTP id m85so9113848wma.0 for ; Tue, 15 Aug 2017 06:42:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nL90zEFiCdILWDshXRkWm1T50cA8C3HYOYJxLuG0rqU=; b=r4UiYOSFkVUTVqqNwTFsfey0tZ1e5b9D85jPJTfVhuM80XX5dzZ7p4xjx95k7duiTc T5pWCtHoF810DgYINfK1rz1ndayHL2c6rTsQBTG2eVhNUVZant8ORWID7+ORjw1V/esG XrG75Vu0DaqL/0RhqG2vgvgFOKJaj6u7MEIoYy6FJ1TTrP8cy8qBtr6TO8jeV3Q08MgO /Lkz3Zt8DyX2sP/IpJew5WBlBRBoI9+WzQObwrLgDhOMrhqJ6AOUTneZCKd6sn6SMTXS yyTHcaGAbrUQabN8WB7uRH3gPKck7UEW1XUdIINwFn7b9JrkqlxcSVSzkjrKpg4mlSBj Wkvg== X-Gm-Message-State: AHYfb5gh0VXZl7wnpMv0LFEImG+JMN20pOeTOLJ+QZy9wYa5pI8H7Nsm kCh2hFFbGMqiw9nHWdp8Gn62rUzgJqkCJWQ= X-Received: by 10.80.194.146 with SMTP id o18mr15199326edf.197.1502804557777; Tue, 15 Aug 2017 06:42:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.180.249 with HTTP; Tue, 15 Aug 2017 06:42:37 -0700 (PDT) In-Reply-To: References: From: Richard Biener Date: Tue, 15 Aug 2017 14:08:00 -0000 Message-ID: Subject: Re: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling To: "Tsimbalist, Igor V" Cc: "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg00939.txt.bz2 On Tue, Aug 1, 2017 at 10:56 AM, Tsimbalist, Igor V wrote: > Part#1. Add generic part for Intel CET enabling. > > The spec is available at > > https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf > > High-level design. > ------------------ > > A proposal is to introduce a target independent flag > -finstrument-control-flow with a semantic to instrument a code to > control validness or integrity of control-flow transfers using jump > and call instructions. The main goal is to detect and block a possible > malware execution through transfer the execution to unknown target > address. Implementation could be either software or target based. Any > target platforms can provide their implementation for instrumentation > under this option. > > When the -finstrument-control-flow flag is set each implementation has > to check if a support exists for a target platform and report an error > if no support is found. > > The compiler should instrument any control-flow transfer points in a > program (ex. call/jmp/ret) as well as any landing pads, which are > targets of for control-flow transfers. > > A new 'notrack' attribute is introduced to provide hand tuning support. > The attribute directs the compiler to skip a call to a function and a > function's landing pad from instrumentation (tracking). The attribute > can be used for function and pointer to function types, otherwise it > will be ignored. The attribute is saved in a type and propagated to a > GIMPLE call statement and later to a call instruction. > > Currently all platforms except i386 will report the error and do no > instrumentation. i386 will provide the implementation based on a > specification published by Intel for a new technology called > Control-flow Enforcement Technology (CET). diff --git a/gcc/gimple.c b/gcc/gimple.c index 479f90c..2e4ab2d 100644 --- a/gcc/gimple.c +++ b/gcc/gimple.c @@ -378,6 +378,23 @@ gimple_build_call_from_tree (tree t) gimple_set_no_warning (call, TREE_NO_WARNING (t)); gimple_call_set_with_bounds (call, CALL_WITH_BOUNDS_P (t)); + if (fndecl == NULL_TREE) + { + /* Find the type of an indirect call. */ + tree addr = CALL_EXPR_FN (t); + if (TREE_CODE (addr) != FUNCTION_DECL) + { + tree fntype = TREE_TYPE (addr); + gcc_assert (POINTER_TYPE_P (fntype)); + fntype = TREE_TYPE (fntype); + + /* Check if its type has the no-track attribute and propagate + it to the CALL insn. */ + if (lookup_attribute ("notrack", TYPE_ATTRIBUTES (fntype))) + gimple_call_set_with_notrack (call, TRUE); + } + } this means notrack is not recognized if fndecl is not NULL. Note that only the two callers know the real function type in effect (they call gimple_call_set_fntype with it). I suggest to pass down that type to gimple_build_call_from_tree and move the gimple_call_set_fntype call there as well. And simply use the type for the above. +static inline bool +gimple_call_with_notrack_p (const gimple *gs) +{ + const gcall *gc = GIMPLE_CHECK2 (gs); + return gimple_call_with_notrack_p (gc); +} please do not add gimple * overloads for new APIs, instead make sure to pass down gcalls at callers. Please change the names to omit 'with_', thus just notrack and GF_CALL_NOTRACK. I think 'notrack' is somewhat unspecific of a name, what prevented you to use 'nocet'? Any idea how to implement a software-based solution efficiently? Creating a table of valid destination addresses in a special section should be possible without too much work, am I right in that only indirect control transfer is checked? Thus CET assumes the code itself cannot be changed (and thus the stack isn't executable)? Thanks, Richard.