netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roberto Sassu <roberto.sassu@huawei.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	KP Singh <kpsingh@kernel.org>, bpf <bpf@vger.kernel.org>,
	Network Development <netdev@vger.kernel.org>,
	"open list:KERNEL SELFTEST FRAMEWORK" 
	<linux-kselftest@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v2 2/3] selftests/bpf: Add test_progs opts for sign-file and kernel priv key + cert
Date: Thu, 9 Jun 2022 09:00:10 +0000	[thread overview]
Message-ID: <92d8b9c08e20449782f19f64cc3ec5fa@huawei.com> (raw)
In-Reply-To: <CAADnVQJ4RCSAeDMqFpF5bQznPQaTWFr=kL7GdssDQuzLof06fg@mail.gmail.com>

> From: Alexei Starovoitov [mailto:alexei.starovoitov@gmail.com]
> Sent: Thursday, June 9, 2022 2:13 AM
> On Wed, Jun 8, 2022 at 4:15 AM Roberto Sassu <roberto.sassu@huawei.com>
> wrote:
> >
> > According to the logs of the eBPF CI, built kernel and tests are copied to
> > a virtual machine to run there.
> >
> > Since a test for a new helper to verify PKCS#7 signatures requires to sign
> > data to be verified, extend test_progs to store in the test_env data
> > structure (accessible by individual tests) the path of sign-file and of the
> > kernel private key and cert.
> >
> > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> > ---
> >  tools/testing/selftests/bpf/test_progs.c | 12 ++++++++++++
> >  tools/testing/selftests/bpf/test_progs.h |  3 +++
> >  2 files changed, 15 insertions(+)
> >
> > diff --git a/tools/testing/selftests/bpf/test_progs.c
> b/tools/testing/selftests/bpf/test_progs.c
> > index c639f2e56fc5..90ce2c06a15e 100644
> > --- a/tools/testing/selftests/bpf/test_progs.c
> > +++ b/tools/testing/selftests/bpf/test_progs.c
> > @@ -707,6 +707,8 @@ enum ARG_KEYS {
> >         ARG_TEST_NAME_GLOB_DENYLIST = 'd',
> >         ARG_NUM_WORKERS = 'j',
> >         ARG_DEBUG = -1,
> > +       ARG_SIGN_FILE = 'S',
> > +       ARG_KERNEL_PRIV_CERT = 'C',
> >  };
> >
> >  static const struct argp_option opts[] = {
> > @@ -732,6 +734,10 @@ static const struct argp_option opts[] = {
> >           "Number of workers to run in parallel, default to number of cpus." },
> >         { "debug", ARG_DEBUG, NULL, 0,
> >           "print extra debug information for test_progs." },
> > +       { "sign-file", ARG_SIGN_FILE, "PATH", 0,
> > +         "sign-file path " },
> > +       { "kernel-priv-cert", ARG_KERNEL_PRIV_CERT, "PATH", 0,
> > +         "kernel private key and cert path " },
> >         {},
> >  };
> >
> > @@ -862,6 +868,12 @@ static error_t parse_arg(int key, char *arg, struct
> argp_state *state)
> >         case ARG_DEBUG:
> >                 env->debug = true;
> >                 break;
> > +       case ARG_SIGN_FILE:
> > +               env->sign_file_path = arg;
> > +               break;
> > +       case ARG_KERNEL_PRIV_CERT:
> > +               env->kernel_priv_cert_path = arg;
> > +               break;
> 
> That's cumbersome approach to use to force CI and
> users to pass these args on command line.
> The test has to be self contained.
> test_progs should execute it without any additional input.
> For example by having test-only private/public key
> that is used to sign and verify the signature.

I thought a bit about this. Just generating a test key does not work,
as it must be signed by the kernel signing key (otherwise, loading
in the secondary keyring will be rejected). Having the test key around
is as dangerous as having the kernel signing key around copied
somewhere.

Allowing users to specify a test keyring in the helper is possible.
But it would introduce unnecessary code, plus the keyring identifier
will be understood by eBPF only and not by verify_pkcs7_signature(),
as it happens for other keyring identifiers.

We may have environment variables directly in the eBPF test, to
specify the location of the signing key, but there is a risk of
duplication, as other tests wanting the same information might
not be aware of them.

I would not introduce any code that handles the kernel signing
key (in the Makefile, or in a separate script). This information is
so sensible, that it must be responsibility of an external party
to do the work of making that key available and tell where it is.

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Yang Xi, Li He

  reply	other threads:[~2022-06-09  9:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-08 11:12 [PATCH v2 0/3] bpf: Add bpf_verify_pkcs7_signature() helper Roberto Sassu
2022-06-08 11:12 ` [PATCH v2 1/3] " Roberto Sassu
2022-06-08 14:43   ` Daniel Borkmann
2022-06-08 14:44     ` KP Singh
2022-06-08 15:13       ` Roberto Sassu
2022-06-08 15:09     ` Roberto Sassu
2022-06-08 14:48   ` kernel test robot
2022-06-08 11:12 ` [PATCH v2 2/3] selftests/bpf: Add test_progs opts for sign-file and kernel priv key + cert Roberto Sassu
2022-06-09  0:12   ` Alexei Starovoitov
2022-06-09  9:00     ` Roberto Sassu [this message]
2022-06-09 15:38       ` Alexei Starovoitov
2022-06-10 12:10         ` Roberto Sassu
2022-06-08 11:12 ` [PATCH v2 3/3] selftests/bpf: Add test for bpf_verify_pkcs7_signature() helper Roberto Sassu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=92d8b9c08e20449782f19f64cc3ec5fa@huawei.com \
    --to=roberto.sassu@huawei.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).