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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 339BDC04AB5 for ; Thu, 6 Jun 2019 13:49:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 115762070B for ; Thu, 6 Jun 2019 13:49:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728533AbfFFNtl convert rfc822-to-8bit (ORCPT ); Thu, 6 Jun 2019 09:49:41 -0400 Received: from mail-ed1-f65.google.com ([209.85.208.65]:37481 "EHLO mail-ed1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726014AbfFFNtk (ORCPT ); Thu, 6 Jun 2019 09:49:40 -0400 Received: by mail-ed1-f65.google.com with SMTP id w13so3461301eds.4 for ; Thu, 06 Jun 2019 06:49:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=j3i5guPNWte923XV713tdz8UcowwZRhCJspDF63SmmQ=; b=f4G1R30PbtGY6sgnfYKV+8FIMQZw+1QyyXn8Y4Lgp/WcUgA/DtCjIkBKclRa7lYzw3 F9eCLIgMYvMECUj3NNxXUR2XIol3ym4W0cMXjJ3vqURYsLdNPw83pPylhoD7DV3TM3bE FaWQzKTFfAwWA3ZzmNGvb/fvVcP70G+m6jlpUUETDRy/1QuSodMcPJU5kNvHswnKMPXa Hg6l8mddY86oF4UVUPiImeryayR4taq4qOqcEku/2F5D/AIC3gIfUuK8wGRoPIIsT/SC tPZomM8Ga1Wy3mY1btp4KTo8k3vUQo0OBnNIL1MGuvO32QkNIVuPrIpyV71hPOOAyTUe mkhA== X-Gm-Message-State: APjAAAX/wYpa3jABQFBj+Dil//Y4p4iiVx7LgfpPWXGj1ts8gJwB54d9 ndF4ZXymyIc0d8QgUnCz5DfjfA== X-Google-Smtp-Source: APXvYqxMyjUrS1kr3CkSn3LuoA7uatliZE1O5iz6J4GA3XsVvr/lAA9ZMEXvSj2Q6pfZcBTTfXE2BA== X-Received: by 2002:a17:906:b743:: with SMTP id fx3mr42181048ejb.208.1559828979194; Thu, 06 Jun 2019 06:49:39 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk (borgediget.toke.dk. [85.204.121.218]) by smtp.gmail.com with ESMTPSA id fj23sm354100ejb.47.2019.06.06.06.49.38 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 06 Jun 2019 06:49:38 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id BBC8C181CC1; Thu, 6 Jun 2019 15:49:37 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Jesper Dangaard Brouer Cc: David Miller , netdev@vger.kernel.org, Daniel Borkmann , Alexei Starovoitov , brouer@redhat.com Subject: Re: [PATCH net-next v2 2/2] devmap: Allow map lookups from eBPF In-Reply-To: <20190606153344.4871ffa2@carbon> References: <155982745450.30088.1132406322084580770.stgit@alrua-x1> <155982745466.30088.16226777266948206538.stgit@alrua-x1> <20190606153344.4871ffa2@carbon> X-Clacks-Overhead: GNU Terry Pratchett Date: Thu, 06 Jun 2019 15:49:37 +0200 Message-ID: <87zhmuddse.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Jesper Dangaard Brouer writes: > On Thu, 06 Jun 2019 15:24:14 +0200 > Toke Høiland-Jørgensen wrote: > >> From: Toke Høiland-Jørgensen >> >> We don't currently allow lookups into a devmap from eBPF, because the map >> lookup returns a pointer directly to the dev->ifindex, which shouldn't be >> modifiable from eBPF. >> >> However, being able to do lookups in devmaps is useful to know (e.g.) >> whether forwarding to a specific interface is enabled. Currently, programs >> work around this by keeping a shadow map of another type which indicates >> whether a map index is valid. >> >> Since we now have a flag to make maps read-only from the eBPF side, we can >> simply lift the lookup restriction if we make sure this flag is always set. > > Nice, I didn't know this was possible. I like it! :-) Me neither; discovered it while looking through the verifier code to figure out what would be needed to get the verifier to enforce read-only semantics. Not much, as it turned out :) The functionality was introduced in: 591fe9888d78 ("bpf: add program side {rd, wr}only support for maps") by Daniel from April 9th. -Toke