From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12249 invoked by alias); 18 Aug 2017 13:53:29 -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 8670 invoked by uid 89); 18 Aug 2017 13:53:27 -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= X-HELO: mail-wm0-f49.google.com Received: from mail-wm0-f49.google.com (HELO mail-wm0-f49.google.com) (74.125.82.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 18 Aug 2017 13:53:25 +0000 Received: by mail-wm0-f49.google.com with SMTP id l19so449008wmi.1 for ; Fri, 18 Aug 2017 06:53:24 -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:content-transfer-encoding; bh=PSpEq2/G7hYiIKuupe1ASaJtE4QAnN1aA8w2QHy0FqU=; b=HlMn/zytm7mEPNMtDg9Ro6WikxQriJGWnNpG0/7kFLptX4ijP9qqFe0tPUyerGRWrq NzA7bm/7WjLgtTcgvzX0iEoG0yDgoV3e6wIIfZD9Aeu23Qxh8ODwnwbF8BQiDCveppHc x35GBq12RP0NxCb3Tply72q93SSlLlKeB6edmdR6iZJzUysuxBZv/wpx1moV2WpIkHDy evLKW67xf/A/sKglPKPVnD2r0lqRSTlXdaw+BM9CVlbKIxHjnyp44ndrWW0Fbd7lrcMm du9pwrMHvwI19byeKD9O2n66/7KuTAMEHxwe2vEOfgn8nwfK6pHmYWMeUodLD3bJKeV3 u7mg== X-Gm-Message-State: AHYfb5j9KwWZEvmjXzA64QDlTYKNyj+W6lxMutmnJ54Dff54mdTqv7Pc ZqllBVknZa/+Kg9/I0aiDYxELjj2HA== X-Received: by 10.80.185.70 with SMTP id m64mr4829550ede.246.1503064402958; Fri, 18 Aug 2017 06:53:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.180.249 with HTTP; Fri, 18 Aug 2017 06:53:22 -0700 (PDT) In-Reply-To: References: From: Richard Biener Date: Fri, 18 Aug 2017 14:06: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" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg01133.txt.bz2 On Fri, Aug 18, 2017 at 3:11 PM, Tsimbalist, Igor V wrote: >> -----Original Message----- >> From: Richard Biener [mailto:richard.guenther@gmail.com] >> Sent: Tuesday, August 15, 2017 3:43 PM >> To: Tsimbalist, Igor V >> Cc: gcc-patches@gcc.gnu.org >> Subject: Re: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling >> >> 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-f >> > low-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 =3D=3D NULL_TREE) >> + { >> + /* Find the type of an indirect call. */ >> + tree addr =3D CALL_EXPR_FN (t); >> + if (TREE_CODE (addr) !=3D FUNCTION_DECL) >> + { >> + tree fntype =3D TREE_TYPE (addr); >> + gcc_assert (POINTER_TYPE_P (fntype)); >> + fntype =3D 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 o= nly 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. > > The best way to say is notrack is not propagated if fndecl is not NULL. F= ndecl, if not NULL, is a direct call and notrack is not applicable for such= calls. I will add a comment before the if. Hmm. But what does this mean? I guess direct calls are always 'notrack' then and thus we're fine to ignore it. > I would like to propose modifying the existing code without changing inte= rfaces. The idea is that at the time the notrack is propagated (the code sn= ippet above) the gimple call was created and the correct type was assigned = to the 'call' exactly by gimple_call_set_fntype. My proposal is to get the = type out of the gimple 'call' (like gimple_call_fntype) instead of the tree= 't'. Is it right? Yes, but note that the type on the gimple 'call' isn't yet correctly set (only the caller does that). The gimple_build_call_from_tree is really an ugly thing and it should be privatized inside the gimplifier... >> +static inline bool >> +gimple_call_with_notrack_p (const gimple *gs) { >> + const gcall *gc =3D 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. > > Ok, I will remove. > >> Please change the names to omit 'with_', thus just notrack and >> GF_CALL_NOTRACK. > > Ok, I will rename. > >> I think 'notrack' is somewhat unspecific of a name, what prevented you to >> use 'nocet'? > > Actually it's specific. The HW will have a prefix with exactly this name = and the same meaning. And I think, what is more important, 'track/notrack' = gives better semantic for a user. CET is a name bound with Intel specific t= echnology. But 'tracking' something is quite unspecific. Tracking for what? 'no_verify_cf' (aka do not verify control flow) maybe? >> Any idea how to implement a software-based solution efficiently? >> Creating a table of valid destination addresses in a special section sho= uld 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)? > > Yes, your idea looks right. Microsoft has published the option /guard:cf = and according to the description it uses similar idea of gathering informat= ion about control-transfer targets. This info is kept in the binary. And 'y= es' for last two your questions. Ok, so if we generate a special section with say 'cettable' as symbol the verification runtime would be invoked at each indirect call site with the destination address and it would search the table and abort if the destination is not recorded. We probably have to support a set of CET tables and register them to support shared libraries (and cross shared object indirect calls). Do you plan to contribute sth like this? Maybe within the sanitizer framew= ork? Thanks, Richard. > Thanks, > Igor > >> Thanks, >> Richard.