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=-6.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED autolearn=ham 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 AB6A7C43381 for ; Wed, 20 Feb 2019 18:35:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 848EB2146E for ; Wed, 20 Feb 2019 18:35:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jCsLpc3J" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726430AbfBTSfA (ORCPT ); Wed, 20 Feb 2019 13:35:00 -0500 Received: from mail-lf1-f66.google.com ([209.85.167.66]:44327 "EHLO mail-lf1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725834AbfBTSe7 (ORCPT ); Wed, 20 Feb 2019 13:34:59 -0500 Received: by mail-lf1-f66.google.com with SMTP id g2so18311242lfh.11 for ; Wed, 20 Feb 2019 10:34:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/ctNUWeLHss0rLblK3MlSeoU6ge46pmht/wAgD6AnJ0=; b=jCsLpc3JIZCojTNIo3G32YnWEtBVZ9RcGJKgSpSckZctF7d9M44dPtB+5MmVkahoW7 9xKUKCg1A0JZ0GkCo6tVOBsxhjlMjsEF9R7UvTqYJipWa6qX3BArnmGLxaBHMzxhh1KV QFqJG6fM1FtNVEe+QttYvMtftrc3Dhuc93VmHndkShjmjghdx0J+fpn9FUyEeURmkiwD oauQl77gpDBYe8Zlna26zb26VPB29CTu5pDqayqhEAvNzEGDqxAuMZw0cXwIkJZd2zTV 31tlXFfdRa41lr6TgFdbj+UtMHRAF/nAUVO1qsumpdp44jtB1a2K74/SmwRcne8ZGOM3 9XUA== 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=/ctNUWeLHss0rLblK3MlSeoU6ge46pmht/wAgD6AnJ0=; b=MP+CDayZc5w9YPVTa+FtjOXsWG9EUYbQQ1E01AA2vb27gEQx+LDkZxZlIIgsd45EMI Kd+cBmsKDGeyIP9GaMA3X0rfYU0EDdgHfVdwYLdUp3gBRXDA2MtuFHWr5t34ZJuUnm31 iK6aLmDw+KLxj2KnLlzc5rDSFGh/M3YSUbT5E4HUiy26NOaVIh9qH8eKykYHX/yRun5s S0zff8kpoHEmGtyyGZA0UYPCyvmUYZbOB23SZK7vYCf9rasgSO8dteIv+byUwa3Sv5ZU iDexus4Pic8uhmUJjbWPMCwzGbYdaYEZde+JpIHBElE4vsrEpZET4zCUoYmcKOb5M5Jk D6SQ== X-Gm-Message-State: AHQUAuYnyHiI8BAAXRgiqXLgsXmbC9OPLJEP+FUO8kpB/P+bc4sUYcT3 X4YNLl/wurkSzmgaJ8hcl+0YsjmweIgYVznR25fdeg== X-Google-Smtp-Source: AHgI3IZGALNsBL9IUo3IDQarnctfcjTXIxKHrYhhjTM9OcYumGzsWFKA1ZgGl6r+NUqu8hb5VQZpQt01KsUwN0zk63I= X-Received: by 2002:a19:5611:: with SMTP id k17mr20311831lfb.168.1550687697539; Wed, 20 Feb 2019 10:34:57 -0800 (PST) MIME-Version: 1.0 References: <20190220110629.21646-1-daniel@iogearbox.net> <20190220170723.bbcj7bipsa6r7oy6@ast-mbp> <15b7c010-0635-35e4-dac8-0d811a496cd7@iogearbox.net> In-Reply-To: <15b7c010-0635-35e4-dac8-0d811a496cd7@iogearbox.net> From: Alexei Starovoitov Date: Wed, 20 Feb 2019 10:34:45 -0800 Message-ID: Subject: Re: [PATCH bpf-next] bpf, seccomp: fix false positive preemption splat for cbpf->ebpf progs To: Daniel Borkmann Cc: Alexei Starovoitov , Network Development Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Feb 20, 2019 at 10:27 AM Daniel Borkmann wrote: > > On 02/20/2019 06:07 PM, Alexei Starovoitov wrote: > > On Wed, Feb 20, 2019 at 12:06:29PM +0100, Daniel Borkmann wrote: > >> In 568f196756ad ("bpf: check that BPF programs run with preemption disabled") > >> a check was added for BPF_PROG_RUN() that for every invocation preemption has > >> to be disabled to not break eBPF assumptions (e.g. per-cpu map). Of course this > >> does not count for seccomp because only cBPF -> eBPF is loaded here and it does > >> not make use of any functionality that would require this assertion. Fix this > >> false positive by adding and using __BPF_PROG_RUN() variant that does not have > >> the cant_sleep(); check. > >> > >> Fixes: 568f196756ad ("bpf: check that BPF programs run with preemption disabled") > >> Reported-by: syzbot+8bf19ee2aa580de7a2a7@syzkaller.appspotmail.com > >> Signed-off-by: Daniel Borkmann > >> --- > >> include/linux/filter.h | 9 ++++++++- > >> kernel/seccomp.c | 2 +- > >> 2 files changed, 9 insertions(+), 2 deletions(-) > >> > >> diff --git a/include/linux/filter.h b/include/linux/filter.h > >> index f32b3ec..2648fd7 100644 > >> --- a/include/linux/filter.h > >> +++ b/include/linux/filter.h > >> @@ -533,7 +533,14 @@ struct sk_filter { > >> struct bpf_prog *prog; > >> }; > >> > >> -#define BPF_PROG_RUN(filter, ctx) ({ cant_sleep(); (*(filter)->bpf_func)(ctx, (filter)->insnsi); }) > >> +#define bpf_prog_run__non_preempt(prog, ctx) \ > >> + ({ cant_sleep(); __BPF_PROG_RUN(prog, ctx); }) > >> +/* Native eBPF or cBPF -> eBPF transitions. Preemption must be disabled. */ > >> +#define BPF_PROG_RUN(prog, ctx) \ > >> + bpf_prog_run__non_preempt(prog, ctx) > >> +/* Direct use for cBPF -> eBPF only, but not for native eBPF. */ > > > > I think the comment is too abstract. > > May be it should say that this is seccomp cBPF only ? > > And macro name should be explicit as well ? > > I think macro naming is probably okay imho as used internally as > well from BPF_PROG_RUN(), but I'll improve the comment to state > seccomp specifically as an example there and providing some more > background. I'm worried about misuse of the macro. If there was a word seccomp in it it would made people think much harder before calling it.