From: Sasha Levin <sashal@kernel.org>
To: Nicolas Boichat <drinkcat@chromium.org>
Cc: Yueyi Li <liyueyi@live.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"markus@oberhumer.com" <markus@oberhumer.com>,
"will.deacon@arm.com" <will.deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
stable@vger.kernel.org, Guenter Roeck <groeck@chromium.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] arm64: kaslr: Reserve size of ARM64_MEMSTART_ALIGN in linear region
Date: Sat, 13 Apr 2019 10:38:07 -0400 [thread overview]
Message-ID: <20190413143807.GV11568@sasha-vm> (raw)
In-Reply-To: <CANMq1KCdagM3L23Fgz2znhFCB_2JvtBWNvVCXZp4iGc8T46GwQ@mail.gmail.com>
On Sat, Apr 13, 2019 at 08:41:33PM +0800, Nicolas Boichat wrote:
>Dear stable maintainers,
>
>I encountered a similar issue on a 4.19.33 kernel (Chromium OS). On my
>board, the system would not even be able to boot if KASLR decides to
>map the linear region to the top of the virtual address space. This
>happens every 253 boots on average (there are 0xfd possible random
>offsets, and only the top one fails).
>
>I tried to debug the issue, and it appears physical memory allocated
>for vmemmap and mem_section array would end up at the same location,
>corrupting each other early on boot. I could not figure out exactly
>why this is happening, but in any case, this patch fixes my issue (no
>failure in 744 reboots with 240 unique offsets, and counting...), and
>IMHO the ERR_PTR justification in the commit message is enough to
>warrant inclusion in -stable branches.
>
>The patch below was committed to mainline as:
>commit c8a43c18a97845e7f94ed7d181c11f41964976a2
> arm64: kaslr: Reserve size of ARM64_MEMSTART_ALIGN in linear region
>
>and should be included in stable branches after this commit:
>Fixes: c031a4213c11a5db ("arm64: kaslr: randomize the linear region")
>i.e. anything after kernel 4.5 (git describe says v4.5-rc4-62-gc031a4213c11a5d).
I've queued it for 4.9-4.19, thanks for the report.
--
Thanks,
Sasha
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2019-04-13 14:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-24 7:40 [PATCH] arm64: kaslr: Reserve size of ARM64_MEMSTART_ALIGN in linear region Yueyi Li
2018-12-24 9:45 ` Ard Biesheuvel
2018-12-25 2:30 ` Yueyi Li
2018-12-26 13:49 ` Ard Biesheuvel
2019-01-16 3:37 ` Yueyi Li
2019-01-16 7:51 ` Ard Biesheuvel
2019-01-16 8:38 ` Yueyi Li
2019-04-13 12:41 ` Nicolas Boichat
2019-04-13 14:38 ` Sasha Levin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190413143807.GV11568@sasha-vm \
--to=sashal@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=drinkcat@chromium.org \
--cc=groeck@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liyueyi@live.com \
--cc=markus@oberhumer.com \
--cc=stable@vger.kernel.org \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).