From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DCE9DC433E2 for ; Thu, 3 Sep 2020 21:30:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B0547206E7 for ; Thu, 3 Sep 2020 21:30:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728573AbgICVaU convert rfc822-to-8bit (ORCPT ); Thu, 3 Sep 2020 17:30:20 -0400 Received: from eu-smtp-delivery-151.mimecast.com ([207.82.80.151]:37876 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726323AbgICVaT (ORCPT ); Thu, 3 Sep 2020 17:30:19 -0400 Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-262-_4fCYuHMPVerwxIv1vLjVw-1; Thu, 03 Sep 2020 22:30:15 +0100 X-MC-Unique: _4fCYuHMPVerwxIv1vLjVw-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) by AcuMS.aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 3 Sep 2020 22:30:14 +0100 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Thu, 3 Sep 2020 22:30:14 +0100 From: David Laight To: 'Christoph Hellwig' , Linus Torvalds , Al Viro , "Michael Ellerman" , "x86@kernel.org" CC: Alexey Dobriyan , Luis Chamberlain , Kees Cook , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-arch@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" Subject: RE: [PATCH 12/14] x86: remove address space overrides using set_fs() Thread-Topic: [PATCH 12/14] x86: remove address space overrides using set_fs() Thread-Index: AQHWggEOyEQXa7QqyE6TJTq6U2S8aalXbNZg Date: Thu, 3 Sep 2020 21:30:14 +0000 Message-ID: <9ab40244a2164f7db2ff0c1d23ab59a0@AcuMS.aculab.com> References: <20200903142242.925828-1-hch@lst.de> <20200903142242.925828-13-hch@lst.de> In-Reply-To: <20200903142242.925828-13-hch@lst.de> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0.001 X-Mimecast-Originator: aculab.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Content-Language: en-US Sender: linux-arch-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org From: Christoph Hellwig > Sent: 03 September 2020 15:23 > > Stop providing the possibility to override the address space using > set_fs() now that there is no need for that any more. To properly > handle the TASK_SIZE_MAX checking for 4 vs 5-level page tables on > x86 a new alternative is introduced, which just like the one in > entry_64.S has to use the hardcoded virtual address bits to escape > the fact that TASK_SIZE_MAX isn't actually a constant when 5-level > page tables are enabled. Why does it matter whether 4 or 5 level page tables are in use? Surely all access_ok() needs to do is ensure that a valid kernel address isn't supplied. A non-canonical (is that the right term) address between the highest valid user address and the lowest valid kernel address (7ffe to fffe?) will fault anyway. So any limit between the valid user and kernel addresses should work? So a limit of 1<<63 would seem appropriate. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)