Received: by 2002:a05:7412:cfc7:b0:fc:a2b0:25d7 with SMTP id by7csp1459893rdb; Mon, 19 Feb 2024 17:23:35 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCWiFN3p7BmskBhY3DZKe4R3Xx2L0U0ZH4dfKrYvrmTUPb7hJ7Wv0TwRehV0R7GHwsRppzJS7YhUZLdcDg2WlnX7vaqtkQX0y9wWpvNklg== X-Google-Smtp-Source: AGHT+IFHOxB37FO7WxefFYFCH6cJ8ldpmxSLhUYOmWT8IShH7y4T7dlQbuthr2Ha0B2nqaCGo5TH X-Received: by 2002:a05:6402:12d3:b0:564:7d36:259d with SMTP id k19-20020a05640212d300b005647d36259dmr2720183edx.17.1708392215445; Mon, 19 Feb 2024 17:23:35 -0800 (PST) Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id x19-20020a05640226d300b0056447ebd7afsi2056303edd.1.2024.02.19.17.23.35 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Feb 2024 17:23:35 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-72178-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; arc=fail (body hash mismatch); spf=pass (google.com: domain of linux-kernel+bounces-72178-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-72178-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id C6D7E1F228FE for ; Tue, 20 Feb 2024 01:23:34 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B116125576; Tue, 20 Feb 2024 01:23:00 +0000 (UTC) Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A441D2375D; Tue, 20 Feb 2024 01:22:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=114.242.206.163 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708392180; cv=none; b=ScUhEOOIVbLTHiQ7en+6yVs16th82aArtSuQPUJaIK/Sdku5yDTTqR6qDqXhdhKmLjqx3JJRqpGao8dUwyY0aG1wIyb/ziilLQZq2XV+csZWt8zuVHMI4vfIU6nFWU4lno/UeCpIXgFVvY9JOcSbxQVlqUYjizl4zH/xomYbztk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708392180; c=relaxed/simple; bh=99PSqupxaWhciKD6PS2xAzi9+SnpFL6NS1UK09usFKg=; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=upDUv4b5RtFZL6jPGzTAxNbKnuktsHDvNvJVgjkWY0Gjdo3hWfOENamIlPTwLAxXzhmUuUXouFMm39jNVzpYOy8xek/bM7WPZFadRl52sLjDb6g4A/JQnjfZAIvpdUDulolfVx7susHChJgLvOamSrdQ7vexJiHVDVYN0vLoONE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=loongson.cn; spf=pass smtp.mailfrom=loongson.cn; arc=none smtp.client-ip=114.242.206.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=loongson.cn Received: from loongson.cn (unknown [113.200.148.30]) by gateway (Coremail) with SMTP id _____8Ax++ju_tNlFNMOAA--.19552S3; Tue, 20 Feb 2024 09:22:54 +0800 (CST) Received: from [10.130.0.149] (unknown [113.200.148.30]) by localhost.localdomain (Coremail) with SMTP id AQAAf8AxX8_l_tNlG2M8AA--.23719S3; Tue, 20 Feb 2024 09:22:46 +0800 (CST) Subject: Re: [PATCH bpf-next 2/2] bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro() To: Christophe Leroy , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Russell King , Puranjay Mohan , Zi Shen Lim , Catalin Marinas , Will Deacon , Hengqi Chen , Huacai Chen , WANG Xuerui , Johan Almbladh , Paul Burton , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Ilya Leoshkevich , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , "David S. Miller" , Andreas Larsson , Wang YanQing , David Ahern , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" References: <135feeafe6fe8d412e90865622e9601403c42be5.1708253445.git.christophe.leroy@csgroup.eu> Cc: bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linux-s390@vger.kernel.org, sparclinux@vger.kernel.org, netdev@vger.kernel.org, Kees Cook , "linux-hardening @ vger . kernel . org" From: Tiezhu Yang Message-ID: <326d7b90-614f-ec2d-e224-5d325c06a349@loongson.cn> Date: Tue, 20 Feb 2024 09:22:45 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID:AQAAf8AxX8_l_tNlG2M8AA--.23719S3 X-CM-SenderInfo: p1dqw3xlh2x3gn0dqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBj93XoWxWrW8GFy7ur13Jr17JrWxZrc_yoW5Aw17pF 9rZwnrCr4vgr4UWFsFk3WUXFZ3Z397Ka47urya9ryjg3Z0qF1kuayfKw1SgFW3ArWUXa18 Xa1vgryUuaykA3gCm3ZEXasCq-sJn29KB7ZKAUJUUUjx529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUPIb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1Y6r17M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv6xkF7I0E14v2 6r4j6r4UJwAaw2AFwI0_GFv_Wryle2I262IYc4CY6c8Ij28IcVAaY2xG8wAqjxCEc2xF0c Ia020Ex4CE44I27wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jw0_ WrylYx0Ex4A2jsIE14v26r4j6F4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrw CYjI0SjxkI62AI1cAE67vIY487MxkF7I0En4kS14v26rWY6Fy7MxAIw28IcxkI7VAKI48J MxC20s026xCaFVCjc4AY6r1j6r4UMxCIbckI1I0E14v26r4a6rW5MI8I3I0E5I8CrVAFwI 0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWrXVW8Jr1lIxkG c2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVW5JVW7JwCI42IY6xIIjxv20xvEc7CjxVAFwI 0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r4j6F4U MIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07b8YL9UUU UU= On 02/18/2024 06:55 PM, Christophe Leroy wrote: > set_memory_rox() can fail, leaving memory unprotected. > > Check return and bail out when bpf_jit_binary_lock_ro() returns > and error. > > Signed-off-by: Christophe Leroy > --- .. > diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c > index e73323d759d0..aafc5037fd2b 100644 > --- a/arch/loongarch/net/bpf_jit.c > +++ b/arch/loongarch/net/bpf_jit.c > @@ -1294,16 +1294,18 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog) > flush_icache_range((unsigned long)header, (unsigned long)(ctx.image + ctx.idx)); > > if (!prog->is_func || extra_pass) { > + int err; > + > if (extra_pass && ctx.idx != jit_data->ctx.idx) { > pr_err_once("multi-func JIT bug %d != %d\n", > ctx.idx, jit_data->ctx.idx); > - bpf_jit_binary_free(header); > - prog->bpf_func = NULL; > - prog->jited = 0; > - prog->jited_len = 0; > - goto out_offset; > + goto out_free; > + } > + err = bpf_jit_binary_lock_ro(header); > + if (err) { > + pr_err_once("bpf_jit_binary_lock_ro() returned %d\n", err); > + goto out_free; > } > - bpf_jit_binary_lock_ro(header); > } else { > jit_data->ctx = ctx; > jit_data->image = image_ptr; > @@ -1334,6 +1336,13 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog) > out_offset = -1; > > return prog; > + > +out_free: > + bpf_jit_binary_free(header); > + prog->bpf_func = NULL; > + prog->jited = 0; > + prog->jited_len = 0; > + goto out_offset; > } > > /* Indicate the JIT backend supports mixing bpf2bpf and tailcalls. */ .. > diff --git a/include/linux/filter.h b/include/linux/filter.h > index fc0994dc5c72..314414fa6d70 100644 > --- a/include/linux/filter.h > +++ b/include/linux/filter.h > @@ -892,10 +892,10 @@ static inline int __must_check bpf_prog_lock_ro(struct bpf_prog *fp) > return 0; > } > > -static inline void bpf_jit_binary_lock_ro(struct bpf_binary_header *hdr) > +static inline int __must_check bpf_jit_binary_lock_ro(struct bpf_binary_header *hdr) > { > set_vm_flush_reset_perms(hdr); > - set_memory_rox((unsigned long)hdr, hdr->size >> PAGE_SHIFT); > + return set_memory_rox((unsigned long)hdr, hdr->size >> PAGE_SHIFT); > } > > int sk_filter_trim_cap(struct sock *sk, struct sk_buff *skb, unsigned int cap); LoongArch does not select CONFIG_ARCH_HAS_SET_MEMORY, set_memory_ro() and set_memory_x() always return 0, then set_memory_rox() also returns 0, that is to say, bpf_jit_binary_lock_ro() will return 0, it seems that there is no obvious effect for LoongArch with this patch. But once CONFIG_ARCH_HAS_SET_MEMORY is selected and the arch-specified set_memory_*() functions are implemented in the future, it is necessary to handle the error cases. At least, in order to keep consistent with the other archs, the code itself looks good to me. Acked-by: Tiezhu Yang # LoongArch Thanks, Tiezhu