Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp3878064pxb; Fri, 11 Feb 2022 09:40:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJyHbSwyvCsVlkk8u2BSxcTCfH6AecqXSeO8khLlTdDd5wzPFBa5cHZJvNIOeKmPFjEO7qDQ X-Received: by 2002:a17:902:bd03:: with SMTP id p3mr2665319pls.50.1644601256194; Fri, 11 Feb 2022 09:40:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644601256; cv=none; d=google.com; s=arc-20160816; b=kW/4OybKJHBkcgKXqdwaebyGKT870kADujkLwppFzEHdjUAZBskNKik3h/dmSPM+u3 HYJVEhskgoboENVPXKK/gPpkEiJoUP/f6rRfG7eaM+9x3gS0IGHicKP87XEYDkhZHEiO urR9KsCsASqVaCydjVW2U5D4tFcbVZw8KYRJYTUVSxSDaKR96w/nTTg4EC6C++uLwY+P KPorDhpQQWnMo8x4SegsZxevDjjOj5k0+OUCkJlvjzzgSYyU3R9LGKWj2FkhV5llociP LLXdGYkGkVBJVVeEwsBmeOV1LEuIuqL3cHOdosV23jbfm4YknvRiGJAiqHMleepeA/i1 jJhQ== 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=777AJh9xQzR3MbnpZrZYCdyEQ0EqjVSbQlq2y8Dd1a4=; b=V3yDt6o+qkLgqXrf0de8Q9F+sWYan8lUiOcC1NhFUrwTt0UZ1Jo1jWpzPgL7F0ntHV q61pv7WfKLKEeezD41Ca2EwV3BJtkHaHOWpDxvZOhNLITN+viGfqhSfJN9HlLwqc7tIw /3wxGU+C8PfGnkoaBk6wwLVnB+mYlo8jlEd7xVUAebjbCyNAgbVAIX4EoKA4uHcTM/vu zPadw1TlgQCoHPalYKPgu6tsl8MGwM4xvQ4mRdSM2mSOcW6csmSXC58oAuxIIKxw6B0l jC8RU+MyFsEkptKf68NIv9eexaCMPUwrf/84aaiikAxm64vQAulIgV5N3hZDXvHwXFbq XZFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=H2i2UGLj; 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=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z5si5186998plo.13.2022.02.11.09.40.41; Fri, 11 Feb 2022 09:40:56 -0800 (PST) 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=@kernel.org header.s=k20201202 header.b=H2i2UGLj; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242226AbiBJNaU (ORCPT + 99 others); Thu, 10 Feb 2022 08:30:20 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:56798 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240857AbiBJNaS (ORCPT ); Thu, 10 Feb 2022 08:30:18 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B948CBC3 for ; Thu, 10 Feb 2022 05:30:19 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 70CF2B82542 for ; Thu, 10 Feb 2022 13:30:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D7F5C340EF for ; Thu, 10 Feb 2022 13:30:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1644499817; bh=D3YvW4DlVwpDo3QJDnNkz3ju1LQKDPPBLL8nBCf56KA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=H2i2UGLj02Xcjphvb+f4dgATUl3J8KGVdHunZml2kNZ1u2fVaqi3EkV3qpB2GLeqE HN2wtWgbJHWMixOAyYYMJpFrf+mUK7U6B0WvnAs1vs4V8xFxcdUq5QIXgcwEpPI8Es pgMS4XrnezCQg3t3U3iW6gsUstT3t+O9wMbr1lX1R8LOpWqvY7TtR73YjCNVigGjww CtwZr0k5ZSYRIijupBtXONQuNqipiJGFjDqRGTVNLassQDabErTyPHpjuNLoaRrv3P KNmj5Oxq2PL41bM/TkDGLpvo+HVMrpimDVR/ALs/Zyump2nK5AlntSw/us64Wq0wDV jW755tpRfPhUg== Received: by mail-wr1-f52.google.com with SMTP id v12so9646875wrv.2 for ; Thu, 10 Feb 2022 05:30:17 -0800 (PST) X-Gm-Message-State: AOAM531pbYed2WUoRyN5xLN8YCdM03oJtMQu16m9RZnnkS3Jx6dDG4JW t7bpITMHwuJ9HEhmGWwvfXPuHR1qCSOxq/mejao= X-Received: by 2002:a05:6000:3c6:: with SMTP id b6mr6255767wrg.12.1644499815448; Thu, 10 Feb 2022 05:30:15 -0800 (PST) MIME-Version: 1.0 References: <20220209144910.1484686-1-arnd@kernel.org> <80c6df0717014472aa81093ae3894d39@AcuMS.aculab.com> In-Reply-To: <80c6df0717014472aa81093ae3894d39@AcuMS.aculab.com> From: Arnd Bergmann Date: Thu, 10 Feb 2022 14:29:59 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] microblaze: remove CONFIG_SET_FS To: David Laight Cc: Michal Simek , Christoph Hellwig , Arnd Bergmann , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, 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 Thu, Feb 10, 2022 at 10:36 AM David Laight wrote: > From: Arnd Sent: 09 February 2022 14:49 > > > > Remove the address space override API set_fs(). The microblaze user > > address space is now limited to TASK_SIZE. > > > > To support this we implement and wire in __get_kernel_nofault and > > __set_kernel_nofault. > > > > The function user_addr_max is removed as there is a default definition > > provided when CONFIG_SET_FS is not used. > ... > > static inline int access_ok(const void __user *addr, unsigned long size) > > { > > if (!size) > > goto ok; > > > > - if ((get_fs().seg < ((unsigned long)addr)) || > > - (get_fs().seg < ((unsigned long)addr + size - 1))) { > > - pr_devel("ACCESS fail at 0x%08x (size 0x%x), seg 0x%08x\n", > > - (__force u32)addr, (u32)size, > > - (u32)get_fs().seg); > > + if ((((unsigned long)addr) > TASK_SIZE) || > > + (((unsigned long)addr + size - 1) > TASK_SIZE)) { > > + pr_devel("ACCESS fail at 0x%08x (size 0x%x)", > > + (__force u32)addr, (u32)size); > > return 0; > > Isn't that the wrong check? > If 'size' is big 'addr + size' can wrap. Ah right, that seems dangerous, and we should probably fix that first, with a backport to stable kernels before my patch. I see the same bug on csky and hexagon: static inline int __access_ok(unsigned long addr, unsigned long size) { unsigned long limit = current_thread_info()->addr_limit.seg; return ((addr < limit) && ((addr + size) < limit)); } #define __access_ok(addr, size) \ ((get_fs().seg == KERNEL_DS.seg) || \ (((unsigned long)addr < get_fs().seg) && \ (unsigned long)size < (get_fs().seg - (unsigned long)addr))) ia64 and sparc skip the size check entirely but rely on an unmapped page at the beginning of the kernel address range, which avoids this problem but may also be dangerous. m68k-coldfire-mmu has a comment about needing a check, but tests for neither address nor size. > It needs to be (addr >= TASK_SIZE || size > TASK_SIZE - addr) > > Which is pretty much a generic version. > Although typical 64bit architectures can use the faster: > ((addr | size) >> 62) I think this is the best version, and it's already widely used: static inline int __range_ok(unsigned long addr, unsigned long size) { return size <= TASK_SIZE && addr <= (TASK_SIZE - size); } since 'size' is usually constant, so this turns into a single comparison against a compile-time constant. Arnd