Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp4522537rwn; Sun, 11 Sep 2022 14:18:03 -0700 (PDT) X-Google-Smtp-Source: AA6agR5IGLOvti0xUfv5O9iK7PuNj11enstIEFp6MIiwith18a7oLpKjq2HmsCCzqlrH6RyAE49Q X-Received: by 2002:aa7:c448:0:b0:44f:c01:2fdb with SMTP id n8-20020aa7c448000000b0044f0c012fdbmr19197306edr.88.1662931083534; Sun, 11 Sep 2022 14:18:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662931083; cv=none; d=google.com; s=arc-20160816; b=zDEAaCSYqUCa62XvK78QwL4epugwbHSF1R03zhFpSz+vkz72wvXZuX1jNMlzYX9TxV RJgUsD021uQUCywlnaXlqXyUcmk49e+XSpV3Qmy1lMB+mxl5oO1zDWJaq6MSymssIcQv GbsJSvFS/rcIeIA46W56Wb8YYBeDuza7QX3xqGAHOPff0iJ5At3Oad8XrnNv/CwAwkhM IoHVlApMuyBfXjkA3A6pYBBT84jMcJxxjZIUZt+hiAk1Me/qsIgAjiSdUKv1Wb4B0zvJ 2GbzHBmoRKf4Quy2K1rnKBpYpaIrcITjGPZCFbGhir6MEFgPrWn7BJ3Lnem/BkGr1i3R 5Jug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=dfaSYpOE7cAlOB6lgtNwix6VkGo4PGRDDhlfC3pQXWo=; b=ui95QKXtbGVzkC5KezxDpsJyaAfHpnN5Sn3Twwm/7TytCmyZ99QTNc+TlDAUsdPEGr bSlXx8gSaT1cZpIlpq7EAd+yF4vhrU8yZRBKNfRGKeu36kTJIIket1lwv6wVtHG7FV0Q F3hixUTr/2MpUJRFnbF+Un2k7GpmrK5G2w8FNlqw2MW2Gx8vM/aQJCFRLbnFOtoIWqp0 mGC+d45KDvydjZJ+i7QTDznBcuqfsVvVo+yuNT0MLIVhwxYO+3ayCf3wGbPm5O0aJxTR UmMfSH42VTIu+kTN1WUEZjaAZVxdHQx/Xn4Xu4Xv/hL+X0LM4ydIhLCIwlQAhgV4mK8m ELgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=AY+k6a14; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h34-20020a0564020ea200b0045081dc93easi5081459eda.143.2022.09.11.14.17.38; Sun, 11 Sep 2022 14:18:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=AY+k6a14; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229658AbiIKVIr (ORCPT + 99 others); Sun, 11 Sep 2022 17:08:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55386 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229492AbiIKVIp (ORCPT ); Sun, 11 Sep 2022 17:08:45 -0400 Received: from mail-il1-x141.google.com (mail-il1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B5CDD25C5A; Sun, 11 Sep 2022 14:08:43 -0700 (PDT) Received: by mail-il1-x141.google.com with SMTP id d16so3627433ils.8; Sun, 11 Sep 2022 14:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=dfaSYpOE7cAlOB6lgtNwix6VkGo4PGRDDhlfC3pQXWo=; b=AY+k6a14ANY3j3WHkVqabrzmv706Harc72VI8vN2U1iSDb2xmFmsWTeAMgf9EPOr/Y qSxPhKKd/qVF2g85ofZfa7HVvdCL+Z0qpaXYHfs6dOppeL5xeYM5FYwlHlOBVCzQKy/s IjtrvpJm4ytCo2B/OBUFBejsYwjrDQN8MVTBSYIsti6B2jHp0D9HotWkqsGd230MxWup BGeqiKGV/WPIRdnpuD/Js7ckW0MPzZZ2V6QEqHWUyq94JprSVvd0oK3y7arQSddCoGQ0 UVETagiQTnshmmGjzQP4zc90DYOMYmDJKJP9uHrZoz2Pm6tNkKbFbmSD/ESK7Xir0frn PJAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=dfaSYpOE7cAlOB6lgtNwix6VkGo4PGRDDhlfC3pQXWo=; b=yltU7UiczH0W4QAPyFEjJEcf9QnlQEG1ajcuera3Tt20w2psXyxQf60km1lNXdDncO kVGBADnoY0mkm0u1YQsihGwzZaazPc80boukJ5WXFWuj+xnp0aqtG25iIRc64LI9ZG2C wahZGanE4NJ5eP4eNZ2KMFQSjacTlpAR9s38W0tnGtKpF3PlgHsovLO5JH6NVNUW0CB9 QQlZxfw1aBkZaLu7pZ9tGy90A4MbLytAMbBKnxdWWykrs/KPcv7IkQJDY3Ll/1tl5aoE dUkapr6Px6JAq9SUGagz868ZVeQhW7AVR5IWCUHwEeGeqtHzv2qA/VbKaquVJGIJyNoJ sWPA== X-Gm-Message-State: ACgBeo1MJcI77LNAdC/TRdIOO+5uFe4XtVusK1tW2Ru7TQMQZtGBpjz5 FkBIK+AVv8DqRqjWVCNZu10b2O/YRY1h/gN9fP4= X-Received: by 2002:a92:cbcf:0:b0:2f3:b515:92d with SMTP id s15-20020a92cbcf000000b002f3b515092dmr2755976ilq.91.1662930522984; Sun, 11 Sep 2022 14:08:42 -0700 (PDT) MIME-Version: 1.0 References: <20220909120736.1027040-1-roberto.sassu@huaweicloud.com> <20220909120736.1027040-8-roberto.sassu@huaweicloud.com> In-Reply-To: From: Kumar Kartikeya Dwivedi Date: Sun, 11 Sep 2022 23:08:05 +0200 Message-ID: Subject: Re: [PATCH v17 07/12] bpf: Add bpf_verify_pkcs7_signature() kfunc To: KP Singh Cc: Roberto Sassu , ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yhs@fb.com, john.fastabend@gmail.com, sdf@google.com, haoluo@google.com, jolsa@kernel.org, mykolal@fb.com, dhowells@redhat.com, jarkko@kernel.org, rostedt@goodmis.org, mingo@redhat.com, paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com, shuah@kernel.org, bpf@vger.kernel.org, keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, deso@posteo.net, Roberto Sassu Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 11 Sept 2022 at 13:41, KP Singh wrote: > > On Fri, Sep 9, 2022 at 2:09 PM Roberto Sassu > wrote: > > > > From: Roberto Sassu > > > > Add the bpf_verify_pkcs7_signature() kfunc, to give eBPF security modules > > the ability to check the validity of a signature against supplied data, by > > using user-provided or system-provided keys as trust anchor. > > > > The new kfunc makes it possible to enforce mandatory policies, as eBPF > > programs might be allowed to make security decisions only based on data > > sources the system administrator approves. > > > > The caller should provide the data to be verified and the signature as eBPF > > dynamic pointers (to minimize the number of parameters) and a bpf_key > > structure containing a reference to the keyring with keys trusted for > > signature verification, obtained from bpf_lookup_user_key() or > > bpf_lookup_system_key(). > > > > For bpf_key structures obtained from the former lookup function, > > bpf_verify_pkcs7_signature() completes the permission check deferred by > > that function by calling key_validate(). key_task_permission() is already > > called by the PKCS#7 code. > > > > Signed-off-by: Roberto Sassu > > Acked-by: KP Singh > > --- > > kernel/trace/bpf_trace.c | 45 ++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 45 insertions(+) > > > > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c > > index ab183dbaa8d1..9df53c40cffd 100644 > > --- a/kernel/trace/bpf_trace.c > > +++ b/kernel/trace/bpf_trace.c > > @@ -1294,12 +1294,57 @@ void bpf_key_put(struct bpf_key *bkey) > > kfree(bkey); > > } > > > > +#ifdef CONFIG_SYSTEM_DATA_VERIFICATION > > +/** > > + * bpf_verify_pkcs7_signature - verify a PKCS#7 signature > > + * @data_ptr: data to verify > > + * @sig_ptr: signature of the data > > + * @trusted_keyring: keyring with keys trusted for signature verification > > + * > > + * Verify the PKCS#7 signature *sig_ptr* against the supplied *data_ptr* > > + * with keys in a keyring referenced by *trusted_keyring*. > > + * > > + * Return: 0 on success, a negative value on error. > > + */ > > +int bpf_verify_pkcs7_signature(struct bpf_dynptr_kern *data_ptr, > > + struct bpf_dynptr_kern *sig_ptr, > > + struct bpf_key *trusted_keyring) > > +{ > > + int ret; > > + > > + if (trusted_keyring->has_ref) { > > + /* > > + * Do the permission check deferred in bpf_lookup_user_key(). > > + * See bpf_lookup_user_key() for more details. > > + * > > + * A call to key_task_permission() here would be redundant, as > > + * it is already done by keyring_search() called by > > + * find_asymmetric_key(). > > + */ > > + ret = key_validate(trusted_keyring->key); > > + if (ret < 0) > > + return ret; > > + } > > + > > + return verify_pkcs7_signature(data_ptr->data, > > + bpf_dynptr_get_size(data_ptr), > > + sig_ptr->data, > > + bpf_dynptr_get_size(sig_ptr), > > + trusted_keyring->key, > > + VERIFYING_UNSPECIFIED_SIGNATURE, NULL, > > + NULL); > > +} > > This seems to work if the data that needs to be verified > and the signature is allocated onto the map. > > For BPF program signing, the signature will be void * pointer (and length) > in a struct in the kernel > > +++ b/include/uapi/linux/bpf.h > @@ -1383,6 +1383,8 @@ union bpf_attr { > __aligned_u64 fd_array; /* array of FDs */ > __aligned_u64 core_relos; > __u32 core_relo_rec_size; /* sizeof(struct > bpf_core_relo) */ > + __aligned_u64 signature; > + __u32 signature_size; > }; > > Something like this in the bpf_prog_aux struct which is passed to > security_bpf_prog_alloc. > > Now creating a dynptr to use with this kfunc does not work: > > bpf_dynptr_from_mem(aux->signature, aux->signature_size, 0, &sig_ptr); > > So one has to copy kernel data into a map and then create dynptrs. > Would you be able to update > the dynptr logic to handle this case too? (follow up is okay too). > ISTM it needs the feature first before it can be added. To make it work like map_val, value_size(which is a constant) to pass to bpf_dynptr_from_mem, verifier will have to mark load of aux->signature as PTR_TO_MEM with the known constant size, and then mark_reg_known for scalar reg for aux->signature_size. Since we need to know that 0 <= r2 <= r1.mem_size. This would require some work on the btf_struct_access handling. It cannot be made to work in the general case of void * and len. There might also be other better options (like kernel itself preparing read only bpf_dynptr struct in bpf_prog_aux for the signature) so you can pass its address directly to the kfunc.