From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3BEDEC43142 for ; Tue, 26 Jun 2018 15:13:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F01BA26CD1 for ; Tue, 26 Jun 2018 15:13:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F01BA26CD1 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752005AbeFZPNw (ORCPT ); Tue, 26 Jun 2018 11:13:52 -0400 Received: from foss.arm.com ([217.140.101.70]:47162 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751867AbeFZPNu (ORCPT ); Tue, 26 Jun 2018 11:13:50 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7E37C80D; Tue, 26 Jun 2018 08:13:50 -0700 (PDT) Received: from edgewater-inn.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 4EF1F3F5AD; Tue, 26 Jun 2018 08:13:50 -0700 (PDT) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id E1F631AE2E48; Tue, 26 Jun 2018 16:14:27 +0100 (BST) Date: Tue, 26 Jun 2018 16:14:27 +0100 From: Will Deacon To: Mathieu Desnoyers Cc: linux-arm-kernel , linux-kernel , Arnd Bergmann , Peter Zijlstra , "Paul E. McKenney" , Boqun Feng , Catalin Marinas , peter maydell , Mark Rutland Subject: Re: [PATCH 3/3] rseq/selftests: Add support for arm64 Message-ID: <20180626151427.GF23375@arm.com> References: <1529949285-11013-1-git-send-email-will.deacon@arm.com> <1529949285-11013-4-git-send-email-will.deacon@arm.com> <501929863.3051.1529950210436.JavaMail.zimbra@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <501929863.3051.1529950210436.JavaMail.zimbra@efficios.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mathieu, On Mon, Jun 25, 2018 at 02:10:10PM -0400, Mathieu Desnoyers wrote: > ----- On Jun 25, 2018, at 1:54 PM, Will Deacon will.deacon@arm.com wrote: > > +#define __RSEQ_ASM_DEFINE_TABLE(label, version, flags, start_ip, \ > > + post_commit_offset, abort_ip) \ > > + " .pushsection __rseq_table, \"aw\"\n" \ > > + " .balign 32\n" \ > > + __rseq_str(label) ":\n" \ > > + " .long " __rseq_str(version) ", " __rseq_str(flags) "\n" \ > > + " .quad " __rseq_str(start_ip) ", " \ > > + __rseq_str(post_commit_offset) ", " \ > > + __rseq_str(abort_ip) "\n" \ > > + " .popsection\n" > > + > > +#define RSEQ_ASM_DEFINE_TABLE(label, start_ip, post_commit_ip, abort_ip) \ > > + __RSEQ_ASM_DEFINE_TABLE(label, 0x0, 0x0, start_ip, \ > > + (post_commit_ip - start_ip), abort_ip) > > + > > +#define RSEQ_ASM_STORE_RSEQ_CS(label, cs_label, rseq_cs) \ > > + RSEQ_INJECT_ASM(1) \ > > + " adrp " RSEQ_ASM_TMP_REG ", " __rseq_str(cs_label) "\n" \ > > + " add " RSEQ_ASM_TMP_REG ", " RSEQ_ASM_TMP_REG \ > > + ", :lo12:" __rseq_str(cs_label) "\n" \ > > + " str " RSEQ_ASM_TMP_REG ", %[" __rseq_str(rseq_cs) "]\n" \ > > + __rseq_str(label) ":\n" > > + > > +#define RSEQ_ASM_DEFINE_ABORT(label, abort_label) \ > > + " .pushsection __rseq_failure, \"ax\"\n" \ > > + " .long " __rseq_str(RSEQ_SIG) "\n" \ > > + __rseq_str(label) ":\n" \ > > + " b %l[" __rseq_str(abort_label) "]\n" \ > > + " .popsection\n" > > Thanks Will for porting rseq to arm64 ! That's ok, it was good fun :) I'm going to chat with our compiler guys to see if there's any room for improving the flexibility in the critical section, since having a temporary in the clobber list is pretty grotty. > I notice you are using the instructions > > adrp > add > str > > to implement RSEQ_ASM_STORE_RSEQ_CS(). Did you compare > performance-wise with an approach using a literal pool > near the instruction pointer like I did on arm32 ? I didn't, no. Do you have a benchmark to hand so I can give this a go? The two reasons I didn't go down this route are: 1. It introduces data which is mapped as executable. I don't have a specific security concern here, but the way things have gone so far this year, I've realised that I'm not bright enough to anticipate these things. 2. It introduces a branch over the table on the fast path, which is likely to have a relatively higher branch misprediction cost on more advanced CPUs. I also find it grotty that we emit two tables so that debuggers can cope, but that's just a cosmetic nit. > With that approach, this ends up being simply > > adr > str > > which provides significantly better performance on my test > platform over loading a pointer targeting a separate data > section. My understanding is that your test platform is based on Cortex-A7, so I'd be wary about concluding too much about general performance from that CPU since its a pretty straightforward in-order design. Will