Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1985727imu; Wed, 21 Nov 2018 05:09:49 -0800 (PST) X-Google-Smtp-Source: AFSGD/UDlLK/7JRBt1i9FRrjLoHCztm/xI57acVlBRM1E/G3jeZiRf9RPcJra0QZhzniFFpqohcd X-Received: by 2002:a63:e001:: with SMTP id e1mr5951636pgh.39.1542805789111; Wed, 21 Nov 2018 05:09:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542805789; cv=none; d=google.com; s=arc-20160816; b=OlanqEyraGJEV791AZQg7udD/V24i3YeX8istJ6pDHwvydqKIZ0hL1qQfwq+Q2u2TN jFnVmGHMyDP8rQd1Gh4Q0RogJP+nIfwO87jhb2Ll8JnNv+9kp4zX4Jk93/6KFwfKgliG 5jHQ0kc+SfV5fsOD2QSfn4q/Xe7QyaFAkJBRE77szhDFHa+2jRRkQ9iIYGAlllnf1CSe DfFsEKfaTyGhlNczLzRg0PRp0cdPUQsLZsTj1JfUWIRzSLKDn1TRvsDukD104yUOFaFN N1oUhC01Di2nd76g0hK5EyNooxtqwVmnBXDTvWMmnW2aAiLIHZV8LGEMqSzGJCITJXCq g41Q== 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; bh=AELdUUz9/rSXlbKJrmFvqILUHcbisBqdqvRKFKH0CQs=; b=yNbV1T/HFPOULZHOrvlLIY98pUKlOTroPLtIB9a5P2hx+BPXyUmQrbmdD+L+4wqcf9 hT1lAWnjDO4vHNG4xkcEiVcGjJZBrsP1q9s69aij99XrnH11CVB9Pdmb4gEzwTDfjZlP I8eK4UIYJwS90Cl0VBpFuHJQHdpup3IT0WMYmWItsW/xqT3ZEeVKDjnAw6HHgf5pjIuH pWRoIlrwB8R6CYaEH98qWd47TBH/1tbQnHaoJpQL0KX0H5hiKH7lLRlDL7/7KneCLTfC pHwmWANyRjSuzm580fPB62m74ltiKAR/pT0egrDohxOMN60dHvPWNKGdlFuHj0xFnK3Q 1vxQ== ARC-Authentication-Results: i=1; mx.google.com; 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 g8-v6si40459019pli.79.2018.11.21.05.09.28; Wed, 21 Nov 2018 05:09:49 -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; 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 S1729259AbeKUWZH (ORCPT + 99 others); Wed, 21 Nov 2018 17:25:07 -0500 Received: from ozlabs.org ([203.11.71.1]:60395 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728078AbeKUWZH (ORCPT ); Wed, 21 Nov 2018 17:25:07 -0500 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 430LW736LBz9s3l; Wed, 21 Nov 2018 22:50:59 +1100 (AEDT) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au From: Michael Ellerman To: Russell Currey , Christophe Leroy , Benjamin Herrenschmidt , Paul Mackerras Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [RFC PATCH v1 3/6] powerpc: Add skeleton for Kernel Userspace Execution Prevention In-Reply-To: <63177c72b94a653707d6b984ca789ecf8ebf0a95.camel@russell.cc> References: <1b27e980fa8dda09955b35be09c99bb1e22fef70.1541568127.git.christophe.leroy@c-s.fr> <63177c72b94a653707d6b984ca789ecf8ebf0a95.camel@russell.cc> Date: Wed, 21 Nov 2018 22:50:56 +1100 Message-ID: <87ftvu1wf3.fsf@concordia.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 Russell Currey writes: > On Wed, 2018-11-07 at 16:56 +0000, Christophe Leroy wrote: >> This patch adds a skeleton for Kernel Userspace Execution Prevention. >> >> Then subarches implementing it have to define CONFIG_PPC_HAVE_KUEP >> and provide setup_kuep() function. >> >> Signed-off-by: Christophe Leroy > > An open question (with nothing to do specifically with this patch): > > For what reason would you ever disable execution prevention? Clearly > there must be something since "nosmep" is a thing, but I don't know why > we'd ever do it. Because depending on the implementation there might be a performance overhead, and you may want to avoid that. cheers