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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2084BC433F5 for ; Mon, 14 Feb 2022 20:31:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 92E836B0075; Mon, 14 Feb 2022 15:31:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8DBE96B007B; Mon, 14 Feb 2022 15:31:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A5236B007D; Mon, 14 Feb 2022 15:31:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0019.hostedemail.com [216.40.44.19]) by kanga.kvack.org (Postfix) with ESMTP id 6C1F76B0075 for ; Mon, 14 Feb 2022 15:31:05 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 37705A309E for ; Mon, 14 Feb 2022 20:31:05 +0000 (UTC) X-FDA: 79142529690.18.BDC5206 Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) by imf29.hostedemail.com (Postfix) with ESMTP id ABBE912000B for ; Mon, 14 Feb 2022 20:31:04 +0000 (UTC) Received: by mail-lf1-f49.google.com with SMTP id g39so9723137lfv.10 for ; Mon, 14 Feb 2022 12:31:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uV1vHLzIr83T8MOCn12tMQAgRRvl8B7jglczOSl4CII=; b=JVRzXzobglXSiT0bLuA7vSr1HiJLXJeQF0BO276l66RCTCZjx8953KmFOVPMErrs0l on/NKX4mjsS9TS9bqhorHzBzM+OjtKgBLqdNoyLvrA639t1A433SV7/dJ5dxrhaCdPXH bTp5UzrLKiAt8Y3WQUfvdICLgLXk8cVAfLq1E= 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=uV1vHLzIr83T8MOCn12tMQAgRRvl8B7jglczOSl4CII=; b=k7uPCsNiv65USPRwtd3BaXwOK02QYx/h/fXsX9h7DrJVFOSCy1CFKYqA+FO6G1n/9S uuJ6zZftPQiflEyspD/JmLitcgjTPKZamMWB71dBV4rMd9/E3rVdGILzEENapNB0Ixix jRS+ALx8kjS1a50c9e5p/zXIglQDZKjyz7bbELPuUVd0L6GZ7+WtX9jEoT73+55HGX2N WaTjYLV9FvYYYJW6gXjCWbn3Ragu/EqpVMHOIYeO9ezjdrBfoOFVFwh346PnSVxva+gV uBBprn52XcXjruki+9LeV6xHA6aYKENWOigNFVHGT9kxCrMiPfSl1K1HQsm2VtFZ5Acx mMEg== X-Gm-Message-State: AOAM5337niefsZpuGw6Ap0UyKSiBdJFCus89/FH1+qlSp7MmXm9n+kVz JIL4Xy9+2Pu5txBgLvqC0GCXqpluD9lFuVAzCOI= X-Google-Smtp-Source: ABdhPJzarBE//v6UwzPJ/rHTOAPL9pvG7BGRMdPv7wHuZ+dW5uoFN20Q8BPtXbwpilzv4Kh6iaxbug== X-Received: by 2002:a05:6512:3f87:: with SMTP id x7mr612130lfa.54.1644870662883; Mon, 14 Feb 2022 12:31:02 -0800 (PST) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com. [209.85.208.175]) by smtp.gmail.com with ESMTPSA id e14sm1039117lfs.146.2022.02.14.12.31.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Feb 2022 12:31:02 -0800 (PST) Received: by mail-lj1-f175.google.com with SMTP id d2so1565952ljl.1 for ; Mon, 14 Feb 2022 12:31:02 -0800 (PST) X-Received: by 2002:a05:651c:1543:: with SMTP id y3mr306548ljp.152.1644870269711; Mon, 14 Feb 2022 12:24:29 -0800 (PST) MIME-Version: 1.0 References: <20220214163452.1568807-1-arnd@kernel.org> <20220214163452.1568807-5-arnd@kernel.org> In-Reply-To: From: Linus Torvalds Date: Mon, 14 Feb 2022 12:24:13 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 04/14] x86: use more conventional access_ok() definition To: Arnd Bergmann Cc: Christoph Hellwig , Christoph Hellwig , linux-arch , Linux-MM , Linux API , Arnd Bergmann , Linux Kernel Mailing List , Mark Rutland , Rich Felker , linux-ia64@vger.kernel.org, Linux-sh list , Peter Zijlstra , Max Filippov , Guo Ren , sparclinux , "open list:QUALCOMM HEXAGON..." , linux-riscv , Will Deacon , Ard Biesheuvel , linux-s390 , Brian Cain , Helge Deller , "the arch/x86 maintainers" , Russell King - ARM Linux , linux-csky@vger.kernel.org, Ingo Molnar , Geert Uytterhoeven , "open list:SYNOPSYS ARC ARCHITECTURE" , "open list:TENSILICA XTENSA PORT (xtensa)" , Heiko Carstens , alpha , linux-um , linux-m68k , Openrisc , Greentime Hu , Stafford Horne , Linux ARM , Michal Simek , Thomas Bogendoerfer , Parisc List , Nick Hu , "open list:BROADCOM NVRAM DRIVER" , Dinh Nguyen , "Eric W . Biederman" , Richard Weinberger , Andrew Morton , linuxppc-dev , David Miller , Al Viro Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: ABBE912000B X-Stat-Signature: 3sr5rio1izwr6uhna1mzhb3f8pzoi5bn Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=JVRzXzob; spf=pass (imf29.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.49 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-HE-Tag: 1644870664-877390 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Feb 14, 2022 at 12:01 PM Linus Torvalds wrote: > > x86-64 has always(*) used TASK_SIZE_MAX for access_ok(), and the > get_user() assembler implementation does the same. Side note: we could just check the sign bit instead, and avoid big constants that way. Right now we actually have this complexity in the x86-64 user access code: #ifdef CONFIG_X86_5LEVEL #define LOAD_TASK_SIZE_MINUS_N(n) \ ALTERNATIVE __stringify(mov $((1 << 47) - 4096 - (n)),%rdx), \ __stringify(mov $((1 << 56) - 4096 - (n)),%rdx), X86_FEATURE_LA57 #else #define LOAD_TASK_SIZE_MINUS_N(n) \ mov $(TASK_SIZE_MAX - (n)),%_ASM_DX #endif just because the code tries to get that TASK_SIZE_MAX boundary just right. And getting that boundary just right is important on 32-bit x86, but it's *much* less important on x86-64. There's still a (weak) reason to do it even for 64-bit code: page faults outside the valid user space range don't actually cause a #PF fault - they cause #GP - and then we have the #GP handler warn about "this address hasn't been checked". Which is nice and useful for doing syzbot kind of randomization loads (ie user accesses that didn't go through access_ok() will stand out nicely), but maybe it's not worth this. syzbot would be fine with only the "sign bit set" case warning for the same thing. So on x86-64, we could just check the sign of the address instead, and simplify and shrink those get/put_user() code sequences (but array_index_mask_nospec() currently uses the carry flag computation too, so we'd have to change that part as well, maybe not worth it). Linus