Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp595682ybl; Thu, 23 Jan 2020 04:32:17 -0800 (PST) X-Google-Smtp-Source: APXvYqwRZc9XNoVGDz3SrqP56BH57GdqhuCJ4pFuKmouNV9iI0vhE1uqq8lymnv8cEdWhXgdCsdK X-Received: by 2002:a9d:4b05:: with SMTP id q5mr10483538otf.174.1579782737762; Thu, 23 Jan 2020 04:32:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579782737; cv=none; d=google.com; s=arc-20160816; b=cSZdufLWSFBF8VRI6CD8nyZbboDEdclwFjBhZg5i/EgLWXEu/vrODzunpcnR+yqwIm 5kvFQtSarbeyiN6AjL1wqIrxAioVg1hZbwrhU/tGsX7zbGA+4C3w+VdH+nCrfepbBRyh W/GCWEaPh59cPzyhHMxx9YZ06ianCmzZJurxTJ0pIy5eDFkPUhEX4RTe5xdAbIyrnKUo U8GrnFUcUzeprMlILUwh2WxpR6KQvC4Y10iXnUWrGdAPu8KtBpleGdhLboLk3cXwTntR FoQUy2gshPG5bipC1v/ZCWHMNuR3Ur06cCHREZvJSSa2iCVbfrItgadZfk7HBZIgBgSh QTHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=b4MpKEjRTvgjrBpG1mY0CAMW101sh9q/TWnANcD0C+Y=; b=PQevngRZ1rJcdohmrxqzFWKapyFfAuMxZHhqm9ypmbI5SUReZ6t/PZacVu97e5K5/X GXnXoNqHEdhRw8TJu3MorKBQI+6VVRePFaT1mmY/yH44H37bW8eaj+t8R9cPkLcOE6n/ Dl8nmMOlTQ5G/oIg5l/GG48XdV3dJKqX3tDbTJGQTabBmejNHihc2y+nJn1+fBdFAVQP HQ/JW1mh311IoDW7tFwEZh/LKcjCCV5YIYKEDBPqryb2kjzQk44cpgUtEfiAFoxj5/EX Y352IG/Wb5DN/E+QxKqSLv0sD1Rbp4R2uvHWlsl4JFWgr2SACwphl7eszcHVZinvI8ca MMoA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ellerman.id.au header.s=201909 header.b=XcDFF1F6; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b9si826059oie.20.2020.01.23.04.32.05; Thu, 23 Jan 2020 04:32:17 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ellerman.id.au header.s=201909 header.b=XcDFF1F6; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728760AbgAWMbH (ORCPT + 99 others); Thu, 23 Jan 2020 07:31:07 -0500 Received: from bilbo.ozlabs.org ([203.11.71.1]:48401 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726260AbgAWMbG (ORCPT ); Thu, 23 Jan 2020 07:31:06 -0500 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 483M7r0bhgz9sSH; Thu, 23 Jan 2020 23:31:04 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ellerman.id.au; s=201909; t=1579782664; bh=vvHlt/x8yUKYf+nz2OV13dtkaSiK0JSgmAVt6B2ldwU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=XcDFF1F6y3fTk8tq1K8XQWrclXCC3LBJX5o7RCzFiNdgBW2TQ0S3QmB9AqGLHxrk9 2Mjirn0e1OnxQ5oedT0kG1SYJZFPYdacZ+mU4aUSTRZ7ULER+33hVi1FDJtisTetC0 s8ix3OdHy+NqsDBBHVmqpZR+YphcDFOhfMy5xUR7Tn2x0cjHgrWbJicQyEKzSYKM68 IW6GqA06/2gL7IrO6MWwCd/B9NVeCAWgmJnZfOZaEm1HK+sqo1LBQZQY8XNNGL8dky TVM9IaaQC1iIxowbHFjZdKrpwL297gUB5DF+isxN3rcEMAIkgADPk4M3Q1ZqGGnWED TvCrztQ+nOF/A== From: Michael Ellerman To: Christophe Leroy , Benjamin Herrenschmidt , Paul Mackerras Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 6/6] powerpc: Implement user_access_begin and friends In-Reply-To: <87iml2idi9.fsf@mpe.ellerman.id.au> References: <12a4be679e43de1eca6e5e2173163f27e2f25236.1579715466.git.christophe.leroy@c-s.fr> <2a20d19776faba4d85dbe51ae00a5f6ac5ac0969.1579715466.git.christophe.leroy@c-s.fr> <87iml2idi9.fsf@mpe.ellerman.id.au> Date: Thu, 23 Jan 2020 23:31:03 +1100 Message-ID: <87ftg6icc8.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Michael Ellerman writes: > Christophe Leroy writes: >> Today, when a function like strncpy_from_user() is called, >> the userspace access protection is de-activated and re-activated >> for every word read. >> >> By implementing user_access_begin and friends, the protection >> is de-activated at the beginning of the copy and re-activated at the >> end. >> >> Implement user_access_begin(), user_access_end() and >> unsafe_get_user(), unsafe_put_user() and unsafe_copy_to_user() >> >> For the time being, we keep user_access_save() and >> user_access_restore() as nops. > > That means we will run with user access enabled in a few more places, but > it's only used sparingly AFAICS: > > kernel/trace/trace_branch.c: unsigned long flags = user_access_save(); > lib/ubsan.c: unsigned long flags = user_access_save(); > lib/ubsan.c: unsigned long ua_flags = user_access_save(); > mm/kasan/common.c: unsigned long flags = user_access_save(); > > And we don't have objtool checking that user access enablement isn't > leaking in the first place, so I guess it's OK for us not to implement > these to begin with? It looks like we can implement them on on all three KUAP implementations. For radix and 8xx we just return/set the relevant SPR. For book3s/32/kup.h I think we'd just need to add a KUAP_CURRENT case to allow_user_access()? cheers