From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79879 invoked by alias); 12 Sep 2017 14:33:00 -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 79868 invoked by uid 89); 12 Sep 2017 14:33:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=BAYES_00,BODY_8BITS,GARBLED_BODY,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=dunno, sk:dvyukov, U*dvyukov X-HELO: mail-it0-f44.google.com Received: from mail-it0-f44.google.com (HELO mail-it0-f44.google.com) (209.85.214.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 12 Sep 2017 14:32:58 +0000 Received: by mail-it0-f44.google.com with SMTP id v19so24025293ite.0 for ; Tue, 12 Sep 2017 07:32:58 -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=amWgsUWFb7S09AYcUPZqhU9EtydSG2Wb0MUW4byLk0o=; b=SKDlb+hj8ZAphdu3fqHdsipPBwql4OIQAMo/7YzGh5zl1TgzY5lpwWr88rHDXShSO/ B045c/tYvF12OHpwFTdBApOZFIlmyqdoO8TNe0qWk0JZauqsdspKTOy8O7NGKBtjUwbA ELysvw93ZRefFu1NbugAlXmYV/ZMCbhbVgGOODAsHw3wmXzoIdSO5WTVU420CI1Jly8j OJ3vW8dvRAefSH7kF4e7nA1bNxxj3vqWo1Xc6esPvZiHZHSN7JI9C7ihsmzPMwgvo23i tlaoT6ilx8b5K/xsPZkV5TvUk6d7YmYMmTdjCGy9jSqSyFf1yHqrYG52hwug0SEZMIVf B4Ag== X-Gm-Message-State: AHPjjUh+kAn7Cae5O3LDiJtw54AIIcC2yKqdi6SBP74EVqWQ0cGCgaQF pStnO2AENQhWspVUhf2l0roPfR4PotV+wB6pPjSS6w== X-Google-Smtp-Source: AOwi7QCHBaQjU1aSV9f/BJOyzS/kVggVa0l5f5UtMGhcEQ6lRtiNHHT5PR8CNyAiOgACs+KI/Hgu31tq6ATdfx4ISk0= X-Received: by 10.36.11.196 with SMTP id 187mr1370340itd.48.1505226776146; Tue, 12 Sep 2017 07:32:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.92.146 with HTTP; Tue, 12 Sep 2017 07:32:35 -0700 (PDT) In-Reply-To: <0d824338-6328-4fc2-87d6-3f831ba7599a.weixi.wwx@antfin.com> References: <234840fd-a06a-4dfd-a1c5-254e26144754.weixi.wwx@antfin.com> <887030ab-6bae-4dd5-b347-05bfad034603.weixi.wwx@antfin.com> <20170901162318.GN2323@tucnak> <20170903100121.GU2323@tucnak> <14d63d4d-aef0-4a82-b553-67d98da3cf42.weixi.wwx@antfin.com> <0d824338-6328-4fc2-87d6-3f831ba7599a.weixi.wwx@antfin.com> From: "Dmitry Vyukov via gcc-patches" Reply-To: Dmitry Vyukov Date: Tue, 12 Sep 2017 14:33:00 -0000 Message-ID: Subject: Re: Add support to trace comparison instructions and switch statements To: =?UTF-8?B?5ZC05r2N5rWgKOatpOW9vCk=?= Cc: Jakub Jelinek , gcc-patches , Jeff Law , wishwu007 , Kostya Serebryany , Alexander Potapenko , andreyknvl Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00694.txt.bz2 On Thu, Sep 7, 2017 at 9:02 AM, =E5=90=B4=E6=BD=8D=E6=B5=A0(=E6=AD=A4=E5=BD= =BC) wrote: > Hi > The trace-div and trace-gep options seems be used to evaluate corpus > to trigger specific kind of bugs. And they don't have strong effect to co= verage. > > The trace-pc-guard is useful, but it may be much more complex than trace-= pc. > I think the best benefit of trace-pc-guard is avoiding dealing ASLR of pr= ograms, > especially programs with dlopen(). Seems hard to implement it in Linux ke= rnel. > > The inline-8bit-counters and pc-table is too close to implementation of f= uzz tool and > option trace-pc-guard . > > I am interesting in "stack-depth" and "func". If we trace user-defined fu= nctions enter and exit, > we can calculate stack-depth and difference level of stack to past existe= d stack. > Adding __sanitizer_cov_trace_pc_{enter,exit} is easy , but it is not stan= dard of llvm. > > How do you think Dmitry ? > > Wish Wu > > ------------------------------------------------------------------ > From:Jakub Jelinek > Time:2017 Sep 6 (Wed) 22:37 > To:Wish Wu > Cc:Dmitry Vyukov ; gcc-patches ; Jeff Law ; wishwu007 > Subject:Re: Add support to trace comparison instructions and switch state= ments > > > On Wed, Sep 06, 2017 at 07:47:29PM +0800, =E5=90=B4=E6=BD=8D=E6=B5=A0(=E6= =AD=A4=E5=BD=BC) wrote: >> Hi Jakub >> I compiled libjpeg-turbo and libdng_sdk with options "-g -O3 -Wall -fsan= itize-coverage=3Dtrace-pc,trace-cmp -fsanitize=3Daddress". >> And run my fuzzer with pc and cmp feedbacks for hours. It works fine. >> About __sanitizer_cov_trace_cmp{f,d} , yes, it isn't provided by llvm. = But once we trace integer comparisons, why not real type comparisons. >> I remember Dmitry said it is not enough useful to trace real type compar= isons because it is rare to see them in programs. >> But libdng_sdk really has real type comparisons. So I want to keep them = and implementing __sanitizer_cov_trace_const_cmp{f,d} may be necessary. > > Ok. Please make sure those entrypoints make it into the various example > __sanitier_cov_trace* fuzzer implementations though, so that people using > -fsanitize-coverage=3Dtrace-cmp in GCC will not need to hack stuff themse= lves. > At least it should be added to sanitizer_common (both in LLVM and GCC). > > BTW, https://clang.llvm.org/docs/SanitizerCoverage.html shows various oth= er > -fsanitize-coverage=3D options, some of them terribly misnamed (e.g. trac= e-gep > using some weirdo LLVM IL acronym instead of being named by what it really > traces (trace-array-idx or something similar)). > > Any plans to implement some or all of those? Thanks, Jakub! I've tested it on Linux kernel. Compiler does not crash, code is instrument= ed. Re terribly misnamed trace-gep, dunno, I will leave this to Kostya. Re __sanitizer_cov_trace_cmp{f,d}, I am still not sure. > But libdng_sdk really has real type comparisons. Do they come from input data? In what format? How do you want to use them? E.g. if they come from input but with using some non-trivial transformation and the fuzzer will try to find them in the input, it won't be able to do so. On the other hand, it does not seem to be harmful, fuzzers that are not interested in them can just add empty callbacks. Re trace-pc-guard, I also don't have strong preference. Global variables should work for kernel, but we probably will not use them in kernel, because even aslr aside we would need to establish some global numbering of these globals across multiple different machines. But then it's much easier and simper to just use PCs as identifiers. Re __sanitizer_cov_trace_pc_{enter,exit}, I don't think we ever experimented/evaluated this idea. Do you have any data that it's useful? I suspect that it can grow corpus too much.