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 00E94C32793 for ; Wed, 18 Jan 2023 15:59:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8CE3D6B0072; Wed, 18 Jan 2023 10:59:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 87E9A6B0073; Wed, 18 Jan 2023 10:59:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 746496B0074; Wed, 18 Jan 2023 10:59:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 65C4A6B0072 for ; Wed, 18 Jan 2023 10:59:42 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 34108C0C43 for ; Wed, 18 Jan 2023 15:59:42 +0000 (UTC) X-FDA: 80368380204.08.C6FEB75 Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) by imf19.hostedemail.com (Postfix) with ESMTP id 3620D1A0007 for ; Wed, 18 Jan 2023 15:59:40 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=PdMtFWv6; dmarc=none; spf=pass (imf19.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.217.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674057580; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=yMnfiDl90nDMp75zhCoCphPVt5I3scvrOc1ITYVkfYQ=; b=me62fAt/z+4TLScntzvVXXtEA3T2sYZlrUrEF5br20whwWINpKaK1BMEFV2uJ6eRQ5ES7l b1egMiKWtKi07nXRuJWc7TarMgyDOgfEKFJF9y7GLShTNLbwHYkJxzIxxuCQL1PtmU0rgi 8qVJPK86deyAY+w5qpqdeabwAQb/aNQ= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=PdMtFWv6; dmarc=none; spf=pass (imf19.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.217.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674057580; a=rsa-sha256; cv=none; b=usrvnxchkziY9nXtgBO3lH+mu9/Br2RR1Wf+npVvnxYqAmlqPBljqRTUUPjCDpWT90zvXB YROU21J2k+r7jvILBOVaVzzlfeK8pzYsL7o41u/vRpdoEnvJLYw+ZMf6pyAJk9z4xgepEh NL4cF4d6vnAVyelN7EWjjB5kGj7caVg= Received: by mail-vs1-f53.google.com with SMTP id v127so31813920vsb.12 for ; Wed, 18 Jan 2023 07:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yMnfiDl90nDMp75zhCoCphPVt5I3scvrOc1ITYVkfYQ=; b=PdMtFWv6YOkJKhAG4gLjZhgFPo65DsYbGhXsa3xdtPIKBIPTic0rHcEQ3CdiRbooys MtFyqsMqZIIgHuIoVgVIVuT6YoFxNTQ2CcVt6GhEwOcXD09vu8nJ2n4BB6fo3/kBhPt2 JxhySlSm6v/yV+rqY6m/f6nNkvkEhQaiHRo6M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yMnfiDl90nDMp75zhCoCphPVt5I3scvrOc1ITYVkfYQ=; b=GfuDeG28MkN68U4omsYCkINGC39aWVc716McR09x7BMQzSTsacx/S+twUFdEjguttq wbNtZHBcAxqMXdLiuwHOs68u+JLRj0GckzGco520vHT36ohZbq+Y+PRuUchRkbgwRCAX tWlLOvNWP+BVgK5d2g8n1oibxObxeLZ3Q8Dq4yjlBiY6yT+gA5SuBpq5mJ2IvHAc6o2L riN7aIxzTk94QDfcM05MvUwJTlhPiu9idzAOpp25VGCRhDepr0iHQln5O8+wWR5i536t psZBPziEcrPjJVCvEs1IQ2NK15Iw8iWifWui2DNZACW84MTg0or0eCRQtUD2jqm2GPXu euwQ== X-Gm-Message-State: AFqh2kpMUazfxsQx9PKvu8gfA+uaxSDHmb1d3cF+2IFm8N6aMwMY4eXl Fgw0jPoA/bORN0yyZ5THTGtlo1UGUmXOWXTD X-Google-Smtp-Source: AMrXdXtve6UStHDhuE5WG+XUK7Kuh+XgWZYu0SK+Z3oh8d61RDjFlXVzv+5kG2bIDE7o/ZlZ56C8GQ== X-Received: by 2002:a67:f447:0:b0:3d3:c531:d3ae with SMTP id r7-20020a67f447000000b003d3c531d3aemr8817876vsn.1.1674057578841; Wed, 18 Jan 2023 07:59:38 -0800 (PST) Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com. [209.85.222.176]) by smtp.gmail.com with ESMTPSA id bs15-20020a05620a470f00b006b61b2cb1d2sm22666369qkb.46.2023.01.18.07.59.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Jan 2023 07:59:38 -0800 (PST) Received: by mail-qk1-f176.google.com with SMTP id pa22so18187999qkn.9 for ; Wed, 18 Jan 2023 07:59:38 -0800 (PST) X-Received: by 2002:a37:6387:0:b0:706:92f4:125 with SMTP id x129-20020a376387000000b0070692f40125mr423230qkb.72.1674057577814; Wed, 18 Jan 2023 07:59:37 -0800 (PST) MIME-Version: 1.0 References: <20230111123736.20025-1-kirill.shutemov@linux.intel.com> <20230111123736.20025-2-kirill.shutemov@linux.intel.com> In-Reply-To: From: Linus Torvalds Date: Wed, 18 Jan 2023 07:59:21 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCHv14 01/17] x86/mm: Rework address range check in get_user() and put_user() To: Peter Zijlstra Cc: "Kirill A. Shutemov" , Dave Hansen , Andy Lutomirski , x86@kernel.org, Kostya Serebryany , Andrey Ryabinin , Andrey Konovalov , Alexander Potapenko , Taras Madan , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , Bharata B Rao , Jacob Pan , Ashok Raj , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 3620D1A0007 X-Stat-Signature: zuxcmpreoqjyp7yqes7da977j3buperh X-HE-Tag: 1674057580-675595 X-HE-Meta: U2FsdGVkX1+Vv8sOjB9JrbV5ZhuyirY5qzqUvxT9D7A+935eIwSdUk/AjFwbVUlUvc7rJYcsbcowWMoT602y/K7QlnAymPFuCUB5Oe3ORU/yIimJYO/RMIrmqWjghTzqrACy5niYx2XiRg1EgB0YCZaYF6OouyPUo/hMEkpF1fJVWLxxxSKLpcXZJtaBaPWSuWHV+22HVfYfEaXfPLdDo7ptjSfwranjQm0UUXxoO8QOUwklwI9uXGHFHvNpkZFM8v7d5hVCpk34SZRpm3ruNSqErncimS3KpEGxAW3UAm9DS/BPLHmk5Uh4WLWcVO3F+WDL4A5lgh1/tiL5SNQ2WV9zPB9eUpevkniGyXKGAhZ8us/DnTE23HmB8w72eBC4zc1jVomdjc0FLEX/a5bz+HQdCVTW5nbf+dXbThi4b8oRhPOJRCgUqtE8dLYd7gSa4bAyUbZOOT5m3Q4ngEbK4lI1LUGJyTnUdOt+GmxwWRRsIvHXQ363TH+cI/krynFODfftBscjCso2kztE6f6SDRTm0W3eCBQVYhwfZBIMBYb64t0swKWuHCBymSySRxWQ6qLWdTtTuxcg0/kjvD6rY9H4oSJFM1IgpAcngaOUR66lxXFzsI8+g6zTYVWpR9dapF9qU601X4Em5tuio8MfpqtHLGKPNm9OVJ6lGf9SGm9FOzy4TDjJf1ESnstDGHqelNGOBjh1dqpmYcHxzEi/Ov0oVtCUIFofAwJaNyKP0yQFkIeMxoVQQBaOQHkRbIGo0DjBGfEVX/Een91LfQ07sawbZGEBwUHp8luhVrCoRd+LC9tuXPBqq7aGsqGjbFeUjyEvW+lQug80faFcmqXeImHH4nidkTeDd9yKtUNOvckFe2VORTm2f6n4YHzXhtKcMlBymt3+aJmd7ALHrAk9/oCytnbv+6x1sEylyTk6rJYlJJFPSG5+0EM4j2INdgm6wXQ4PbAUqKaEApKS3vM aScevSt2 OgFEdYdTFAUSScTmHG53qAEPT9NIyW/G9Vm4iuZBak3lewbJZ7ZDzo0s7nW1i4UJfI1CbbYNx1mgDxFh8v+8dpE81tfFom6emsFSxY1ybcOfSoMBVkUvZp++H3aa5eEIc4FRmrhEjIqTZit4mkVj1h7g15DHkxfQE3udQl8VziNFcRb34U/uN8xClKWUYHFL6n9X4grRNamReNWJZBZrYMgsHeF1G474YNbtB10o09SQpb2yqUWNkpWMQepagrWCxLSAxWNMfMAoZqkmMFBUdsvIcZ1pvsqgjHZjLu06hMfvtMtpNr+ukCz3ol92K8T20UkSVnucp3brihXFVOGOB+s+U4/zyNPM8CLy9UYxrMzjm8fdVIfcZdqbY6S0WGWSKEBu2Kc3tvN0Hpa7NAYi83fcIFg== 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 Wed, Jan 18, 2023 at 7:50 AM Peter Zijlstra wrote: > > On Wed, Jan 11, 2023 at 03:37:20PM +0300, Kirill A. Shutemov wrote: > > > If an address with bit 63 set is passed down, it will trigger a #GP > > exception. _ASM_EXTABLE_UA() complains about this. Replace it with > > plain _ASM_EXTABLE() as it is expected behaviour now. > > here I don't. The new logic basically squishes every kernel address to > -1L -- a known unmapped address, but getting that address in > {get,put}_user() is still a fail, right? > > We used to manually branch to bad_get_user when outside TASK_SIZE_MAX, > now we rely on #GP. > > So why silence it? We don't silence it - for a kernel address that turns into an all-ones address, the the _ASM_EXTABLE() will still cause the -EFAULT due to the page fault. But it's not the high bit set case that is the problem here. The problem is a "positive" address that is non-canonical. Testing against TASK_SIZE_MAX would catch non-canonical addresses before the access, and we'd return -EFAULT. But now that we don't test against TASK_SIZE_MAX any more, non-canonical accesses will cause a GP fault, and *that* message is what we want to silence. We'll still return -EFAULT, of course, we're just getting rid of the WARN_ONCE(trapnr == X86_TRAP_GP, "General protection fault in user access. Non-canonical address?"); issue that comes from not being so exact about the address limit any more. Linus