Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp849067pxf; Thu, 25 Mar 2021 15:46:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz7zL198j0IlCSjDLM3UWugbwDLWI1KnU4mzFHBYF5qa+IseMIKRAFxBgT5pQng0zFwq3ew X-Received: by 2002:a17:906:b1d4:: with SMTP id bv20mr12198169ejb.46.1616712409361; Thu, 25 Mar 2021 15:46:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616712409; cv=none; d=google.com; s=arc-20160816; b=IcEe2L1Eu3LkfWDpDfd7TWV0hWs5PaqXOt2N7B2zF8U+JHDSTRHmkLUt/dF8UDG4gF Uzo0QEAIGzszmjuXtf31ufB/VJMchNQeloYxc/pUck5B/NpXOsqYujhJ0luhgJNcm0Nc IKkA46rjwNDXSN+QxypeHbia5M2TjAF508+qvErqCY1BEUHBfQAjZUHCwzhMScr4t9ZX ZsuZD3XM4ujVL+GnmC6tf/t+FJAQnaeR7sk34Jg/5LB3EGufcKXZfeT5vi+g+M1qKXES mWX3ggGPtN9OuzvpBncQAMQHGLT5w5MtfQ1jJUS1V76+k0Ieouy9s0eC8B35XcM1uqEU q83Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=i1A3B1VA5Zv5sBwoUoS9WZiP910FQdZZhnQVANdwB9c=; b=BfDKQmS1kZTPVOD4oXUkjdfnAF9yb7X5ij7ZaYDmuzI1vlbdh7kJDqa6DQbrUpjgMu XLN0h2Agntoh6yNeuA83LBXE2N5bpBQnvXunWA9ZxwkOD/dHku83JhmrR7Bxaxm0QF3W t1CLynLo336Tz1GfofAqREfZADCoApbjjof7AXrmpj5ucoKlUbA/pySFKkXaiGrwIx5z JBz6tEoovGX1KQCvgJZDhBMooK0DywpkiETkc5k/Y38I9GERfbw/GsS+El5qjvFQd4nf nOw9YyKKFXti68Gsc2Zmh1AuQX5SbXOacTpHjt9e4LMbL2Ts7xLA8CFGdfDyScJsLq5b 5Kvg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@axtens.net header.s=google header.b=IicXkfu1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id go41si5552105ejc.135.2021.03.25.15.46.26; Thu, 25 Mar 2021 15:46:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@axtens.net header.s=google header.b=IicXkfu1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230285AbhCYWpd (ORCPT + 99 others); Thu, 25 Mar 2021 18:45:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45644 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230461AbhCYWo7 (ORCPT ); Thu, 25 Mar 2021 18:44:59 -0400 Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 197FDC06174A for ; Thu, 25 Mar 2021 15:44:59 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id v3so3297951pgq.2 for ; Thu, 25 Mar 2021 15:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=i1A3B1VA5Zv5sBwoUoS9WZiP910FQdZZhnQVANdwB9c=; b=IicXkfu18EISqV5ydhu56kRQMXqHpoRlop4C6BcDh/WNhGYMdJzZ/j9kZAfuPT4BQ/ npjBX182kJUDvhCs3A14H6ZmbO6bikVoZBMzyFhHP3JHmK2ypCwwuYKXo48N26dOflJz sF9QIO5+3JINV4A5ZlwLXVEoUJCE0XxMhc7Us= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=i1A3B1VA5Zv5sBwoUoS9WZiP910FQdZZhnQVANdwB9c=; b=glC0DbWMcYwnKn9WseV6QIgHX1e8Rf3PPTvlgoHp88kab36rVxHHuvlh0RMoyLMKRH g0pZ+Nvb5wJJrh7Y+p6679mvwpfbFJCRep3B187qT97rH6OWEwdMjxJqeWsaqXr0kMH+ BX9kmK+7PANVTUT4lZ9kXEElxYG1gmqOa+xJ2cxNiv9ef7WLVadx0VUOpQ7F80yXHvcH AqzRiDrNx9G5qrcjU2vEqLnczcBX8z5M+l/eBTKL/JM/RL7zsrfAOXpDYeWyiBMPck18 MEVWsOkad4IdAxwH+4ceka/MIoNix/YzWtfLU2b9xjrgbyOWP6reuA350dLWDYVgKoWc UNRw== X-Gm-Message-State: AOAM5339EQ1HUdAxDL0AYyfycjOCVJOWnKve44TGcxlFugwnHgNIynqX ohZV6H0amq4TmkBc+LkTtvuiXA== X-Received: by 2002:a17:902:da81:b029:e5:de44:af5b with SMTP id j1-20020a170902da81b02900e5de44af5bmr12069109plx.27.1616712298559; Thu, 25 Mar 2021 15:44:58 -0700 (PDT) Received: from localhost (2001-44b8-111e-5c00-5199-f2bf-3cbb-22e6.static.ipv6.internode.on.net. [2001:44b8:111e:5c00:5199:f2bf:3cbb:22e6]) by smtp.gmail.com with ESMTPSA id o20sm4304026pjs.2.2021.03.25.15.44.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Mar 2021 15:44:58 -0700 (PDT) From: Daniel Axtens To: Christophe Leroy , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v2 07/15] powerpc/uaccess: Call might_fault() inconditionaly In-Reply-To: <874kgykgfk.fsf@dja-thinkpad.axtens.net> References: <874kgykgfk.fsf@dja-thinkpad.axtens.net> Date: Fri, 26 Mar 2021 09:44:54 +1100 Message-ID: <871rc2kg49.fsf@dja-thinkpad.axtens.net> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Daniel Axtens writes: > Hi Christophe, > >> Commit 6bfd93c32a50 ("powerpc: Fix incorrect might_sleep in >> __get_user/__put_user on kernel addresses") added a check to not call >> might_sleep() on kernel addresses. This was to enable the use of >> __get_user() in the alignment exception handler for any address. >> >> Then commit 95156f0051cb ("lockdep, mm: fix might_fault() annotation") >> added a check of the address space in might_fault(), based on >> set_fs() logic. But this didn't solve the powerpc alignment exception >> case as it didn't call set_fs(KERNEL_DS). >> >> Nowadays, set_fs() is gone, previous patch fixed the alignment >> exception handler and __get_user/__put_user are not supposed to be >> used anymore to read kernel memory. >> >> Therefore the is_kernel_addr() check has become useless and can be >> removed. > > While I agree that __get_user/__put_user should not be used on kernel > memory, I'm not sure that we have covered every case where they might be > used on kernel memory yet. I did a git grep for __get_user - there are > several callers in arch/powerpc and it looks like at least lib/sstep.c > might be using __get_user to read kernel memory while single-stepping. > > I am not sure if might_sleep has got logic to cover the powerpc case - > it uses uaccess_kernel, but we don't supply a definition for that on > powerpc, so if we do end up calling __get_user on a kernel address, I > think we might now throw a warning. (Unless we are saved by > pagefault_disabled()?) Ah, I just re-read some of my earlier emails and was reminded that yes, if we are calling __get/put, we must have disabled page faults. So yes, this is good. > > (But I haven't tested this yet, so it's possible I misunderstood > something.) > > Do you expect any consequences if we've missed a case where > __(get|put)_user is called on a kernel address because it hasn't been > converted to use better helpers yet? > > Kind regards, > Daniel > >> >> Signed-off-by: Christophe Leroy >> --- >> arch/powerpc/include/asm/uaccess.h | 9 ++++----- >> 1 file changed, 4 insertions(+), 5 deletions(-) >> >> diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h >> index eaa828a6a419..c4bbc64758a0 100644 >> --- a/arch/powerpc/include/asm/uaccess.h >> +++ b/arch/powerpc/include/asm/uaccess.h >> @@ -77,8 +77,7 @@ __pu_failed: \ >> __typeof__(*(ptr)) __pu_val = (x); \ >> __typeof__(size) __pu_size = (size); \ >> \ >> - if (!is_kernel_addr((unsigned long)__pu_addr)) \ >> - might_fault(); \ >> + might_fault(); \ >> __chk_user_ptr(__pu_addr); \ >> __put_user_size(__pu_val, __pu_addr, __pu_size, __pu_err); \ >> \ >> @@ -238,12 +237,12 @@ do { \ >> __typeof__(size) __gu_size = (size); \ >> \ >> __chk_user_ptr(__gu_addr); \ >> - if (do_allow && !is_kernel_addr((unsigned long)__gu_addr)) \ >> + if (do_allow) { \ >> might_fault(); \ >> - if (do_allow) \ >> __get_user_size(__gu_val, __gu_addr, __gu_size, __gu_err); \ >> - else \ >> + } else { \ >> __get_user_size_allowed(__gu_val, __gu_addr, __gu_size, __gu_err); \ >> + } \ One microscopic nit: these changes throw the '\'s further out of alignment. Reviewed-by: Daniel Axtens Kind regards, Daniel >> (x) = (__typeof__(*(ptr)))__gu_val; \ >> \ >> __gu_err; \ >> -- >> 2.25.0