From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: [PATCH v12 06/13] seccomp: add system call filtering using BPF Date: Thu, 01 Mar 2012 22:55:30 -0800 Message-ID: <4F506EE2.1050705@zytor.com> References: <1330559620-23543-1-git-send-email-wad@chromium.org> <1330559620-23543-6-git-send-email-wad@chromium.org> <4F50603B.7040505@zytor.com> Reply-To: kernel-hardening@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: List-Post: List-Help: List-Unsubscribe: List-Subscribe: In-Reply-To: To: Indan Zupancic Cc: Will Drewry , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, kernel-hardening@lists.openwall.com, netdev@vger.kernel.org, x86@kernel.org, arnd@arndb.de, davem@davemloft.net, mingo@redhat.com, oleg@redhat.com, peterz@infradead.org, rdunlap@xenotime.net, mcgrathr@chromium.org, tglx@linutronix.de, luto@mit.edu, eparis@redhat.com, serge.hallyn@canonical.com, djm@mindrot.org, scarybeasts@gmail.com, pmoore@redhat.com, akpm@linux-foundation.org, corbet@lwn.net, eric.dumazet@gmail.com, markus@chromium.org, coreyb@linux.vnet.ibm.com, keescook@chromium.org List-Id: linux-arch.vger.kernel.org On 03/01/2012 10:43 PM, Indan Zupancic wrote: > On Fri, March 2, 2012 06:52, H. Peter Anvin wrote: >> On 03/01/2012 09:45 PM, Indan Zupancic wrote: >>> >>>> + * @nr: the system call number >>>> + * @arch: indicates system call convention as an AUDIT_ARCH_* value >>>> + * as defined in . >>>> + * @instruction_pointer: at the time of the system call. >>> >>> If the vDSO is used this will always be the same, so what good is this? >>> I haven't gotten an answer to this yet. >>> >> >> And if it isn't, or you're on an architecture which doesn't use the vdso >> as the launching point, it's not. > > True, but then what? > Ok, fail on my part - I misread the above to refer to @arch, not @instruction_pointer. >> -- Pin is a great example. > Is that http://www.pintool.org/? > > Can you explain how knowing the IP is useful for Pin? > > All I am asking for is just one use case for providing the IP. Is that > asking for too much? However, it still applies. For something like Pin, Pin may want to trap on all or a subset from the instrumented program, while the instrumentation code -- which lives in the same address space -- needs to execute those same instructions. Yes, it's useless for *security* (unless perhaps if you keep very strict tabs on the flow of control by using debug registers, dynamic translation or whatnot), but it can be highly useful for *instrumentation*, where you want to analyze the behavior of a non-malicious program. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from terminus.zytor.com ([198.137.202.10]:43205 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756401Ab2CBG42 (ORCPT ); Fri, 2 Mar 2012 01:56:28 -0500 Message-ID: <4F506EE2.1050705@zytor.com> Date: Thu, 01 Mar 2012 22:55:30 -0800 From: "H. Peter Anvin" MIME-Version: 1.0 Subject: Re: [PATCH v12 06/13] seccomp: add system call filtering using BPF References: <1330559620-23543-1-git-send-email-wad@chromium.org> <1330559620-23543-6-git-send-email-wad@chromium.org> <4F50603B.7040505@zytor.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Indan Zupancic Cc: Will Drewry , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, kernel-hardening@lists.openwall.com, netdev@vger.kernel.org, x86@kernel.org, arnd@arndb.de, davem@davemloft.net, mingo@redhat.com, oleg@redhat.com, peterz@infradead.org, rdunlap@xenotime.net, mcgrathr@chromium.org, tglx@linutronix.de, luto@mit.edu, eparis@redhat.com, serge.hallyn@canonical.com, djm@mindrot.org, scarybeasts@gmail.com, pmoore@redhat.com, akpm@linux-foundation.org, corbet@lwn.net, eric.dumazet@gmail.com, markus@chromium.org, coreyb@linux.vnet.ibm.com, keescook@chromium.org Message-ID: <20120302065530.j-DwPUbW3iVM8Rmaq_FBcVsT5d9XC4P5i6K867NwXjs@z> On 03/01/2012 10:43 PM, Indan Zupancic wrote: > On Fri, March 2, 2012 06:52, H. Peter Anvin wrote: >> On 03/01/2012 09:45 PM, Indan Zupancic wrote: >>> >>>> + * @nr: the system call number >>>> + * @arch: indicates system call convention as an AUDIT_ARCH_* value >>>> + * as defined in . >>>> + * @instruction_pointer: at the time of the system call. >>> >>> If the vDSO is used this will always be the same, so what good is this? >>> I haven't gotten an answer to this yet. >>> >> >> And if it isn't, or you're on an architecture which doesn't use the vdso >> as the launching point, it's not. > > True, but then what? > Ok, fail on my part - I misread the above to refer to @arch, not @instruction_pointer. >> -- Pin is a great example. > Is that http://www.pintool.org/? > > Can you explain how knowing the IP is useful for Pin? > > All I am asking for is just one use case for providing the IP. Is that > asking for too much? However, it still applies. For something like Pin, Pin may want to trap on all or a subset from the instrumented program, while the instrumentation code -- which lives in the same address space -- needs to execute those same instructions. Yes, it's useless for *security* (unless perhaps if you keep very strict tabs on the flow of control by using debug registers, dynamic translation or whatnot), but it can be highly useful for *instrumentation*, where you want to analyze the behavior of a non-malicious program. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.