From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934970AbcHaOJN (ORCPT ); Wed, 31 Aug 2016 10:09:13 -0400 Received: from mailapp01.imgtec.com ([195.59.15.196]:49089 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933214AbcHaOJL (ORCPT ); Wed, 31 Aug 2016 10:09:11 -0400 Subject: Re: [PATCH 1/2] tracing/syscalls: allow multiple syscall numbers per syscall To: Andy Lutomirski , Steven Rostedt References: <1472463007-6469-1-git-send-email-marcin.nowakowski@imgtec.com> <20160830152955.17633511@gandalf.local.home> <20160830165830.5e494c43@gandalf.local.home> <20160830180328.4e579db3@gandalf.local.home> <20160830183030.3e9f67f0@gandalf.local.home> <20160830192818.4e16a674@gandalf.local.home> CC: Linux API , Ingo Molnar , open list , Linux MIPS Mailing List From: Marcin Nowakowski Message-ID: <0609be30-bfcd-40f3-ec00-2b8b056654bc@imgtec.com> Date: Wed, 31 Aug 2016 16:08:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.2.5] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 31.08.2016 02:01, Andy Lutomirski wrote: > On Tue, Aug 30, 2016 at 4:28 PM, Steven Rostedt wrote: >> On Tue, 30 Aug 2016 16:09:04 -0700 >> Andy Lutomirski wrote: >> >>> But none of this should be a problem at all for MIPS, right? AFAICT >>> the only problem for MIPS is that there *is* a mapping from metadata >>> to nr. If that mapping got removed, MIPS should just work, right? >> >> Wait, where's the mapping of metadata to nr. I don't see that, nor do I >> see a need for that. The issue is that we have metadata that expresses >> how to record a syscall, and we map syscall nr to metadata, because >> when tracing is active, the only thing we have to find that metadata is >> the syscall nr. > > It's in init_ftrace_syscalls(): > > meta->syscall_nr = i; > > and everything that uses that. I think that this is the main problem > that the patch that started this thread changes, and I think that > deleting it would be cleaner than this patch. > >> >> Now if a syscall nr has more than one way to record (a single nr for >> multiple syscalls), then we get into trouble. That's why we have >> trouble with compat syscalls. The same number maps to different >> syscalls, and we don't know how to differentiate that. > >> >> >>> >>> For x86 compat, I think that adding arch should be sufficient. >>> Specifically, rather than having just one enter_syscall_files array, >>> have one per audit arch. Then call syscall_get_arch() as well as >>> syscall_get_nr() and use both to lookup the metadata. AFAIK this >>> should work on all architectures, although you might need some arch >>> helpers to enumerate all the arches and their respective syscall >>> tables (and max syscall nrs). >> >> OK, if the regs can get us to the arch, then this might work. >> >> That is, perhaps we can have multiple tables (not really sure how to >> make that happen in an arch agnostic way), and then have two functions: >> >> trace_get_syscall_nr(current, regs) >> trace_get_syscall_arch(current, regs) > > Sadly, syscall_get_arch() doesn't take a regs parameter -- it looks at > current. If it were made more general, it would need a task pointer, > not a regs pointer, but would just looking at current be okay for > tracing? I think using current should be enough here? Anyway in all other cases where syscall_get_arch is used, any other methods that require a task pointer take it from current as well. > syscall_get_arch() does work on all archs that support seccomp filters, though. And as it happens I think it works on all archs that have COMPAT and that pose any problems here? So for any arch that doesn't support syscall_get_arch it should be safe to have a fallback that defaults to indicating a single arch type. However, it seems to me that the method used currently for mapping the syscall metadata to the syscall numbers wouldn't be possible when the extra dimension of arch type is added? Would it require some sort of metadata pointer table generation at build time? If all archs used the same method for building syscall tables (as suggested by Arnd) then we could have a single build-time method for adding the syscall metadata map to the syscall tables? (as all the symbol names are known at that time and could be coalesced to find the metadata location from a syscall number/arch and name)... Marcin