From patchwork Fri May 24 15:59:27 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?q?Iago_L=C3=B3pez_Galeiras?= X-Patchwork-Id: 1104986 Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=kinvolk.io Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=kinvolk.io header.i=@kinvolk.io header.b="Co9GxXET"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 459WKn74rWz9s3l for ; Sat, 25 May 2019 02:00:13 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390514AbfEXP7p (ORCPT ); Fri, 24 May 2019 11:59:45 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:39800 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390413AbfEXP7p (ORCPT ); Fri, 24 May 2019 11:59:45 -0400 Received: by mail-wr1-f68.google.com with SMTP id e2so1777417wrv.6 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=hrjhT4p2fLW4WOorxMQUr9sJ5M1X4vVddruogZRYupxkEcSxnoqq+vB9+BAEaypfns OpQNqPdfRZvqFfNGr0BOQ5itVFm4TCVPFGCVeAvtI38sHNJrHu1RuQpY9N+qL+IvLxCV cP88aGIeHfnsRb2r5DFDAZE6bhYDMMR+6hITLjAO/C18nudJue3eu8rdSBK8v/9nhH9k ASscxfExDJaBclfJimLKe/NH6V2SCEfn7yIseLUBRYKJrRvZv4C5y7addbIP4vyg7V/6 b21r6Ju91S3O4d8sTJkbeGy7zV9AbalsJOkLZuWkDkI8pauA/598GvQt9HH560xm8qxB +LIA== X-Gm-Message-State: APjAAAWcfMjYy5yVAX9pSkAmg4nAmeRihyeYE9GR4tilu82hCtZD+BJR XyRuIGn7nzj32SVxDGsyuc2lpA== 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_L=C3=B3pez_Galeiras?= 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_?= =?utf-8?q?L=C3=B3pez_Galeiras?= 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 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@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(-)