From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124267 invoked by alias); 10 Jun 2016 15:11:55 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 124258 invoked by uid 89); 10 Jun 2016 15:11:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:575ACCB, H*MI:sk:575ACCB, H*M:1127, H*i:sk:575ACCB X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 10 Jun 2016 15:11:53 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 353BAC04D292; Fri, 10 Jun 2016 15:11:52 +0000 (UTC) Received: from [10.13.129.159] (dhcp129-159.rdu.redhat.com [10.13.129.159]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5AFBpaw016368; Fri, 10 Jun 2016 11:11:51 -0400 Subject: Re: exercising current aarch64 kprobe support with systemtap To: David Long , Pratyush Anand References: <599229e0-49ad-1c8e-1055-81e38692e5ec@redhat.com> <575A54D6.2070801@linaro.org> <20160610134251.GA15590@dhcppc6> <575ACCB5.90507@linaro.org> Cc: systemtap@sourceware.org, Mark Brown From: William Cohen Message-ID: Date: Fri, 10 Jun 2016 15:11:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <575ACCB5.90507@linaro.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-q2/txt/msg00212.txt.bz2 On 06/10/2016 10:20 AM, David Long wrote: > On 06/10/2016 09:42 AM, Pratyush Anand wrote: >> On 10/06/2016:01:49:10 AM, David Long wrote: >>> Attached are incremental diffs I hope will fix the latest systemtap >>> failures, without abandoning atomic sequence checking. I'm trying to avoid >>> the hex constants but I don't think the insn.c functions help in this case. >> >> It will save us from current problem by checking "stp x29,x30,[sp,...]" >> instruction and returning false if matches. However, we will have to find some >> way to recognize .word instructions. >> >> * An assembly function may not start with "stp x29,x30,[sp,...]", e.g. >> __dma_map_area(), _cpu_resume etc. However, it could be least likely that a >> .word instruction exists before start of assembly function and that too >> contains a word value which could be misleading. >> >> * But major issue is, what if someone instruments a kprobe at an address which >> contains .word values. Instruction will never hit, so probe function will not >> be called, but when real code reads that .word value, it reads a wrong value. >> > > I had considered the assembler routine case but my take on it is that all of this is just a best effort heuristic attempt to prevent someone from kprobe'ing a kernel to death. I don't hold out any hope for making this bullet-proof. The mode of failure for the atomic sequence is the safer choice (rejecting probe registration) so I'm not that worried about the rare case of this happening. Probing inline data doesn't seem like something we can protect from, although we now do blacklist some more data sections. > Yes, the way that the kprobe registration is failing is safer than the alternative. The main concern is that some places that should be allowed for kprobes are not such as the beginning of the schedule function. This type of failure will make a number of the systemtap scripts fail. Would it be possible to look up internally through the data the /proc/kallsyms provides for the T/t symbol that precedes this address and do a max between that symbol address and currently computed start address? -Will >> Can GCC provide some compiler option where .word values are located into a >> specific area? >> > > You can't just go moving the effect of .word directives into a new location/section. As likely as not that data (which could be an actual instruction) needs to be exactly where they were put in the source. > >> ~Pratyush >> >>> >>> -dl >>> >> >>> diff --git a/arch/arm64/kernel/kprobes-arm64.c b/arch/arm64/kernel/kprobes-arm64.c >>> index 28b9c5b..36b4ea5 100644 >>> --- a/arch/arm64/kernel/kprobes-arm64.c >>> +++ b/arch/arm64/kernel/kprobes-arm64.c >>> @@ -127,7 +127,9 @@ is_probed_address_atomic(kprobe_opcode_t *scan_start, kprobe_opcode_t *scan_end) >>> * atomic region starts from exclusive load and ends with >>> * exclusive store. >>> */ >>> - if (aarch64_insn_is_store_ex(le32_to_cpu(*scan_start))) >>> + if ((le32_to_cpu(*scan_start) & 0xffc07fff) == 0xa9807bfd) >>> + return false; >>> + else if (aarch64_insn_is_store_ex(le32_to_cpu(*scan_start))) >>> return false; >>> else if (aarch64_insn_is_load_ex(le32_to_cpu(*scan_start))) >>> return true; >> >