From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Ellerman Subject: Re: [PATCH] vsprintf: Do not break early boot with probing addresses Date: Fri, 10 May 2019 16:41:24 +1000 Message-ID: <87h8a2vmjv.fsf@concordia.ellerman.id.au> References: <20190509121923.8339-1-pmladek@suse.com> <20190510043200.GC15652@jagdpanzerIV> <20190510050709.GA1831@jagdpanzerIV> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: <20190510050709.GA1831@jagdpanzerIV> Sender: linux-kernel-owner@vger.kernel.org To: Linus Torvalds Cc: Sergey Senozhatsky , Petr Mladek , Andy Shevchenko , Rasmus Villemoes , "Tobin C . Harding" , Michal Hocko , Sergey Senozhatsky , Steven Rostedt , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Russell Currey , Christophe Leroy , Stephen Rothwell , Heiko Carstens , linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, Martin Schwidefsky List-Id: linux-arch.vger.kernel.org Sergey Senozhatsky writes: > On (05/09/19 21:47), Linus Torvalds wrote: >> [ Sorry about html and mobile crud, I'm not at the computer right now ] >> How about we just undo the whole misguided probe_kernel_address() thing? > > But the problem will remain - %pS/%pF on PPC (and some other arch-s) > do dereference_function_descriptor(), which calls probe_kernel_address(). (Only on 64-bit big endian, and we may even change that one day) > So if probe_kernel_address() starts to dump_stack(), then we are heading > towards stack overflow. Unless I'm totally missing something. We only ended up calling dump_stack() from probe_kernel_address() due to a combination of things: 1. probe_kernel_address() actually uses __copy_from_user_inatomic() which is silly because it's not doing a user access. 2. our user access code uses mmu_has_feature() which uses jump labels, and so isn't safe to call until we've initialised those jump labels. This is unnecessarily fragile, we can easily make the user access code safe to call before the jump labels are initialised. 3. we had extra debug code enabled in mmu_has_feature() which calls dump_stack(). I've fixed 2, and plan to fix 1 as well at some point. And 3 is behind a CONFIG option that no one except me is going to have enabled in practice. So in future we shouldn't be calling dump_stack() in that path. cheers From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bilbo.ozlabs.org ([203.11.71.1]:38563 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726816AbfEJGla (ORCPT ); Fri, 10 May 2019 02:41:30 -0400 From: Michael Ellerman Subject: Re: [PATCH] vsprintf: Do not break early boot with probing addresses In-Reply-To: <20190510050709.GA1831@jagdpanzerIV> References: <20190509121923.8339-1-pmladek@suse.com> <20190510043200.GC15652@jagdpanzerIV> <20190510050709.GA1831@jagdpanzerIV> Date: Fri, 10 May 2019 16:41:24 +1000 Message-ID: <87h8a2vmjv.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-arch-owner@vger.kernel.org List-ID: To: Sergey Senozhatsky , Linus Torvalds Cc: Petr Mladek , Andy Shevchenko , Rasmus Villemoes , "Tobin C . Harding" , Michal Hocko , Sergey Senozhatsky , Steven Rostedt , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Russell Currey , Christophe Leroy , Stephen Rothwell , Heiko Carstens , linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, Martin Schwidefsky Message-ID: <20190510064124.q7J_CwuPPeHjW5ZMFj9t16uRiB6ATm6nxxi7Biu_ngY@z> Sergey Senozhatsky writes: > On (05/09/19 21:47), Linus Torvalds wrote: >> [ Sorry about html and mobile crud, I'm not at the computer right now ] >> How about we just undo the whole misguided probe_kernel_address() thing? > > But the problem will remain - %pS/%pF on PPC (and some other arch-s) > do dereference_function_descriptor(), which calls probe_kernel_address(). (Only on 64-bit big endian, and we may even change that one day) > So if probe_kernel_address() starts to dump_stack(), then we are heading > towards stack overflow. Unless I'm totally missing something. We only ended up calling dump_stack() from probe_kernel_address() due to a combination of things: 1. probe_kernel_address() actually uses __copy_from_user_inatomic() which is silly because it's not doing a user access. 2. our user access code uses mmu_has_feature() which uses jump labels, and so isn't safe to call until we've initialised those jump labels. This is unnecessarily fragile, we can easily make the user access code safe to call before the jump labels are initialised. 3. we had extra debug code enabled in mmu_has_feature() which calls dump_stack(). I've fixed 2, and plan to fix 1 as well at some point. And 3 is behind a CONFIG option that no one except me is going to have enabled in practice. So in future we shouldn't be calling dump_stack() in that path. cheers