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=-3.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_GIT 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 CE2B2C072B5 for ; Fri, 24 May 2019 15:59:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A377A21848 for ; Fri, 24 May 2019 15:59:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kinvolk.io header.i=@kinvolk.io header.b="Co9GxXET" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390546AbfEXP7p (ORCPT ); Fri, 24 May 2019 11:59:45 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:44240 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390411AbfEXP7p (ORCPT ); Fri, 24 May 2019 11:59:45 -0400 Received: by mail-wr1-f67.google.com with SMTP id w13so2181052wru.11 for ; Fri, 24 May 2019 08:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kinvolk.io; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=HTU8ZvQGukDYiT1iBEhaciWthxQj5tSMJzxivJb2X1g=; b=Co9GxXET5rTh0Gix9SpGtQXpoW7PfAsPOzE4RvtRidzZoKoaH/7aXuFpxXZqijZTW5 VQpH43xlsRCoJpE3daQdOwG8owbA8EqUhSn/7bi+lnRdr5qbWDzXUo3qFT20Us01qhCy +OpZp4cOR2+U9YWVmhvXfDVQhLk8sgHXZ/OW8= 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:date:message-id:mime-version :content-transfer-encoding; bh=HTU8ZvQGukDYiT1iBEhaciWthxQj5tSMJzxivJb2X1g=; b=q6rEGiNgl5wU0rw5Pl+IQS7oURi81OWxIuotCOq1wnJ5j2eaM/52eA55cQRp2PrA2S L6e0F9zordp011h5ehA+s9dVTYUCa2izpJ9K55qp1uaNAXizNQ26Y94ZTlonzkoHrvCV 5A8Y2YzjouXJFkjdbezbFadAAAzD0tgAj+T5IUYP5qPtnPSz21Ye1l9dgvhFD3Ruihoo o96a2M707fTFfe4wRsN6HpTkkcFpBvso4kU4E51U6aoZbjCwAkt1MW5mOGOY9g1KnlZ9 +WSpLEvNurGni0TlkqfV6Gi9B36kqeSGLckvz4SlbKwBCo7nQQYfbEqHrhFf87ty+Oa8 zTBg== X-Gm-Message-State: APjAAAVFGyIGRahI1VGVONuu5eSxGVqe4bfKk25sfhG1U81+UpDM39Yi z+REHNrbWyL2GBGJYF/whWw+DQ== X-Google-Smtp-Source: APXvYqyA0nKVvtW4KzkZUeSSbuyLcKqJJfWlj5TiUYJ11BV86ItffK7JLzlBB5qMe/JE64Q0wWetkA== X-Received: by 2002:adf:e408:: with SMTP id g8mr31393993wrm.143.1558713583663; Fri, 24 May 2019 08:59:43 -0700 (PDT) Received: from locke-xps13.localdomain (69.pool85-58-237.dynamic.orange.es. [85.58.237.69]) by smtp.gmail.com with ESMTPSA id i185sm4535054wmg.32.2019.05.24.08.59.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 May 2019 08:59:42 -0700 (PDT) From: =?UTF-8?q?Iago=20L=C3=B3pez=20Galeiras?= To: john.fastabend@gmail.com, ast@kernel.org, daniel@iogearbox.net Cc: alban@kinvolk.io, krzesimir@kinvolk.io, bpf@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, =?UTF-8?q?Iago=20L=C3=B3pez=20Galeiras?= Subject: [PATCH bpf-next v4 0/4] sock ops: add netns ino and dev in bpf context Date: Fri, 24 May 2019 17:59:27 +0200 Message-Id: <20190524155931.7946-1-iago@kinvolk.io> X-Mailer: git-send-email 2.21.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I'm taking over Alban's work on this. This series allows sockops programs to access the network namespace inode and device via (struct bpf_sock_ops)->netns_ino and ->netns_dev. This can be useful to apply different policies on different network namespaces. In the unlikely case where network namespaces are not compiled in (CONFIG_NET_NS=n), the verifier will generate code to return netns_dev as usual and will return 0 for netns_ino. The generated BPF bytecode for netns_ino is loading the correct inode number at the time of execution. However, the generated BPF bytecode for netns_dev is loading an immediate value determined at BPF-load-time by looking at the initial network namespace. In practice, this works because all netns currently use the same virtual device. If this was to change, this code would need to be updated too. It also adds sockmap and verifier selftests to cover the new fields. Partial reads work thanks to commit e2f7fc0ac69 ("bpf: fix undefined behavior in narrow load handling"). v1 patchset can be found at: https://lkml.org/lkml/2019/4/12/238 Changes since v1: - add netns_dev (review from Alexei) - tools/include/uapi/linux/bpf.h: update with netns_dev - tools/testing/selftests/bpf/test_sockmap_kern.h: print debugs with - This is a new selftest (review from Song) v2 patchest can be found at: https://lkml.org/lkml/2019/4/18/685 Changes since v2: - replace __u64 by u64 in kernel code (review from Y Song) - remove unneeded #else branch: program would be rejected in is_valid_access (review from Y Song) - allow partial reads (netns* selftests: bpf: read netns_ino from struct bpf_sock_ops selftests: bpf: verifier: read netns_dev and netns_ino from struct bpf_sock_ops include/uapi/linux/bpf.h | 2 + net/core/filter.c | 70 +++++++++++++++++++ tools/include/uapi/linux/bpf.h | 2 + tools/testing/selftests/bpf/test_sockmap.c | 38 +++++++++- .../testing/selftests/bpf/test_sockmap_kern.h | 22 ++++++ .../testing/selftests/bpf/verifier/var_off.c | 53 ++++++++++++++ 6 files changed, 184 insertions(+), 3 deletions(-) -- 2.21.0