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=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 D3C51C433DB for ; Fri, 29 Jan 2021 21:41:00 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5B9E364E0A for ; Fri, 29 Jan 2021 21:41:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5B9E364E0A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=TSERIfsXCeXObVsEhKDVIiyhPoIJs47a5RJRRdV0mG0=; b=Hc1gWcujxnKvtkg9Jgj3UGWYm E4c6rrYufZq9WsiP8i7QTMV/t2MyJ1PqaSpmVzP28v4nQT+PzWcD7OAyur7PpLn8OdotxTk7R68CK j0AX+Cza7ZDgsKGVYJRstHzynKZ+T86gMNybOtvYctokGHrmE0AbyQJd+1s/5LhlSpIRex7PZe8f5 hpuhs8BvQj/EJmeIVwcKEqWq+W1g+/rKYz9XPDndO29tOHGXetZs/GvZI2x9I0PDs9QXcQEhZJZ75 2nsLc0DEDZRHlnIL2ic8vGOBknUyhjg0Pyv9Hclbssn7HqFOsLyI+kwo8saXaETlsBsJmJ17+WKHQ 9t29i5SDA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l5bUS-000051-Rv; Fri, 29 Jan 2021 21:39:40 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l5bUQ-0008W9-01 for linux-arm-kernel@lists.infradead.org; Fri, 29 Jan 2021 21:39:39 +0000 Received: from [192.168.254.32] (unknown [47.187.219.45]) by linux.microsoft.com (Postfix) with ESMTPSA id 054FC20B7192; Fri, 29 Jan 2021 13:39:35 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 054FC20B7192 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1611956376; bh=YivDnTH5x173IDU3H7zGmJNGWLW4hS8RSMFUVFjFPqk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Jcm15syo29k/9DwOoiuXeGHQhuT0fdxd9whuCa/K9x3jscnYvLd7JZua6TiUC3fsI OrsjagprnxNZLspVRGAw52POqf3SqhfqJtJhnIjBh72nO+NvnEoohBCmYH2ERla3LG xxvZQLUeGcGQ3rk2izoIJP15BQ4I79yeHWPKy1yY= Subject: Re: [RFC PATCH 0/3] arm64: Implement reliable stack trace To: Josh Poimboeuf , Mark Brown References: <20201012172605.10715-1-broonie@kernel.org> <13095563-ff6d-b806-1bf3-efde4383456e@linux.microsoft.com> <20210128142250.GC4537@sirena.org.uk> <20210128152649.6zin3hzim3etbv2p@treble> From: "Madhavan T. Venkataraman" Message-ID: <4a934966-0460-459c-cce3-ca67f099d781@linux.microsoft.com> Date: Fri, 29 Jan 2021 15:39:35 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210128152649.6zin3hzim3etbv2p@treble> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210129_163938_310071_4627EB48 X-CRM114-Status: GOOD ( 24.01 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Julien Thierry , Catalin Marinas , Miroslav Benes , Will Deacon , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 1/28/21 9:26 AM, Josh Poimboeuf wrote: > > Hi all, > > I know this is an old patch set, but I'm not able to see the context, > because I'm not subcribed to the ML. For future patch sets can you also > add live-patching and lkml? > > Are we still considering the shadow stack thing? Just wondering why > we're talking about objtool again. > I think that we are still considering the shadow stack thing. No discussion has happened. Based on my limited knowledge of shadow stacks, I think that shadow stacks do not get rid of objtool. Here is what I feel about shadow stacks. Please correct me if I am wrong. Advantages ========== The only advantage in shadow stacks that I can see is that stack corruption will not prevent unwinding from happening (unless the shadow stack gets corrupted somehow). Issues common with frame pointers ================================= - The compiler has to generate the prolog and epilog. If we cannot trust the compiler to generate these for frame pointers, can we trust it to generate these for the shadow stack? If we can't, we would need objtool anyway. - The compiler would only generate shadow stack code for C functions. For assembly functions, it has to be done by hand. So, objtool has to check this anyway, right? - Inline assembly in C functions can screw up the shadow stack just like it can screw up frame pointers. Again, objtool needs to check. - Performance hit because of the extra overhead in the prolog and the epilog. Issues unique to shadow stacks ============================== - Performance hit because of the extra cache and memory footprint. There is a paper that says that the performance hit can be as high as 10%. Using a parallel shadow stack reduces the hit to about 3.5%. But then again, the characteristics for the kernel may be different. - A separate register has to be reserved for holding the shadow stack pointer. The compiler (gcc) has to be changed to not use this register for other purposes. And we have to trust that there are no compiler bugs in this area. All assembly code that currently uses this register for anything needs to be reviewed and potentially changed. This includes all inline assembly code. BTW, I believe clang uses x18 for the shadow stack pointer register. - Need to decide if we need a separate shadow stack for task, IRQ, overflow, etc. Or, use the same shadow stack. If it is the former, we use more memory and need to switch stacks. If it is the latter, we need to be aware of the boundaries between the different stack traces in the shadow stack. - longjmp style situations require unwinding the shadow stack by several frames. - either unwind the shadow stack repeatedly until the return address matches with the original stack. - for userland code, the shadow stack pointer can be saved in setjmp and restored in longjmp. Something similar can be done in the kernel. - Minor issue is the sizing of the shadow stack so there is no overflow. Questions ========= Do we have to worry about code that modifies the return address of a function? Madhavan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel