Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp3388324imw; Mon, 18 Jul 2022 07:16:12 -0700 (PDT) X-Google-Smtp-Source: AGRyM1s33Utj2sgKkBcu8426Vry063p+gcl0Z8uD+5Wxrwus5q4nl474n/iOR3Abxqdzb3SUrbIR X-Received: by 2002:a17:906:4fc5:b0:72b:9943:6f10 with SMTP id i5-20020a1709064fc500b0072b99436f10mr26237480ejw.722.1658153772541; Mon, 18 Jul 2022 07:16:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658153772; cv=none; d=google.com; s=arc-20160816; b=Ki16cN0YDYlbaz15D/516fbA+LlI20gbEmrFblNJBVaL9CDvqwQ+8nANsyazCVvcWR 3gb5pH/Fh1jc4fIy4F9h2FWyDyeHA2x5q3qMQu+oKKrzTuko9n4EyuJnDZfnN7ObJbvX /HlENEfXMBqJZv5kjk6h2xLsG5f8Ave8v+tX0sHHDEdPthUz2C3Mx9Z5P/F/4PrSvmh/ Dp7+ZAVigDIhkpxbBliRwMXVddbTKWyr2OsnVL/bMGZraPxcc9c4vDe7c10KbEZ77Bqm 7kRAN/SD1/wdKW3U0J9qykEZiOla5jnFD672eJ3H/Lu0kgRmyvv2h7SKA7dbcUxwFWhG G9OA== 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=Pc2COzK5DZ3zqU+q9ucYylkxH5lyMmFL6dLIwCvbYD4=; b=YE9VJDEhkQtTy4KTqafv9UWDT1GQ4vBrfF5pkW6SlgD6AKO9EMPn91dONCFJj9D8jl txnnfCLIMToXYC+EK3YWK0FJYPe4NWSXyx8/f6LO2oOKvc8IT4Ti4APll0ttkCC34Lwc iltF9U27C9Q1gmXtaVBOneeSYIEquV9k80ECmGyEyJvObMHCu+/LmHaG/D2aJUm/DNpP ekDGWJQBVnebDS2a7r9q2uYGhiOCd9y60W/DXsVSPBlNRrIMGqkIh/1aIdSANcghMnmy Xw/gTIju+qfo7BRG9ldSykkTc9gL6eSLJqkmRIm6oyxQ1NhMBIFFU+dmbFCyE4LnxOFi /6lA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="HhxY/UJB"; 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=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t12-20020aa7d4cc000000b0043ad1d1d68asi13663592edr.335.2022.07.18.07.15.48; Mon, 18 Jul 2022 07:16:12 -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=@redhat.com header.s=mimecast20190719 header.b="HhxY/UJB"; 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=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234507AbiGRNy2 (ORCPT + 99 others); Mon, 18 Jul 2022 09:54:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52200 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235585AbiGRNyL (ORCPT ); Mon, 18 Jul 2022 09:54:11 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id B2462111B for ; Mon, 18 Jul 2022 06:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1658152448; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Pc2COzK5DZ3zqU+q9ucYylkxH5lyMmFL6dLIwCvbYD4=; b=HhxY/UJBH40yzhzTYYnaF98mhZEX2zFZuuKHl0w0Tw0x7F1K7CBnhmuWHhIdhpz/WSDIK1 rl7w1WuA86v8TCJfQf8TQcJi9VL0B5/HgySqNImSpiXysFbF98vgLQ5b/a7pbDSziC4P5r b+N/Wad3RFBQCikJfFZLaUFGsn8ErgU= Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-204-T4XC-JeAOECPjj_j3NtowQ-1; Mon, 18 Jul 2022 09:54:07 -0400 X-MC-Unique: T4XC-JeAOECPjj_j3NtowQ-1 Received: by mail-pf1-f198.google.com with SMTP id j9-20020aa78009000000b0052b5ccdf6b8so495096pfi.6 for ; Mon, 18 Jul 2022 06:54:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Pc2COzK5DZ3zqU+q9ucYylkxH5lyMmFL6dLIwCvbYD4=; b=RLv4cCsV2FeajFGI2NW7jAHefSR8bl/ROfv4cKsL2bGRslFFQ9VXdOT1Kwj9DKTPk0 Ioa7t3Hywf6v2i3ePfFam8hse648kgkkCUW8jVmJBBKiEi5xi50q4cDaq+27HC7BEzNR 0s8OmpR7zStRQtsfifo6vcb3qfcgocBRIK7Nl9wNfu/QlNX2dko2htsZod8nycHSpECq MvFZB83RdLaXR4+MXiXgpWkBuu4+YM5nOPz2vu2tnc9UKvuL7JM+gwAZEFqueZmyzSDn kaF7mwjVyp92460jHCVJBizpWTlEARLugRfkmBU0piRVFUqVQQGI/epKJlM1vl6jIWhv uTHg== X-Gm-Message-State: AJIora96PRhuW7FYkxa+kvDeYcc4J+hqQ4qGp3coh7EIOHNro9APzYq+ qigrHWW049kE+TYvWRgejNonc2UXhKzo2OZeLzV9mYLu70usHn8RdG/+ErQEe2PgsxSuEpKIKHB IB/HLRUCkcJhia0Wyqdmz5INaj/qAcEDDS89irTHK X-Received: by 2002:a17:90b:3c0c:b0:1ef:e647:ff48 with SMTP id pb12-20020a17090b3c0c00b001efe647ff48mr38420249pjb.173.1658152446341; Mon, 18 Jul 2022 06:54:06 -0700 (PDT) X-Received: by 2002:a17:90b:3c0c:b0:1ef:e647:ff48 with SMTP id pb12-20020a17090b3c0c00b001efe647ff48mr38420212pjb.173.1658152446035; Mon, 18 Jul 2022 06:54:06 -0700 (PDT) MIME-Version: 1.0 References: <20220712145850.599666-1-benjamin.tissoires@redhat.com> <20220712145850.599666-3-benjamin.tissoires@redhat.com> In-Reply-To: From: Benjamin Tissoires Date: Mon, 18 Jul 2022 15:53:55 +0200 Message-ID: Subject: Re: [PATCH bpf-next v6 02/23] bpf/verifier: allow kfunc to read user provided context To: Kumar Kartikeya Dwivedi Cc: Greg KH , Jiri Kosina , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Shuah Khan , Dave Marchevsky , Joe Stringer , Jonathan Corbet , Tero Kristo , lkml , "open list:HID CORE LAYER" , Networking , bpf , "open list:KERNEL SELFTEST FRAMEWORK" , Linux Doc Mailing List Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_NONE 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 Sat, Jul 16, 2022 at 9:48 PM Kumar Kartikeya Dwivedi wrote: > > On Tue, 12 Jul 2022 at 17:02, Benjamin Tissoires > wrote: > > > > When a kfunc was trying to access data from context in a syscall eBPF > > program, the verifier was rejecting the call. > > This is because the syscall context is not known at compile time, and > > so we need to check this when actually accessing it. > > > > Check for the valid memory access and allow such situation to happen. > > > > Signed-off-by: Benjamin Tissoires > > > > --- > > > > new in v6 > > --- > > kernel/bpf/verifier.c | 16 ++++++++++++++++ > > 1 file changed, 16 insertions(+) > > > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c > > index 328cfab3af60..f6af57a84247 100644 > > --- a/kernel/bpf/verifier.c > > +++ b/kernel/bpf/verifier.c > > @@ -248,6 +248,7 @@ struct bpf_call_arg_meta { > > struct bpf_map *map_ptr; > > bool raw_mode; > > bool pkt_access; > > + bool is_kfunc; > > u8 release_regno; > > int regno; > > int access_size; > > @@ -5170,6 +5171,7 @@ static int check_helper_mem_access(struct bpf_verifier_env *env, int regno, > > struct bpf_call_arg_meta *meta) > > { > > struct bpf_reg_state *regs = cur_regs(env), *reg = ®s[regno]; > > + enum bpf_prog_type prog_type = resolve_prog_type(env->prog); > > u32 *max_access; > > > > switch (base_type(reg->type)) { > > @@ -5223,6 +5225,19 @@ static int check_helper_mem_access(struct bpf_verifier_env *env, int regno, > > env, > > regno, reg->off, access_size, > > zero_size_allowed, ACCESS_HELPER, meta); > > + case PTR_TO_CTX: > > + /* in case of a kfunc called in a program of type SYSCALL, the context is > > + * user supplied, so not computed statically. > > + * Dynamically check it now > > + */ > > + if (prog_type == BPF_PROG_TYPE_SYSCALL && meta && meta->is_kfunc) { > > + enum bpf_access_type access_t = meta->raw_mode ? BPF_WRITE : BPF_READ; > > small nit: _t suffix is used for types, so you could probably rename > this. maybe atype? Ack, fixed locally. > > > + > > + return check_mem_access(env, env->insn_idx, regno, access_size, BPF_B, > > + access_t, -1, false); > > If I read the code correctly, this makes the max_ctx_offset of prog > access_size + 1 (off + size_to_bytes(BPF_B)), which is 1 more than the > actual size being accessed. Oh, correct. I am mixing offset and access_size, which creates this :( > > This also messes up check_helper_mem_access when it allows NULL, 0 > pair to pass (because check is against actual size + 1). We do allow > passing NULL when size is 0 for kfuncs (see zero_size_allowed is true I am a little bit confused by how check_mem_size_reg() treats the case when reg->umin_value == 0. What does it mean to call check_helper_mem_access() with a 0 size if we have zero_size_allowed? Can I just have in the PTR_TO_CTX case: "if (access_size == 0) return zero_size_allowed ? 0 : -EINVAL;" or should I only allow the call if the ptr in the register is null? > in check_mem_size_reg), so your hid_hw_request function is missing > that NULL check for buf too. Actually, in hid_hw_request() we ensure buf__sz is greater than 1, so buf can not be null. But I agree it doesn't hurt to have that extra check to be sure (we are called from a syscall program, so not time sensitive). > > In the selftest that checks for failure in loading > + bpf_kfunc_call_test_mem_len_pass1(&args->data, sizeof(*args) + 1); > so it will still fail with just sizeof(*args). Good point. > > Also please add coverage for this case in the next version. I added both (NULL, 0) and (&args->data, sizeof(*args)) as passing tests locally. And thanks for the review! Cheers, Benjamin > > > + } > > + > > + fallthrough; > > default: /* scalar_value or invalid ptr */ > > /* Allow zero-byte read from NULL, regardless of pointer type */ > > if (zero_size_allowed && access_size == 0 && > > @@ -5335,6 +5350,7 @@ int check_kfunc_mem_size_reg(struct bpf_verifier_env *env, struct bpf_reg_state > > WARN_ON_ONCE(regno < BPF_REG_2 || regno > BPF_REG_5); > > > > memset(&meta, 0, sizeof(meta)); > > + meta.is_kfunc = true; > > > > if (may_be_null) { > > saved_reg = *mem_reg; > > -- > > 2.36.1 > > >