From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0529BC35242 for ; Tue, 11 Feb 2020 21:38:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CB8ED2073C for ; Tue, 11 Feb 2020 21:38:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Kp+kvUFE" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727587AbgBKVi0 (ORCPT ); Tue, 11 Feb 2020 16:38:26 -0500 Received: from mail-pf1-f194.google.com ([209.85.210.194]:38012 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727361AbgBKViZ (ORCPT ); Tue, 11 Feb 2020 16:38:25 -0500 Received: by mail-pf1-f194.google.com with SMTP id x185so92291pfc.5; Tue, 11 Feb 2020 13:38:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=oJSY3+unP7njMIVK4X94hP/7d/d2A7Dqq9Ad7uaQNuM=; b=Kp+kvUFE8QBS06WMeMrPfDHf6XHJBSFjBNdpWZoNQEFuDXpQNvDlKsacoJXbKp/F0z 7mjYdwKOaTU+l/BbI0M35AbxA4Bk+zW+knm5/w/vdR+3T1qXdCJkIIWDy0dwlbgz8NxY 3cu40q8BNwsRHaAh+O5VbTV5B7QzT5e7tKwELBIAbIJAwytkfzTVvEKVVK86NXy4k0NS REEU+ySD34LlI7ixGYsC9mQzCTXJO/9Hoovi73SZQLq6iNnA2NqlEeMr+rggUykmNwU6 3na9+7zREZUQHoLyBc88JraQMoPZNVka+XeZCODMhZqcujAlao92ta4IcvKoPzLbp0mP vfpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=oJSY3+unP7njMIVK4X94hP/7d/d2A7Dqq9Ad7uaQNuM=; b=HXihRdvmOARFnYqFhbp3wgqcNg64kjntwnj2SyCAISENS/QhdICPBQPrSlN0QLLuCc F+xJUoBaZAjQCf11Lusl63x6IWc2Vef4dX0Wvz6s2dVyUTAc2aYeVv3Hk0SicgwOxeR6 soCpl31HYvKnjjPnmG3rzMUxSPw/2cSdvKFx2qMmFOxNlDB7Cl93NWGwy20yUHntck3o nSLhPPMNn5JVcSMypaB6TbQTBMk50gFrb1jfX+PwIumX7FMETOR5xBF6XmIssWxbV2Mf RdTw95ibC/3SRkXebLGzJ2LgnNCfmbYKh9Qgd1+M6GZVXkMPwqVerHssPs3/N19xP0id jZ1Q== X-Gm-Message-State: APjAAAX2Ht5HDPzhYWDlmff9wiO3JmJI7HX0T++xfXdZX+z90d62AdTU aT1hXOQ11dySP8BQUuV/Nro= X-Google-Smtp-Source: APXvYqzPQNC73PGSmEbOYih8cQaHC5eGDgjAfZNnep7lcccZ066rjEwUFgQM6K61/xXQOktcYcoP3g== X-Received: by 2002:aa7:8ad9:: with SMTP id b25mr5108673pfd.70.1581457103385; Tue, 11 Feb 2020 13:38:23 -0800 (PST) Received: from ast-mbp ([2620:10d:c090:200::1:aeb4]) by smtp.gmail.com with ESMTPSA id d14sm4447685pjz.12.2020.02.11.13.38.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Feb 2020 13:38:22 -0800 (PST) Date: Tue, 11 Feb 2020 13:38:20 -0800 From: Alexei Starovoitov To: Jann Horn Cc: KP Singh , kernel list , bpf@vger.kernel.org, linux-security-module , Brendan Jackman , Florent Revest , Thomas Garnier , Alexei Starovoitov , Daniel Borkmann , James Morris , Kees Cook , Thomas Garnier , Michael Halcrow , Paul Turner , Brendan Gregg , Matthew Garrett , Christian Brauner , =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= , Florent Revest , Brendan Jackman , "Serge E. Hallyn" , Mauro Carvalho Chehab , "David S. Miller" , Greg Kroah-Hartman , Kernel Team Subject: Re: BPF LSM and fexit [was: [PATCH bpf-next v3 04/10] bpf: lsm: Add mutable hooks list for the BPF LSM] Message-ID: <20200211213819.j4ltrjjkuywihpnv@ast-mbp> References: <20200123152440.28956-1-kpsingh@chromium.org> <20200123152440.28956-5-kpsingh@chromium.org> <20200211031208.e6osrcathampoog7@ast-mbp> <20200211124334.GA96694@google.com> <20200211175825.szxaqaepqfbd2wmg@ast-mbp> <20200211190943.sysdbz2zuz5666nq@ast-mbp> <20200211201039.om6xqoscfle7bguz@ast-mbp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180223 Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On Tue, Feb 11, 2020 at 09:33:49PM +0100, Jann Horn wrote: > > > > Got it. Then let's whitelist them ? > > All error injection points are marked with ALLOW_ERROR_INJECTION(). > > We can do something similar here, but let's do it via BTF and avoid > > abusing yet another elf section for this mark. > > I think BTF_TYPE_EMIT() should work. Just need to pick explicit enough > > name and extensive comment about what is going on. > > Sounds reasonable to me. :) awesome :) > > Locking rules and cleanup around security_blah() shouldn't change though. > > Like security_task_alloc() should be paired with security_task_free(). > > And so on. With bpf_sk_storage like logic the alloc/free of scratch > > space will be similar to the way socket and bpf progs deal with it. > > > > Some of the lsm hooks are in critical path. Like security_socket_sendmsg(). > > retpoline hurts. If we go with indirect calls right now it will be harder to > > optimize later. It took us long time to come up with bpf trampoline and build > > bpf dispatcher on top of it to remove single indirect call from XDP runtime. > > For bpf+lsm would be good to avoid it from the start. > > Just out of curiosity: Are fexit hooks really much cheaper than indirect calls? > > AFAIK ftrace on x86-64 replaces the return pointer for fexit > instrumentation (see prepare_ftrace_return()). So when the function > returns, there is one return misprediction for branching into > return_to_handler(), and then the processor's internal return stack > will probably be misaligned so that after ftrace_return_to_handler() > is done running, all the following returns will also be mispredicted. > > So I would've thought that fexit hooks would have at least roughly the > same impact as indirect calls - indirect calls via retpoline do one > mispredicted branch, fexit hooks do at least two AFAICS. But I guess > indirect calls could still be slower if fexit benefits from having all > the mispredicted pointers stored on the cache-hot stack while the > indirect branch target is too infrequently accessed to be in L1D, or > something like that? For fexit I've tried ftrace style of overwriting return address in the stack, but it was slower than "leave; add rsp, 8; ret". So I went with that. Looks like skipping one frame makes intel return stack prediction work better than overwriting. I tested on broadwell only though. Later I realized that I can do "jmp bpf_trampoline" instead of "call bpf_trampoline", so this extra 'add rsp, 8' can be removed and both direct jump and return stack predictors will be happy. Will be posting this patch soon. Old perf numbers of fexit vs original vs kprobe: https://lore.kernel.org/bpf/20191122011515.255371-1-ast@kernel.org/