Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp3931665imb; Wed, 6 Mar 2019 00:48:14 -0800 (PST) X-Google-Smtp-Source: APXvYqzW/FOAp9RzScxaDAfDy4wZ5hQSioL6qeE6ANGmYQlLnOjA32UBoQB9l1FF93nY7HrdgrTF X-Received: by 2002:a62:f201:: with SMTP id m1mr6180493pfh.97.1551862094821; Wed, 06 Mar 2019 00:48:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551862094; cv=none; d=google.com; s=arc-20160816; b=h/e/4glBeOR2cG+ecWuFGFL2TCxd7spPopZuytvHAmSwzlgGyqCn6ml3CeJHHbs1xn pEEj3zGY+/kSD820BkEaJF5W91sac8+sRIEbebBp0y/kaiDDSq1LWMzGotyh/txD1BXF sluxS8Vlw4R1qf5MdVQFo20t8qLsxntYr4Y0dU8uAAwcHLjyZLx24AG96AiNJF0h20Ww FfyNnWvbX1DAvFoRMD93jvuLUfxHM0CQGKhWVdN+LrKtuyHu6LJrgaX2quy8+UOzH1lY ysiZYNOnkmzI2794eFd/jWEAy2k2AEw1NPYP/vZYUyUXT2LZDfaH+1p0em+du/GTY33Q UAyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=NM3xQT8ZCO4/Dlq3Ro+mfnRddwV3Pbik78B0afnrzLw=; b=SuMx3GiWaQMevg+marELM+XGu7Mq8iof3VHm2dwaWhmDZT0khChYGp6WN0cAiRr2wy qzhfwm4+XFus1um+P3NLUaIvigxM+JXvEfoq7S3aG5icKUewd1jbDO1/S8JK3TbgFpna KkVarW8nCKRqD6coP6EfAFoBhgrIRwFkRMCdS7d5vCoGYKFRCiql/RTfe4+jWCLU4hZ2 B9MIBFo+okaDxI3D0FXfxowqbXrt4St101+BmBRXkpNcTe4VpcagTHNjPh55yFBVAZ8B 8S9qEbszN3vNPxu6Hv5WXNF8wfuZZ3ft1GMy1RYaeR8hXCTJxV1I39cFAetdv/ea9hd1 H6yQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="UbQDu/K6"; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f40si946065plb.339.2019.03.06.00.47.59; Wed, 06 Mar 2019 00:48:14 -0800 (PST) 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; dkim=pass header.i=@gmail.com header.s=20161025 header.b="UbQDu/K6"; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729134AbfCFH6q (ORCPT + 99 others); Wed, 6 Mar 2019 02:58:46 -0500 Received: from mail-io1-f66.google.com ([209.85.166.66]:39429 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725783AbfCFH6q (ORCPT ); Wed, 6 Mar 2019 02:58:46 -0500 Received: by mail-io1-f66.google.com with SMTP id x3so9439939ior.6 for ; Tue, 05 Mar 2019 23:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NM3xQT8ZCO4/Dlq3Ro+mfnRddwV3Pbik78B0afnrzLw=; b=UbQDu/K66YYoyGR+gDY2au5cxMtJ7vmotfGbOhXeob4n4R1tpmRGB6wewLBlkhI/f3 CHoay/boJrgRoQb7b92duBEoTCMnAimjiAPBx3vlK4fJ/e7OtzFWTO8W67RRG/5xtA86 IHA0CJ/EDAHdk4ZYWfFH4SvMyZ/gwVnsNVpyDPyvV9PmCKFRYikb5afEzHcDQJsksPvr HIIpEZjvX9CYXDRZXXcjcxWTKUibRGDfF+rtW1opurszAEI/F/SRiPW5JqO07mPMJa7r aOyuuja8zuGtZxck0yu0qzdciZw5b0x8QuwaH9BU63j0HykdwplCZobtQ4ZK9FRTDQpH KR0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NM3xQT8ZCO4/Dlq3Ro+mfnRddwV3Pbik78B0afnrzLw=; b=KJfsCKQf8iai6TxhujiZZAl9khWDPLNzBwyDJ4X18ZBnODH/R1PonzjmgIaSie0LME hH4AiXcLcfnsMwcwC1dXxJyazw6Jyz5KzWz+WB70+4NlqZamGiRT6IedU3CnBiCBHASs EukyX2/ouBZ45+cnrQZ/Av5m+AEsGJeA7fsktMOomx+GtL9PlWV+7j8BK/Imcm7odb9v vu60dRzp+nyg11/NcPpQ1NnDNTgeN/rxl0Db4vnzGc9CcYJ6zSJlORCn7cO02urU3ZS+ 6BNYqwVbYyqKPiIDPS4DwPtACrpTIJhUoDL2twTAGNNlKJMDu7RmT/EniPl5AFCr5lJQ oWQg== X-Gm-Message-State: APjAAAUL5b3pmecWmqSk4/9gfLzrXm3BgaPSn+hBEJcuSaqESyu1LQCQ QhWjmgnpaiH4ZSRQsfImIhpfAKNa2jjL3DPTVA== X-Received: by 2002:a6b:c889:: with SMTP id y131mr2517449iof.106.1551859125218; Tue, 05 Mar 2019 23:58:45 -0800 (PST) MIME-Version: 1.0 References: <1551081596-2856-1-git-send-email-kernelfans@gmail.com> <20190225094522.GC26145@zn.tnic> <20190226104653.GB14836@zn.tnic> <20190227013034.GP14858@MiWiFi-R3L-srv> <20190227073958.GA1786@zn.tnic> In-Reply-To: <20190227073958.GA1786@zn.tnic> From: Pingfan Liu Date: Wed, 6 Mar 2019 15:58:33 +0800 Message-ID: Subject: Re: [PATCH] x86/boot/KASLR: skip the specified crashkernel reserved region To: Borislav Petkov Cc: Baoquan He , Kees Cook , x86@kernel.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Will Deacon , Nicolas Pitre , Chao Fan , "Kirill A. Shutemov" , Ard Biesheuvel , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 27, 2019 at 3:40 PM Borislav Petkov wrote: > > + Kees. > > @Kees, you might want to go upthread a bit for context. > Seems not reply from Kees. > On Wed, Feb 27, 2019 at 09:30:34AM +0800, Baoquan He wrote: > > Agree that 'crashkernel=x' should be encouraged to use as the first > > choice when reserve crashkernel. If we decide to not obsolete > > 'crashkernel=x@y', it will leave a unstable kernel parameter. > > Is anyone even talking about obsoleting this? > > And if anyone is, anyone can think a bit why we can't do this. > As Dave said, some un-relocatable code should be loaded to a specified space. Also the param is used by archs beside x86 > > Another worry is that KASLR won't always fail 'crashkernel=x@y', > > customer may set and check in testing stage, then later in production > > environment one time of neglect to not check may cause carashed kernel > > uncaptured. > > > > IMHO, 'crashkernel=x@y' is similar to those specified memmap=ss[#$!]nn > > which have been avoided in boot stage KASLR. > > So my worry is that by specifying too many exclusion ranges, we might > limit the kaslr space too much and make it too predictable. Especially > since distros slap those things automatically and most users take them > for granted. > Kernel has already done this excluding 1gb pages. Do we need to worry about 200-400 MB for crashkernel? And I think if a user specify the region, then he/she should be aware of the limit of KASLR (can printk to warn him/her). > But I might be way off here because of something else I'm missing ... > So how do you think about this now? Just leaving a unstable kernel parameter, or printk some info when crashkernel=x@y fails. Thanks, Pingfan > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply.