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.8 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_HELO_NONE,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 7F8CBC4360C for ; Tue, 8 Oct 2019 23:42:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5559821721 for ; Tue, 8 Oct 2019 23:42:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Apk8SrN/" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727051AbfJHXmD (ORCPT ); Tue, 8 Oct 2019 19:42:03 -0400 Received: from mail-qt1-f193.google.com ([209.85.160.193]:44664 "EHLO mail-qt1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726822AbfJHXmC (ORCPT ); Tue, 8 Oct 2019 19:42:02 -0400 Received: by mail-qt1-f193.google.com with SMTP id u40so716959qth.11; Tue, 08 Oct 2019 16:42:02 -0700 (PDT) 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=6HiVuuo2rZvDIOVhBACObN7eVlMYASXv5ByWnYJPHms=; b=Apk8SrN/aDgWVwvpPsca+YwWsR2qhEhxS2RFjArDN52HbeZCzq2bcrPhNByNhjA17K s4ygyBzYPVGO1uBbKemEhx0d4xQ1/ksmagvZohLmd9u1tatMONUkqm32FNOV+/oRgW1i 77gN8OunkvYy/4qY1v3oWJqjJ/MVg0bJqqbLfXFfeVkLduw9YHq8wfWRE+HfCH2/QS0+ z/4ga94LUHYT6CgWbmN2yASnbKHjcMKz6P6tK/TGIhbRcyVda2sAW94Km7u+6WwYNZ34 tgkSEQt0UBqCdM3p1p+pwE+23btA3KZFDX6BCxOGU/shuZWQztF4EGW5CNkHKD2jftXW liBg== 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=6HiVuuo2rZvDIOVhBACObN7eVlMYASXv5ByWnYJPHms=; b=Yk3TscfGMFvW8I4iHefcW5MrU9OufRkrAtL0zMhPAnlTHgDZdKrN49p1pN07Pg9emO nmiXC4LPLT9n//B3/RebezBh/+U7aO/ODhsgnq70KO1al5cZyosnOOanDRd4MMtGBgT1 MRZBNa8c/Qdzzhh/RMrL/hETMZi80/P+rYfVioA5FSter00gXtTD0y2NdaDPHiX831At ySDk4BW1aBsxMWX0RwzrcdlR31bfswe1vL9yZ8lYy+lNGhjqis/eNOy2qgKOsrcsV6um AawpY45f7wwemOJTJya2RLlgUCLrZeFa1FGRai2U8Vo/3FDxay5iS8AiCPE7EwSuzO/w ZnrQ== X-Gm-Message-State: APjAAAXF8sGhG3KZ+xOGNX65AY5PzxjqZaUlXLjsXR/FskuNTZFazoRI VdOCDxYVoY7/C1ScRyAkT/8gUYy5YGEzd85iVV8= X-Google-Smtp-Source: APXvYqzoVqrm6m26F8VOzUBLXy/bvK5WFaruQMtVBkbo+3Re9cR0zVkVziTEMvFcuYFcfII3tsUppcacGxkxD3ysxs4= X-Received: by 2002:ac8:1c34:: with SMTP id a49mr580016qtk.59.1570578121660; Tue, 08 Oct 2019 16:42:01 -0700 (PDT) MIME-Version: 1.0 References: <20191008194548.2344473-1-andriin@fb.com> <20191008194548.2344473-2-andriin@fb.com> <20191008212945.GG27307@pc-66.home> In-Reply-To: <20191008212945.GG27307@pc-66.home> From: Andrii Nakryiko Date: Tue, 8 Oct 2019 16:41:50 -0700 Message-ID: Subject: Re: [PATCH bpf-next 1/2] bpf: track contents of read-only maps as scalars To: Daniel Borkmann Cc: Andrii Nakryiko , bpf , Networking , Alexei Starovoitov , Kernel Team Content-Type: text/plain; charset="UTF-8" Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Tue, Oct 8, 2019 at 2:29 PM Daniel Borkmann wrote: > > On Tue, Oct 08, 2019 at 12:45:47PM -0700, Andrii Nakryiko wrote: > > Maps that are read-only both from BPF program side and user space side > > have their contents constant, so verifier can track referenced values > > precisely and use that knowledge for dead code elimination, branch > > pruning, etc. This patch teaches BPF verifier how to do this. > > > > Signed-off-by: Andrii Nakryiko > > --- > > kernel/bpf/verifier.c | 58 +++++++++++++++++++++++++++++++++++++++++-- > > 1 file changed, 56 insertions(+), 2 deletions(-) > > > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > > index ffc3e53f5300..1e4e4bd64ca5 100644 > > --- a/kernel/bpf/verifier.c > > +++ b/kernel/bpf/verifier.c > > @@ -2739,6 +2739,42 @@ static void coerce_reg_to_size(struct bpf_reg_state *reg, int size) > > reg->smax_value = reg->umax_value; > > } > > > > +static bool bpf_map_is_rdonly(const struct bpf_map *map) > > +{ > > + return (map->map_flags & BPF_F_RDONLY_PROG) && > > + ((map->map_flags & BPF_F_RDONLY) || map->frozen); > > This is definitely buggy. Testing for 'map->map_flags & BPF_F_RDONLY' > to assume it's RO from user space side is not correct as it's just > related to the current fd, but not the map itself. So the second part > definitely /must/ only be: && map->frozen Yep, you are right, map->frozen and BPF_F_RDONLY_PROG only. > > Thanks, > Daniel