Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1549609 > unrolled thread
| Started by | Baoquan He <bhe@redhat.com> |
|---|---|
| First post | 2017-01-03 09:40 +0100 |
| Last post | 2017-01-04 03:00 +0100 |
| Articles | 5 — 4 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH] x86: fix kaslr and memmap collision Baoquan He <bhe@redhat.com> - 2017-01-03 09:40 +0100
Re: [PATCH] x86: fix kaslr and memmap collision Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-01-03 17:30 +0100
Re: [PATCH] x86: fix kaslr and memmap collision Dan Williams <dan.j.williams@intel.com> - 2017-01-03 19:30 +0100
Re: [PATCH] x86: fix kaslr and memmap collision Dave Jiang <dave.jiang@intel.com> - 2017-01-03 21:20 +0100
Re: [PATCH] x86: fix kaslr and memmap collision Baoquan He <bhe@redhat.com> - 2017-01-04 03:00 +0100
| From | Baoquan He <bhe@redhat.com> |
|---|---|
| Date | 2017-01-03 09:40 +0100 |
| Subject | Re: [PATCH] x86: fix kaslr and memmap collision |
| Message-ID | <sVsNr-3qW-5@gated-at.bofh.it> |
Hi Dan, On 11/22/16 at 09:26am, Dan Williams wrote: > [ replying for Dave since he's offline today and tomorrow ] > > On Tue, Nov 22, 2016 at 12:47 AM, Ingo Molnar <mingo@kernel.org> wrote: > > > > * Dave Jiang <dave.jiang@intel.com> wrote: > > > >> CONFIG_RANDOMIZE_BASE relocates the kernel to a random base address. > >> However it does not take into account the memmap= parameter passed in from > >> the kernel commandline. > > > > memmap= parameters are often used as a list. > > > >> [...] This results in the kernel sometimes being put in the middle of the user > >> memmap. [...] > > > > What does this mean? If memmap= is used to re-define the memory map then the > > kernel getting in the middle of a RAM area is what we want, isn't it? What we > > don't want is for the kernel to get into reserved areas, right? > > Right, this is about teaching kaslr to not land the kernel in newly > defined reserved regions that were not marked reserved in the initial > e820 map from platform firmware. If only tell kaslr to not land kernel in newly defined reserved regions, memory added by "memmap=nn[KMG]@ss[KMG]" should not be avoided since it's usable memory. Kernel randomized into this region is also what we want. Not sure if I understand it right. Thanks Baoquan
[toc] | [next] | [standalone]
| From | Ross Zwisler <ross.zwisler@linux.intel.com> |
|---|---|
| Date | 2017-01-03 17:30 +0100 |
| Message-ID | <sVA8i-ua-13@gated-at.bofh.it> |
| In reply to | #1549609 |
On Tue, Jan 03, 2017 at 04:31:37PM +0800, Baoquan He wrote:
> Hi Dan,
>
> On 11/22/16 at 09:26am, Dan Williams wrote:
> > [ replying for Dave since he's offline today and tomorrow ]
> >
> > On Tue, Nov 22, 2016 at 12:47 AM, Ingo Molnar <mingo@kernel.org> wrote:
> > >
> > > * Dave Jiang <dave.jiang@intel.com> wrote:
> > >
> > >> CONFIG_RANDOMIZE_BASE relocates the kernel to a random base address.
> > >> However it does not take into account the memmap= parameter passed in from
> > >> the kernel commandline.
> > >
> > > memmap= parameters are often used as a list.
> > >
> > >> [...] This results in the kernel sometimes being put in the middle of the user
> > >> memmap. [...]
> > >
> > > What does this mean? If memmap= is used to re-define the memory map then the
> > > kernel getting in the middle of a RAM area is what we want, isn't it? What we
> > > don't want is for the kernel to get into reserved areas, right?
> >
> > Right, this is about teaching kaslr to not land the kernel in newly
> > defined reserved regions that were not marked reserved in the initial
> > e820 map from platform firmware.
>
> If only tell kaslr to not land kernel in newly defined reserved regions,
> memory added by "memmap=nn[KMG]@ss[KMG]" should not be avoided since
> it's usable memory. Kernel randomized into this region is also what we
> want. Not sure if I understand it right.
The following text is from:
https://nvdimm.wiki.kernel.org/how_to_choose_the_correct_memmap_kernel_parameter_for_pmem_on_your_system
Hopefully this will make it clearer.
---
Another thing that you may need to be aware of is the CONFIG_RANDOMIZE_BASE
kernel config option. When enabled, this randomizes the physical address at
which the kernel image is decompressed and the virtual address where the kernel
image is mapped. Currently this random address is chosen without regard to the
memmap kernel command line parameter.
This means that the kernel can choose to put itself in the middle of your
reserved memmap area. You can observe this behavior via /proc/iomem.
Here is /proc/iomem from a system with CONFIG_RANDOMIZE_BASE turned off:
# cat /proc/iomem
00000000-00000fff : reserved
00001000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : PCI Bus 0000:00
000c0000-000c97ff : Video ROM
000c9800-000ca5ff : Adapter ROM
000ca800-000ccbff : Adapter ROM
000f0000-000fffff : reserved
000f0000-000fffff : System ROM
00100000-bffd8fff : System RAM
01000000-01b18598 : Kernel code
01b18599-023f53ff : Kernel data
0276d000-0365efff : Kernel bss
bffd9000-bfffffff : reserved
c0000000-febfffff : PCI Bus 0000:00
f4000000-f7ffffff : 0000:00:02.0
f8000000-fbffffff : 0000:00:02.0
fc000000-fc03ffff : 0000:00:03.0
fc050000-fc051fff : 0000:00:02.0
fc052000-fc052fff : 0000:00:03.0
fc053000-fc053fff : 0000:00:04.0
fc054000-fc054fff : 0000:00:05.7
fc054000-fc054fff : ehci_hcd
fc055000-fc055fff : 0000:00:06.0
fec00000-fec003ff : IOAPIC 0
fee00000-fee00fff : Local APIC
feffc000-feffffff : reserved
fffc0000-ffffffff : reserved
100000000-4ffffffff : Persistent Memory (legacy)
100000000-4ffffffff : namespace0.0
500000000-53fffffff : System RAM
The interesting bits for us are the “System RAM” region from 00100000-bffd8fff,
and the “Persistent Memory (legacy)” region from 100000000-4ffffffff.
If I turn on CONFIG_RANDOMIZE_BASE on this same system, I get the following:
# cat /proc/iomem
00000000-00000fff : reserved
00001000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : PCI Bus 0000:00
000c0000-000c97ff : Video ROM
000c9800-000ca5ff : Adapter ROM
000ca800-000ccbff : Adapter ROM
000f0000-000fffff : reserved
000f0000-000fffff : System ROM
00100000-bffd8fff : System RAM
bffd9000-bfffffff : reserved
c0000000-febfffff : PCI Bus 0000:00
f4000000-f7ffffff : 0000:00:02.0
f8000000-fbffffff : 0000:00:02.0
fc000000-fc03ffff : 0000:00:03.0
fc050000-fc051fff : 0000:00:02.0
fc052000-fc052fff : 0000:00:03.0
fc053000-fc053fff : 0000:00:04.0
fc054000-fc054fff : 0000:00:05.7
fc054000-fc054fff : ehci_hcd
fc055000-fc055fff : 0000:00:06.0
fec00000-fec003ff : IOAPIC 0
fee00000-fee00fff : Local APIC
feffc000-feffffff : reserved
fffc0000-ffffffff : reserved
100000000-4e6ffffff : Persistent Memory (legacy)
4e7000000-4e968bfff : System RAM
4e7000000-4e7b185d8 : Kernel code
4e7b185d9-4e83f54bf : Kernel data
4e876d000-4e965efff : Kernel bss
4e968c000-4ffffffff : Persistent Memory (legacy)
500000000-53fffffff : System RAM
The “System RAM” region now sits in the middle of my “Persistent Memory
(legacy)” region, splitting it in half. This results in the following kernel
WARNING:
[ 6.356180] WARNING: CPU: 4 PID: 689 at kernel/memremap.c:300 devm_memremap_pages+0x3b2/0x4c0
[ 6.357757] devm_memremap_pages attempted on mixed region [mem 0x4e968c000-0x4ffffffff flags 0x200]
and no /dev/pmem* devices being created.
[toc] | [prev] | [next] | [standalone]
| From | Dan Williams <dan.j.williams@intel.com> |
|---|---|
| Date | 2017-01-03 19:30 +0100 |
| Message-ID | <sVC0p-1Og-17@gated-at.bofh.it> |
| In reply to | #1549609 |
On Tue, Jan 3, 2017 at 12:31 AM, Baoquan He <bhe@redhat.com> wrote: > Hi Dan, > > On 11/22/16 at 09:26am, Dan Williams wrote: >> [ replying for Dave since he's offline today and tomorrow ] >> >> On Tue, Nov 22, 2016 at 12:47 AM, Ingo Molnar <mingo@kernel.org> wrote: >> > >> > * Dave Jiang <dave.jiang@intel.com> wrote: >> > >> >> CONFIG_RANDOMIZE_BASE relocates the kernel to a random base address. >> >> However it does not take into account the memmap= parameter passed in from >> >> the kernel commandline. >> > >> > memmap= parameters are often used as a list. >> > >> >> [...] This results in the kernel sometimes being put in the middle of the user >> >> memmap. [...] >> > >> > What does this mean? If memmap= is used to re-define the memory map then the >> > kernel getting in the middle of a RAM area is what we want, isn't it? What we >> > don't want is for the kernel to get into reserved areas, right? >> >> Right, this is about teaching kaslr to not land the kernel in newly >> defined reserved regions that were not marked reserved in the initial >> e820 map from platform firmware. > > If only tell kaslr to not land kernel in newly defined reserved regions, > memory added by "memmap=nn[KMG]@ss[KMG]" should not be avoided since > it's usable memory. Kernel randomized into this region is also what we > want. Not sure if I understand it right. You're right, this is supposed to be for memmap=nn!ss cases which defines reserved persistent memory ranges, not memmap=nn@ss which defines usable memory. We need to fix mem_avoid_memmap() to only skip memmap= statements that specify reserved memory.
[toc] | [prev] | [next] | [standalone]
| From | Dave Jiang <dave.jiang@intel.com> |
|---|---|
| Date | 2017-01-03 21:20 +0100 |
| Message-ID | <sVDIR-30E-9@gated-at.bofh.it> |
| In reply to | #1550067 |
On 01/03/2017 11:24 AM, Dan Williams wrote: > On Tue, Jan 3, 2017 at 12:31 AM, Baoquan He <bhe@redhat.com> wrote: >> Hi Dan, >> >> On 11/22/16 at 09:26am, Dan Williams wrote: >>> [ replying for Dave since he's offline today and tomorrow ] >>> >>> On Tue, Nov 22, 2016 at 12:47 AM, Ingo Molnar <mingo@kernel.org> wrote: >>>> >>>> * Dave Jiang <dave.jiang@intel.com> wrote: >>>> >>>>> CONFIG_RANDOMIZE_BASE relocates the kernel to a random base address. >>>>> However it does not take into account the memmap= parameter passed in from >>>>> the kernel commandline. >>>> >>>> memmap= parameters are often used as a list. >>>> >>>>> [...] This results in the kernel sometimes being put in the middle of the user >>>>> memmap. [...] >>>> >>>> What does this mean? If memmap= is used to re-define the memory map then the >>>> kernel getting in the middle of a RAM area is what we want, isn't it? What we >>>> don't want is for the kernel to get into reserved areas, right? >>> >>> Right, this is about teaching kaslr to not land the kernel in newly >>> defined reserved regions that were not marked reserved in the initial >>> e820 map from platform firmware. >> >> If only tell kaslr to not land kernel in newly defined reserved regions, >> memory added by "memmap=nn[KMG]@ss[KMG]" should not be avoided since >> it's usable memory. Kernel randomized into this region is also what we >> want. Not sure if I understand it right. > > You're right, this is supposed to be for memmap=nn!ss cases which > defines reserved persistent memory ranges, not memmap=nn@ss which > defines usable memory. > > We need to fix mem_avoid_memmap() to only skip memmap= statements that > specify reserved memory. > I think nn@ss is the only one that we should skip over, otherwise everything else looks like should be avoided. I'll update.
[toc] | [prev] | [next] | [standalone]
| From | Baoquan He <bhe@redhat.com> |
|---|---|
| Date | 2017-01-04 03:00 +0100 |
| Message-ID | <sVJ1T-6fS-9@gated-at.bofh.it> |
| In reply to | #1550152 |
On 01/03/17 at 01:15pm, Dave Jiang wrote: > > > On 01/03/2017 11:24 AM, Dan Williams wrote: > > On Tue, Jan 3, 2017 at 12:31 AM, Baoquan He <bhe@redhat.com> wrote: > >> Hi Dan, > >> > >> On 11/22/16 at 09:26am, Dan Williams wrote: > >>> [ replying for Dave since he's offline today and tomorrow ] > >>> > >>> On Tue, Nov 22, 2016 at 12:47 AM, Ingo Molnar <mingo@kernel.org> wrote: > >>>> > >>>> * Dave Jiang <dave.jiang@intel.com> wrote: > >>>> > >>>>> CONFIG_RANDOMIZE_BASE relocates the kernel to a random base address. > >>>>> However it does not take into account the memmap= parameter passed in from > >>>>> the kernel commandline. > >>>> > >>>> memmap= parameters are often used as a list. > >>>> > >>>>> [...] This results in the kernel sometimes being put in the middle of the user > >>>>> memmap. [...] > >>>> > >>>> What does this mean? If memmap= is used to re-define the memory map then the > >>>> kernel getting in the middle of a RAM area is what we want, isn't it? What we > >>>> don't want is for the kernel to get into reserved areas, right? > >>> > >>> Right, this is about teaching kaslr to not land the kernel in newly > >>> defined reserved regions that were not marked reserved in the initial > >>> e820 map from platform firmware. > >> > >> If only tell kaslr to not land kernel in newly defined reserved regions, > >> memory added by "memmap=nn[KMG]@ss[KMG]" should not be avoided since > >> it's usable memory. Kernel randomized into this region is also what we > >> want. Not sure if I understand it right. > > > > You're right, this is supposed to be for memmap=nn!ss cases which > > defines reserved persistent memory ranges, not memmap=nn@ss which > > defines usable memory. > > > > We need to fix mem_avoid_memmap() to only skip memmap= statements that > > specify reserved memory. Thanks for confirmation, Dan! > > > > I think nn@ss is the only one that we should skip over, otherwise > everything else looks like should be avoided. I'll update. Hi Dave, I guess your purpose is to avoid the user defined reserved memory and pmem which I am not very sure about since kaslr won't stamp on ACPI region reported by BIOS. Seems OK to avoid them all except of nn@ss. I have other concerns, will directly comment in your v4 post. Thanks Baoquan
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web