Received: by 10.213.65.68 with SMTP id h4csp779881imn; Tue, 27 Mar 2018 08:37:43 -0700 (PDT) X-Google-Smtp-Source: AG47ELsMmXy0wrFQ9nZEGxWJYu/x7MpFHtW/ph8yeanmxw1PSO8mLqRm+g8NmPA05eKr2+WpuHHV X-Received: by 2002:a17:902:525:: with SMTP id 34-v6mr14950004plf.267.1522165063846; Tue, 27 Mar 2018 08:37:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522165063; cv=none; d=google.com; s=arc-20160816; b=BFfbcu8vRVE9n7pjeQZM+gE2ZMNKMFbDz4H/DVjOSdRX4MJfpl4Fs+2s6soj1sQFqD 3ZshYgQrJiJMpAva/NpQB+rv34pYWngttg/LEARYkH4GIsEU3C9QvSdN473o4MwlHH3h icpdGWUWLitSnJpoHAEJLGKCZdqRTVNs8Ig2aFAn5ZJaAIoJO+QkuIDLUSWHUbhnTxwA H0+lk/ub+vwM9UW3YTAoE7okQ7AKYWuGcCQvmrTGWqRU72YU80MmsfCnC25u4YmUdeZ+ Kl4f9UIlMVVmrBb954Kdho2mzkzAQEGRoQZuquzQoyMWHF1vm2AufZV7cGLTsOhDicdi vKqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=AIxagM+Ghm/uOYctb4xoz4TuJKmnLa82ZwpHe/aCpV4=; b=NkK5rSu34cjIC5s/UUCx+OSCpXn2dDmVArZx21RZ1E081AevKcSwN3GPFMkv58jO8x ihiuK9yIKgl6BmYp9Q5OjrfOPz3iZL82l90uQfS4zwVt8NSrcGeyAd0IBtf8YTv9qCf0 LVOeZ+d+3GdRaahd4om387rLt2xmLf8I8A0UqooWlL7gx8eU1FfAPA50+0OWNQexqFhT o2SQnvUpO7XfC0ymxQ+inxlpAvouEmr4yYmJIT9iJeaeichucWjl6uFuLilGXLeDMLkN i5zURXGrkl26Q3ROGTffWhdF73AbQNeOI5jX/F1lxKtt06YEpooqD176cMwwKRYkUt/8 9Tkg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u1-v6si1632624plj.409.2018.03.27.08.37.29; Tue, 27 Mar 2018 08:37:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752546AbeC0PgZ (ORCPT + 99 others); Tue, 27 Mar 2018 11:36:25 -0400 Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:33244 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752470AbeC0PgY (ORCPT ); Tue, 27 Mar 2018 11:36:24 -0400 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1f0qdB-0001HP-00; Tue, 27 Mar 2018 15:35:25 +0000 Date: Tue, 27 Mar 2018 11:35:25 -0400 From: Rich Felker To: Russell King - ARM Linux Cc: Tony Lindgren , Huacai Chen , Andrew Morton , Stephen Rothwell , Ralf Baechle , James Hogan , Yoshinori Sato , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org Subject: Re: Regression with arm in next with stack protector Message-ID: <20180327153525.GI1436@brightrain.aerifal.cx> References: <20180323181452.GJ5799@atomide.com> <20180327090409.GA10990@n2100.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180327090409.GA10990@n2100.armlinux.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 27, 2018 at 10:04:10AM +0100, Russell King - ARM Linux wrote: > On Fri, Mar 23, 2018 at 11:14:53AM -0700, Tony Lindgren wrote: > > Hi, > > > > Looks like commit 5638790dadae ("zboot: fix stack protector in > > compressed boot phase") breaks booting on arm. > > > > This is all I get from the bootloader on omap3: > > > > Starting kernel ... > > > > data abort > > pc : [<810002d0>] lr : [<100110a8>] > > reloc pc : [<9d6002d0>] lr : [<2c6110a8>] > > sp : 81467c18 ip : 81466bf0 fp : 81466bf0 > > r10: 80fc2c40 r9 : 81000258 r8 : 86fec000 > > r7 : ffffffff r6 : 81466bf8 r5 : 00000000 r4 : 80008000 > > r3 : 81466c14 r2 : 81466c18 r1 : 000a0dff r0 : 00466bf8 > > Flags: nZCv IRQs off FIQs off Mode SVC_32 > > Resetting CPU ... > > > > resetting ... > > The reason for this is the following code that was introduced by the > referenced patch: > > + ldr r0, =__stack_chk_guard > + ldr r1, =0x000a0dff > + str r1, [r0] > > This uses the absolute address of __stack_chk_guard in the decompressor, > which is a self-relocatable image. As with all constructs like the > above, this absolute address doesn't get fixed up, and so it ends up > pointing at invalid memory (in this case 0x466bf8) vs RAM at 0x80000000, > and the decompressor looks to be around 0x81000000. > > Such constructs can not be used in the decompressor for exactly this > reason - they need to use PC-relative addressing instead just like > everything else does in head.S. Can someone please answer why this is even needed to begin with? I don't see any compelling reason __stack_chk_guard needs a particular value in the decompressor, which is not dealing with any non-constant input. Just putting __stack_chk_guard in its bss should be fine and would eliminate all the risks of wrong code to load a value into it. Alternatively put it in initialized data with the desired value. Rich