Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1469462pxa; Thu, 20 Aug 2020 12:06:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxbD0NPATBUq9nNaDXZnpMYwJtaY3dLzEYcur9E+FTHMeHnTn2ggsZPnO2INnx6rEehmHAI X-Received: by 2002:a17:906:b110:: with SMTP id u16mr58668ejy.483.1597950364632; Thu, 20 Aug 2020 12:06:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597950364; cv=none; d=google.com; s=arc-20160816; b=0JQf9CA4EeRAHFWP5JaGpgsc4laez1Lm6Fdzw1YtneXCsL7P3I3EbqGJpWOMoo0a5R E0hh0Zi4iMI22wD3Gpa0gtk0y5mP60nPGa+U9RacdG1XmIgidgqC6RV/mIMvj/9ri9H8 dXZX3t3m6UG1oFhGmjmufaoxjJRmxZyNTrExz1t72aTY0Bd6GtRRsM51+zdKLul0jEML qRD+W+pOdtZ7NHtL1q7tU+dZ3FM/1BkdU9kWaR6/Ad82/b2umXW57DQWJWHudDXcVk2k Px5XbuoPEOtAxdhIKa8tnjifU1WleOnSnLtGjjvhHfG+y+Ud2uz+APKJdO87RuuRwzc8 JH5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=xswSx5sBRdGqWy7m+JAEwKsyUNhOueCNUf2Bs425COY=; b=djLgF+1H3J84BE0OTMhWc7f0aBydcH3wQKkMA1spJH72WFn4wq7al4h80r4QyIRSkm Fsn0KPc7xP7735Y41+0PawTxz22zoGInSF8DHQFqar1e0t6WLmGme+5s1M8nCTGMHbCU sEAFDXLfkhCLAKIuhlcavE+D+4xgOZe08IneXQtIzC0vE4yY3OhPawXStrJHv1CnXj8o Y/ZWy5JmBBGYF7jGVkQJEqzeryurRMeJP22BQpryVJhkXoZ+0PXE2K5kA/sUu/GoxzQc grc9XpnQlgkKwkchdDbjHSlGoMhASr8PT1CiizFtGff+wf3uhwAugV4NIvBLnePOKsfH hnPg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=YgjQySlg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a18si2015518ejr.184.2020.08.20.12.05.40; Thu, 20 Aug 2020 12:06:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=YgjQySlg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727979AbgHTTE5 (ORCPT + 99 others); Thu, 20 Aug 2020 15:04:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33048 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727884AbgHTTEv (ORCPT ); Thu, 20 Aug 2020 15:04:51 -0400 Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 93B4CC061387 for ; Thu, 20 Aug 2020 12:04:50 -0700 (PDT) Received: by mail-ed1-x543.google.com with SMTP id l23so2484036edv.11 for ; Thu, 20 Aug 2020 12:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xswSx5sBRdGqWy7m+JAEwKsyUNhOueCNUf2Bs425COY=; b=YgjQySlg/iJIcLjVeYMYfs6nHZ0TBX0Osdu5/PR0ioBTn1qODpMbK2EvPQHig4GYxX 3WqnjZQFDbDAJOmcrdXxf9yGlAUj6v9DGoFpNDoQYOpcL6UJ/mWdSdo+iexH/aZk2MQw vzWyUetDMt9/nhrDW7Jz7QSVwNgmiP+PPChHP8KG3i0kmjU665QRM1KUHpfzQtCWp0nR ej5+V+jONMstbL1hYaigI9G9+K1lQePpUskJuhCCauQM6/FVNpiH+5cGabC/a2DSndz2 4l/DzmqjsMkSjLmuLFt/MM4eqvsC8rkiJUBmlpfNSHGRwQq9K+/xkrnR79i9uBrhBG6f yi6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xswSx5sBRdGqWy7m+JAEwKsyUNhOueCNUf2Bs425COY=; b=cWvd3zKhH5esXrXo0VglV+/2FxFoMd58zmZQOlil46lI1mRyIDjWUjHaFNksBNdA2o +/bIc8+zPO/AuXvCP397R3gFDobfx2/HKRWU2q27ty26RnQap/tCb2G992061YQeo/c1 BSzCSG9o7PJMOCwe9tAuF39uQsUuN8ULhazbh8EneX420gcTu+jQ81T7Qx/WsNY264/H FgmZcWEIhffpX3Od3WKu9m0FxAFp5VDEScAz7rRkFzSbi0r9ueXPIWVPtNRlHRNiqblO L71eZ8tyG0siNX5dYirm4KkMKf9Lu+kDZxxV1vOJRaPog1yHtqZeJTuhSW93snlJDR73 MLOw== X-Gm-Message-State: AOAM531CzFfXdnwqG8w2hefncvsqLH0kdhXXniX1Xrc6k5fG7UFNoGBW Y1Z05HGUTVIwxkIW6Q8or30RuhGJ1arIw+/W4Hzr X-Received: by 2002:aa7:cf19:: with SMTP id a25mr4175514edy.67.1597950288828; Thu, 20 Aug 2020 12:04:48 -0700 (PDT) MIME-Version: 1.0 References: <20200820164753.3256899-1-jackmanb@chromium.org> In-Reply-To: From: KP Singh Date: Thu, 20 Aug 2020 21:04:32 +0200 Message-ID: Subject: Re: [RFC] security: replace indirect calls with static calls To: James Morris Cc: Brendan Jackman , Linux Kernel Mailing List , bpf@vger.kernel.org, linux-security-module@vger.kernel.org, Paul Renauld , Alexei Starovoitov , Daniel Borkmann , Paul Turner , Jann Horn , peterz@infradead.org, rafael.j.wysocki@intel.com, keescook@chromium.org, thgarnie@chromium.org, paul.renauld.epfl@gmail.com, Brendan Jackman Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 20, 2020 at 8:43 PM James Morris wrote: > > On Thu, 20 Aug 2020, Brendan Jackman wrote: > > > With this implementation, any overhead of the indirect call in the LSM > > framework is completely mitigated (performance results: [7]). This > > facilitates the adoption of "bpf" LSM on production machines and also > > benefits all other LSMs. > > This looks like a potentially useful improvement, although I wonder if it > would be overshadowed by an LSM hook doing real work. > Thanks for taking a look! We can surely look at other examples, but the real goal is to optimize the case where the "bpf" LSM adds callbacks to every LSM hook which don't do any real work and cause an avoidable overhead. This makes it not very practical for data center environments where one would want a framework that adds a zero base case overhead and allows the user to decide where to hook / add performance penalties. (at boot time for other LSMs and at runtime for bpf) I also think this would be beneficial for LSMs which use a cache for a faster policy decision (e.g. access vector caching in SELinux). - KP > Do you have any more benchmarking beyond eventfd_write() ? > > > > > > > [1]: https://lwn.net/ml/linux-kernel/20200710133831.943894387@infradead.org/ [...] > > > > /* Security operations */ > > > > -- > James Morris > >