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;
IronPort-SDR: hJr1EkTJd3g8xOwIKYsTgzqT5ZBi4+so2g0hHW62WCperZZ0pkfPJzP+yzPbk4fnaS4A6k8bR1
 J1awoLKngPWw521rtm+l1P9xJ/qAvZnpKzWUhMp3nYbsg7HX6wUdCSsRoQTJ94xFb9xvlt8hbp
 RkDFm4TO5QLqDBpuQP00c4gd1cbnCOeUZy0Dx+pVTl8aT2C409ugHsEA807MX5a+54dRJxJV+x
 Ri0NWWpYuxZarVC9OMNsiUA52yoJBiVOhQDB21Eqg/2mwVTRu7sriNKKUVLSbMD/iv9U+KUN7s
 iAM=
From:   "d.hatayama@fujitsu.com" <d.hatayama@fujitsu.com>
To:     "'dyoung@redhat.com'" <dyoung@redhat.com>,
        "'bhe@redhat.com'" <bhe@redhat.com>,
        "'vgoyal@redhat.com'" <vgoyal@redhat.com>,
        "'ebiederm@xmission.com'" <ebiederm@xmission.com>,
        "'mingo@kernel.org'" <mingo@kernel.org>
CC:     "'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>,
        "'kexec@lists.infradead.org'" <kexec@lists.infradead.org>
Subject: [RFD] kdump, kaslr: how to fix the failure of reservation of
 crashkernel low memory due to physical kaslr
Thread-Topic: [RFD] kdump, kaslr: how to fix the failure of reservation of
 crashkernel low memory due to physical kaslr
Thread-Index: AdW621PrfLWfeSyiSUOQtrg7XKymEQ==
Date:   Wed, 25 Dec 2019 04:26:08 +0000
Message-ID: <OSBPR01MB4006AF8B4D355200E385850E95280@OSBPR01MB4006.jpnprd01.prod.outlook.com>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7396d895-2780-464e-78e5-08d788f29055
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Dec 2019 04:26:08.0588
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a19f121d-81e1-4858-a9d8-736e267fd4c7
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tds9fsteMFPnMuPmqVfgDvGjpJyove/3wWTl+RFc5otAWBcKEZEaLNkBLfJn9AAUMrJJA7RVfLFsk6cM19p1/4uQ7JmMYpHlgvm0dc4T1BY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB4215
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Currently, reservation of crashkernel low memory sometimes fails due
to a sparse memory caused by physical kaslr with the following
message:

    Cannot reserve 256MB crashkernel low memory, please try smaller size.

Kdump needs low memory, memory area less than 4GB, e.g. for swiotlb.
Its size is 256MB for low memory by default. OTOH, physical kaslr
loads kernel images in a random physical address for
security. Physical kaslr sometimes choose low memory and sparse
there and as a result, reservation of crash kernel low memory could fail.

This failure seldom occurs on systems with large memory. For example,
on our system with 128GB, the issue occurs once in hundreds of
reboots. Although it doesn't occur frequently and can be avoided in
practice simply by rebooting the system, it definitely occurs once in
hundreds of reboots. Once the issue occurs, it's difficult for ordinary
users to understand why it failed. I'd like to fix this current behavior.

I'm now coming up two ideas but don't know what is best. Please
discuss how to fix the issue in better way.

1) Add a kernel parameter to make physical kaslr to avoid specified
   memory area

  This is the simplest idea I came up with first just like
   kaslr_mem_avoid=3D4GB-0, which is similar syntax to memap=3D, meaning
   that kaslr, please avoid to load kernel image into the region [0,
   4GB).

  It looks to me that this can be implemented easily by taking
   advantage of the existing code about mem_avoid mechanism in
   arch/x86/boot/compressed/kaslr.c.

  This mechanism doesn't lose security provided by physical kaslr if
   system memory is large enough.

  Demerit of this is that users need configuration. Automatic way is
   better if possible.

2) Add special handling for crashkernel=3D low in physical kaslr

  The second idea I came up with is to add special handling for
   crashkernel=3D low in physical kaslr, i.e. physical kaslr recognizes
   crashkernel=3D in kernel parameters and keep enough memory for
   crashkenrel.

  To guarantee that the memory area kept by the special handling in
   physical kaslr is used for crashkernel, it is necessary to mark the
   area to indicate to the crashkernel code executed after kernel
   runs. To implement this, I imagine introducing a new type of memory
   a kind of E820_CRASHKERNEL_LOW.

  My concern on this idea is whether its worth implementing such
   special handling in physical kaslr simply because I don't find such
   code in physical kaslr now.

3) Any other better ideas?

Thanks.
HATAYAMA, Daisuke