Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp627410imm; Fri, 14 Sep 2018 04:01:13 -0700 (PDT) X-Google-Smtp-Source: ANB0VdabuOAOotRcHRuiQX0JXChre5F5hf0Ev3Zd7i2uW3K11d5d7SPcr+PXny/BjRxb3xiB7HJB X-Received: by 2002:a62:5047:: with SMTP id e68-v6mr11807364pfb.157.1536922873343; Fri, 14 Sep 2018 04:01:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536922873; cv=none; d=google.com; s=arc-20160816; b=F5VW3zbq9Q5Pywwb9eKcPgfuKUT9zoZRWN0futlpbSiSsxtMnW6bdZU41PwC58281r CtrkOI+YVHG0mB9HgzEudJ/HHwDaQ3VxpxJwgquShLqUaT2dZngGgZG7M7tRcVm0W95T Rfnt+MTdUk4fmYc+sXgmltawGlCC5j79m50XZIzM55GpAileio9/g6LcYTUe21IiZzH7 PZ3KK4hDgzKbxYBUlRsM55iD1n22cmJA0DpvkltO6sycE7N3uErPc7Ga41jJYZPF7v+C aSsKoVVDmlrY7jSF3mVCBV/kvZbMJXDJc5d2S0BrrK8Gl7rLpSHFw62oL2HQT32UCdvm KFcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=TNK/JKxfYNiYnLq+26qZeDptCb7sT2J+H/yxmyv8GYQ=; b=U0vZba0GnJAkQ/2qdvc5fhnuL6/SB/YmNgX80UBNc7ATvptJjvRtM2hwfQ9+YH7IjD kg/6OxrXHUHa5+cRfGyYWG6rPS+n3ynHQuzJUaXOGhIgAAjGKaTmpoeStB6IJMXOA6CQ xmF4haI6b4bD+yF6fxzJqM9AwWXL1jKu0KmXP/Rgolb24e8kNZmGSb3XF6SE7C67fSWe YYcEIE+DXfB89bAoERPR8VcBGqtKFnHN6RWn2EkzhW3KGzFbEPknEW0Kg1KoWGVsAbd+ w6LNHwh6mdKg/VZIBZoS3JEJ4RcVBor8TUdkFN4lviVwJJ+MH7rjESvEq1UkGi1nAOtE BdoQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m24-v6si7098629pfk.56.2018.09.14.04.00.57; Fri, 14 Sep 2018 04:01:13 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728247AbeINQOm (ORCPT + 99 others); Fri, 14 Sep 2018 12:14:42 -0400 Received: from mx2.suse.de ([195.135.220.15]:48130 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728131AbeINQOm (ORCPT ); Fri, 14 Sep 2018 12:14:42 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id DB35EAF4D; Fri, 14 Sep 2018 11:00:42 +0000 (UTC) Date: Fri, 14 Sep 2018 13:00:40 +0200 (CEST) From: Jiri Kosina To: "Schaufler, Casey" cc: Thomas Gleixner , Ingo Molnar , Peter Zijlstra , Josh Poimboeuf , Andrea Arcangeli , "Woodhouse, David" , Andi Kleen , Tim Chen , "linux-kernel@vger.kernel.org" , "x86@kernel.org" Subject: RE: [PATCH v6 1/3] x86/speculation: apply IBPB more strictly to avoid cross-process data leak In-Reply-To: <99FC4B6EFCEFD44486C35F4C281DC6732144BFBC@ORSMSX107.amr.corp.intel.com> Message-ID: References: <99FC4B6EFCEFD44486C35F4C281DC6732144BFBC@ORSMSX107.amr.corp.intel.com> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 13 Sep 2018, Schaufler, Casey wrote: > > - return security_ptrace_access_check(task, mode); > > + if (!(mode & PTRACE_MODE_NOACCESS_CHK)) > > + return security_ptrace_access_check(task, mode); > > + return 0; > > Because PTRACE_MODE_IBPB includes PTRACE_MODE_NOAUDIT you > shouldn't need this change. That is true, but that's not my concern here. security_ptrace_access_check() -> call_int_hook() -> P->hook.FUNC(). If it's somehow guaranteed that all functions called this ways are fine to be called from scheduler context (wrt. locks), then it's all fine and I'll happily drop that check. Is it guaranteed? Thanks, -- Jiri Kosina SUSE Labs