Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp655574imm; Thu, 4 Oct 2018 00:48:36 -0700 (PDT) X-Google-Smtp-Source: ACcGV61yUWb9vDop6Po7wAa/QMTZnGuuh9x5SHnajp+kMcpufgBxchjVoRxeXjUUhDJkiBqlwTRM X-Received: by 2002:a63:dc14:: with SMTP id s20-v6mr4657550pgg.398.1538639315968; Thu, 04 Oct 2018 00:48:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538639315; cv=none; d=google.com; s=arc-20160816; b=YbbhC+DvZCtMscFWMAhFC9/oOEB0TjPadPTnHvoIFdGna5hhHViZ6R4ypSr7U5FZKM PUJp1++wYtUsbFDfiNlFuhnE2p4Jt/phUWyAsg89U0e/jlhBGdbckEHT3xlDk+nq3yPm IJ6dXmXtdHd4zD3OlJIB2LClr/CUCroRFAjAi9VDvtM8XOLfw6RDi7/0elBUTYvEMQUG s6O9+Q2aw3nlz0e0ZHL092xG0jorP1iytB8/Ws4wO+Kb1KTbg/UheZGjdtjcenn1dID/ ncMSey3M5ZTXHXf6iuzRiTtJLW5K5NDOlY9h/EW0lrtbFa/7mUDR/T8uA7SzmjFe20ZM pQUA== 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=ZENGjzBdVF/W+b1R+8GpPpvxAA8KpYFF1YAqTXq5FCw=; b=U+LlVS/4rcfzSNizDE8S91JnjEDXRA6LIU9pNDCHhpQB6PbWtnAwxqT5Jci6i1HLAe k35Trv77+daYhxb0ifDERJfl0ArwOAOh8jeRxLxY1zdz2BEOGhnjWJy9IcZRRDxAO1u6 AwOwvp8z/QkdEtrOnMTTLd5o5gqNrERM4Zh9GIya/7IcTD5hEbGoIwudCyZS1QhEKhol 4M5qfK99HasNNFPUxPUP6tuHJAxunb73ZSOCxWv/4/NKXpQMisj0x6JON+tZ+lAxI3Cc m8uN0J1BjKGwQ2ID1C/pa8hj/uwVBwvjvP7+gbdMfiPkIh3tbqwh5o4I7VgVOjlPIEMH W3zg== 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 75-v6si4701061pfy.169.2018.10.04.00.48.20; Thu, 04 Oct 2018 00:48:35 -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 S1727841AbeJDOjY (ORCPT + 99 others); Thu, 4 Oct 2018 10:39:24 -0400 Received: from mx2.suse.de ([195.135.220.15]:39084 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727287AbeJDOjX (ORCPT ); Thu, 4 Oct 2018 10:39:23 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 569FFAE0B; Thu, 4 Oct 2018 07:47:26 +0000 (UTC) Date: Thu, 4 Oct 2018 09:47:25 +0200 (CEST) From: Jiri Kosina To: Jann Horn cc: Casey Schaufler , Kernel Hardening , kernel list , linux-security-module , selinux@tycho.nsa.gov, Dave Hansen , deneen.t.dock@intel.com, kristen@linux.intel.com, Arjan van de Ven Subject: Re: [PATCH v5 2/5] Smack: Prepare for PTRACE_MODE_SCHED In-Reply-To: Message-ID: References: <20180926203446.2004-1-casey.schaufler@intel.com> <20180926203446.2004-3-casey.schaufler@intel.com> <99FC4B6EFCEFD44486C35F4C281DC673214625EA@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, 27 Sep 2018, Jann Horn wrote: > > Yes. Since the PTRACE_MODE_NOAUDIT was in PTRACE_MODE_IBPB in Jiri's > > previous patch set and not in PTRACE_MODE_SCHED in this one I assumed > > that there was a good reason for it. > > Jiri, was there a good reason for it, and if so, what was it? [ FWIW PTRACE_MODE_NOAUDIT being in PTRACE_MODE_IBPB goes back to original Tim's pre-CRD patchset ] Well, we can't really call out into audit from scheduler code, and the previous versions of the patchsets didn't have PTRACE_MODE_SCHED, so it had to be included in PTRACE_MODE_IBPB in order to make sure we're not calling into audit from context switch code. Or did I misunderstand the question? Thanks, -- Jiri Kosina SUSE Labs