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 X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 69066C433F5 for ; Wed, 5 Sep 2018 15:58:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2B2CF2075E for ; Wed, 5 Sep 2018 15:58:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2B2CF2075E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727636AbeIEU3X (ORCPT ); Wed, 5 Sep 2018 16:29:23 -0400 Received: from mga02.intel.com ([134.134.136.20]:3185 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726487AbeIEU3X (ORCPT ); Wed, 5 Sep 2018 16:29:23 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Sep 2018 08:58:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,334,1531810800"; d="scan'208";a="83282404" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.126]) by fmsmga002.fm.intel.com with ESMTP; 05 Sep 2018 08:58:24 -0700 Received: by tassilo.localdomain (Postfix, from userid 1000) id DB8DA300B65; Wed, 5 Sep 2018 08:58:23 -0700 (PDT) Date: Wed, 5 Sep 2018 08:58:23 -0700 From: Andi Kleen To: Jiri Kosina Cc: Tim Chen , "Schaufler, Casey" , Thomas Gleixner , Ingo Molnar , Peter Zijlstra , Josh Poimboeuf , Andrea Arcangeli , "Woodhouse, David" , Oleg Nesterov , "linux-kernel@vger.kernel.org" , "x86@kernel.org" Subject: Re: [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks Message-ID: <20180905155823.GL27886@tassilo.jf.intel.com> References: <31436186-88da-324e-88a0-8fdca7bf60ac@linux.intel.com> <99FC4B6EFCEFD44486C35F4C281DC67321447094@ORSMSX107.amr.corp.intel.com> <3f24e8c8-eab8-66c2-9a8d-957e30cac809@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > So, after giving it a bit more thought, I still believe "I want spectre V2 > protection" vs. "I do not care about spectre V2 on my system > (=nospectre_v2)" are the sane options we should provide; so I'll respin v4 > of my patchset, including the ptrace check in switch_mm() (statically > patched out on !IBPB-capable systems), and we can then later see whether > the LSM implementation, once it exists, should be used instead. Please if you repost include plenty of performance numbers for multi threaded workloads. It's ridiculous to even discuss this without them. -Andi