Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1624675 > unrolled thread

[PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr

Started byBaoquan He <bhe@redhat.com>
First post2017-04-17 15:40 +0200
Last post2017-04-24 04:50 +0200
Articles 7 — 2 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr Baoquan He <bhe@redhat.com> - 2017-04-17 15:40 +0200
    Re: [PATCH 0/4] Handle memmap and mem kernel options in boot stage  kaslr Ingo Molnar <mingo@kernel.org> - 2017-04-18 11:50 +0200
      Re: [PATCH 0/4] Handle memmap and mem kernel options in boot stage  kaslr Baoquan He <bhe@redhat.com> - 2017-04-18 13:40 +0200
        Re: [PATCH 0/4] Handle memmap and mem kernel options in boot stage  kaslr Ingo Molnar <mingo@kernel.org> - 2017-04-18 15:00 +0200
          Re: [PATCH 0/4] Handle memmap and mem kernel options in boot stage  kaslr Baoquan He <bhe@redhat.com> - 2017-04-19 02:10 +0200
          Re: [PATCH 0/4] Handle memmap and mem kernel options in boot stage  kaslr Baoquan He <bhe@redhat.com> - 2017-04-20 16:10 +0200
          Re: [PATCH 0/4] Handle memmap and mem kernel options in boot stage  kaslr Baoquan He <bhe@redhat.com> - 2017-04-24 04:50 +0200

#1624675 — [PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr

FromBaoquan He <bhe@redhat.com>
Date2017-04-17 15:40 +0200
Subject[PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr
Message-ID<txf2N-1br-9@gated-at.bofh.it>
People reported kernel panic occurs during system boots up with mem boot option.
After checking code, several problems are found about memmap= and mem= in boot stage
kaslr.

*) In commit f28442497b5c ("x86/boot: Fix KASLR and memmap= collision"), only one memmap
   entry is considered and only the last one if multiple memmap entries are specified.

*) mem= and memmap=nn[KMG] are not considered yet. They are used to limit max address
   of system. Kernel can't be randomized to be above the limit.

*) kernel-parameters.txt doesn't tell the updated behaviour of memmap=.

This patchset tries to solve above issues.

Baoquan He (4):
  param: Move function next_arg to lib/cmdline.c for later reuse
  KASLR: Parse all memmap entries in cmdline
  KASLR: Handle memory limit specified by memmap and mem option
  doc: Update description about memmap option in kernel-parameter.txt

 Documentation/admin-guide/kernel-parameters.txt |   9 ++
 arch/x86/boot/compressed/cmdline.c              |   2 +-
 arch/x86/boot/compressed/kaslr.c                | 161 ++++++++++++++----------
 arch/x86/boot/string.c                          |   8 ++
 include/linux/kernel.h                          |   1 +
 kernel/params.c                                 |  52 --------
 lib/cmdline.c                                   |  57 +++++++++
 7 files changed, 172 insertions(+), 118 deletions(-)

-- 
2.5.5

[toc] | [next] | [standalone]

#1625191 — Re: [PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr

FromIngo Molnar <mingo@kernel.org>
Date2017-04-18 11:50 +0200
SubjectRe: [PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr
Message-ID<txxVL-4zJ-13@gated-at.bofh.it>
In reply to#1624675
* Baoquan He <bhe@redhat.com> wrote:

> People reported kernel panic occurs during system boots up with mem boot option.
> After checking code, several problems are found about memmap= and mem= in boot stage
> kaslr.
> 
> *) In commit f28442497b5c ("x86/boot: Fix KASLR and memmap= collision"), only one memmap
>    entry is considered and only the last one if multiple memmap entries are specified.
> 
> *) mem= and memmap=nn[KMG] are not considered yet. They are used to limit max address
>    of system. Kernel can't be randomized to be above the limit.
> 
> *) kernel-parameters.txt doesn't tell the updated behaviour of memmap=.
> 
> This patchset tries to solve above issues.
> 
> Baoquan He (4):
>   param: Move function next_arg to lib/cmdline.c for later reuse
>   KASLR: Parse all memmap entries in cmdline
>   KASLR: Handle memory limit specified by memmap and mem option
>   doc: Update description about memmap option in kernel-parameter.txt
> 
>  Documentation/admin-guide/kernel-parameters.txt |   9 ++
>  arch/x86/boot/compressed/cmdline.c              |   2 +-
>  arch/x86/boot/compressed/kaslr.c                | 161 ++++++++++++++----------
>  arch/x86/boot/string.c                          |   8 ++
>  include/linux/kernel.h                          |   1 +
>  kernel/params.c                                 |  52 --------
>  lib/cmdline.c                                   |  57 +++++++++
>  7 files changed, 172 insertions(+), 118 deletions(-)

I ported this series to tip:x86/boot (please post future versions against that), 
and beyond a trivial conflict with e820entry => e820_entry, it fails to build on 
32-bit allmodconfig:

  ld: -r and -shared may not be used together
  scripts/Makefile.build:294: recipe for target 'arch/x86/boot/compressed/kaslr.o' failed

... which could be due to bad relocations, but I've not dug any further.

Please also pick up the fixed/rewritten changelogs from the git log below for the 
next version.

Thanks,

	Ingo

====================>

Documentation/kernel-parameters.txt: Update 'memmap=' option description

In commit:

  9710f581bb4c ("x86, mm: Let "memmap=" take more entries one time")

... 'memmap=' was changed to adopt multiple, comma delimited values in a
single entry, so update the related description.

In the special case of only specifying size value without an offset,
like memmap=nn[KMG], memmap behaves similarly to mem=nn[KMG], so update
it too here.

Furthermore, for memmap=nn[KMG]$ss[KMG], an escape character needs be added
before '$' for some bootloaders. E.g in grub2, if we specify memmap=100M$5G
as suggested by the documentation, "memmap=100MG" gets passed to the kernel.

Clarify all this.

----

KASLR: Handle memory limit specified by memmap and mem option

Option mem= will limit the max address a system can use and any memory
region above the limit will be removed.

Furthermore, memmap=nn[KMG] which has no offset specified has the same
behaviour as mem=.

KASLR needs to consider this when choosing the random position for
decompressing the kernel.

This patch implements that.

----

KASLR: Parse all memmap entries in cmdline

In commit:

  f28442497b5c ("x86/boot: Fix KASLR and memmap= collision")

... the memmap= option is parsed so that KASLR can avoid those reserved
regions. It uses cmdline_find_option() to get the value if memmap=
is specified, however the problem is that cmdline_find_option() can only
find the last entry if multiple memmap entries are provided. This
is not correct.

In this patch, the whole cmdline will be scanned to search each
memmap, all of them will be parsed and handled.

----

boot/param: Move next_arg() function to lib/cmdline.c for later reuse

next_arg() will be used to parse boot parameters in the x86/boot/compressed code,
so move it to lib/cmdline.c for better code reuse.

No change in functionality.

[toc] | [prev] | [next] | [standalone]

#1625278 — Re: [PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr

FromBaoquan He <bhe@redhat.com>
Date2017-04-18 13:40 +0200
SubjectRe: [PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr
Message-ID<txzEd-5Dd-5@gated-at.bofh.it>
In reply to#1625191
On 04/18/17 at 11:47am, Ingo Molnar wrote:
> 
> * Baoquan He <bhe@redhat.com> wrote:
> 
> > People reported kernel panic occurs during system boots up with mem boot option.
> > After checking code, several problems are found about memmap= and mem= in boot stage
> > kaslr.
> > 
> > *) In commit f28442497b5c ("x86/boot: Fix KASLR and memmap= collision"), only one memmap
> >    entry is considered and only the last one if multiple memmap entries are specified.
> > 
> > *) mem= and memmap=nn[KMG] are not considered yet. They are used to limit max address
> >    of system. Kernel can't be randomized to be above the limit.
> > 
> > *) kernel-parameters.txt doesn't tell the updated behaviour of memmap=.
> > 
> > This patchset tries to solve above issues.
> > 
> > Baoquan He (4):
> >   param: Move function next_arg to lib/cmdline.c for later reuse
> >   KASLR: Parse all memmap entries in cmdline
> >   KASLR: Handle memory limit specified by memmap and mem option
> >   doc: Update description about memmap option in kernel-parameter.txt
> > 
> >  Documentation/admin-guide/kernel-parameters.txt |   9 ++
> >  arch/x86/boot/compressed/cmdline.c              |   2 +-
> >  arch/x86/boot/compressed/kaslr.c                | 161 ++++++++++++++----------
> >  arch/x86/boot/string.c                          |   8 ++
> >  include/linux/kernel.h                          |   1 +
> >  kernel/params.c                                 |  52 --------
> >  lib/cmdline.c                                   |  57 +++++++++
> >  7 files changed, 172 insertions(+), 118 deletions(-)
> 
> I ported this series to tip:x86/boot (please post future versions against that), 
> and beyond a trivial conflict with e820entry => e820_entry, it fails to build on 
> 32-bit allmodconfig:
> 
>   ld: -r and -shared may not be used together
>   scripts/Makefile.build:294: recipe for target 'arch/x86/boot/compressed/kaslr.o' failed
> 
> ... which could be due to bad relocations, but I've not dug any further.

Thanks, Ingo!

I will find a x86_32 system to try allmodconfig.

> 
> Please also pick up the fixed/rewritten changelogs from the git log below for the 
> next version.

Will do, thanks a lot!

> 
> Thanks,
> 
> 	Ingo
> 
> ====================>
> 
> Documentation/kernel-parameters.txt: Update 'memmap=' option description
> 
> In commit:
> 
>   9710f581bb4c ("x86, mm: Let "memmap=" take more entries one time")
> 
> ... 'memmap=' was changed to adopt multiple, comma delimited values in a
> single entry, so update the related description.
> 
> In the special case of only specifying size value without an offset,
> like memmap=nn[KMG], memmap behaves similarly to mem=nn[KMG], so update
> it too here.
> 
> Furthermore, for memmap=nn[KMG]$ss[KMG], an escape character needs be added
> before '$' for some bootloaders. E.g in grub2, if we specify memmap=100M$5G
> as suggested by the documentation, "memmap=100MG" gets passed to the kernel.
> 
> Clarify all this.
> 
> ----
> 
> KASLR: Handle memory limit specified by memmap and mem option
> 
> Option mem= will limit the max address a system can use and any memory
> region above the limit will be removed.
> 
> Furthermore, memmap=nn[KMG] which has no offset specified has the same
> behaviour as mem=.
> 
> KASLR needs to consider this when choosing the random position for
> decompressing the kernel.
> 
> This patch implements that.
> 
> ----
> 
> KASLR: Parse all memmap entries in cmdline
> 
> In commit:
> 
>   f28442497b5c ("x86/boot: Fix KASLR and memmap= collision")
> 
> ... the memmap= option is parsed so that KASLR can avoid those reserved
> regions. It uses cmdline_find_option() to get the value if memmap=
> is specified, however the problem is that cmdline_find_option() can only
> find the last entry if multiple memmap entries are provided. This
> is not correct.
> 
> In this patch, the whole cmdline will be scanned to search each
> memmap, all of them will be parsed and handled.
> 
> ----
> 
> boot/param: Move next_arg() function to lib/cmdline.c for later reuse
> 
> next_arg() will be used to parse boot parameters in the x86/boot/compressed code,
> so move it to lib/cmdline.c for better code reuse.
> 
> No change in functionality.
>

[toc] | [prev] | [next] | [standalone]

#1625309 — Re: [PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr

FromIngo Molnar <mingo@kernel.org>
Date2017-04-18 15:00 +0200
SubjectRe: [PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr
Message-ID<txATE-6he-17@gated-at.bofh.it>
In reply to#1625278
* Baoquan He <bhe@redhat.com> wrote:

> On 04/18/17 at 11:47am, Ingo Molnar wrote:
> > 
> > * Baoquan He <bhe@redhat.com> wrote:
> > 
> > > People reported kernel panic occurs during system boots up with mem boot option.
> > > After checking code, several problems are found about memmap= and mem= in boot stage
> > > kaslr.
> > > 
> > > *) In commit f28442497b5c ("x86/boot: Fix KASLR and memmap= collision"), only one memmap
> > >    entry is considered and only the last one if multiple memmap entries are specified.
> > > 
> > > *) mem= and memmap=nn[KMG] are not considered yet. They are used to limit max address
> > >    of system. Kernel can't be randomized to be above the limit.
> > > 
> > > *) kernel-parameters.txt doesn't tell the updated behaviour of memmap=.
> > > 
> > > This patchset tries to solve above issues.
> > > 
> > > Baoquan He (4):
> > >   param: Move function next_arg to lib/cmdline.c for later reuse
> > >   KASLR: Parse all memmap entries in cmdline
> > >   KASLR: Handle memory limit specified by memmap and mem option
> > >   doc: Update description about memmap option in kernel-parameter.txt
> > > 
> > >  Documentation/admin-guide/kernel-parameters.txt |   9 ++
> > >  arch/x86/boot/compressed/cmdline.c              |   2 +-
> > >  arch/x86/boot/compressed/kaslr.c                | 161 ++++++++++++++----------
> > >  arch/x86/boot/string.c                          |   8 ++
> > >  include/linux/kernel.h                          |   1 +
> > >  kernel/params.c                                 |  52 --------
> > >  lib/cmdline.c                                   |  57 +++++++++
> > >  7 files changed, 172 insertions(+), 118 deletions(-)
> > 
> > I ported this series to tip:x86/boot (please post future versions against that), 
> > and beyond a trivial conflict with e820entry => e820_entry, it fails to build on 
> > 32-bit allmodconfig:
> > 
> >   ld: -r and -shared may not be used together
> >   scripts/Makefile.build:294: recipe for target 'arch/x86/boot/compressed/kaslr.o' failed
> > 
> > ... which could be due to bad relocations, but I've not dug any further.
> 
> Thanks, Ingo!
> 
> I will find a x86_32 system to try allmodconfig.

No need, on a 64-bit system just do:

	make ARCH=i386 allmodconfig

and build the kernel the regular way.

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1625740 — Re: [PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr

FromBaoquan He <bhe@redhat.com>
Date2017-04-19 02:10 +0200
SubjectRe: [PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr
Message-ID<txLm2-4su-7@gated-at.bofh.it>
In reply to#1625309
On 04/18/17 at 02:51pm, Ingo Molnar wrote:
> > > I ported this series to tip:x86/boot (please post future versions against that), 
> > > and beyond a trivial conflict with e820entry => e820_entry, it fails to build on 
> > > 32-bit allmodconfig:
> > > 
> > >   ld: -r and -shared may not be used together
> > >   scripts/Makefile.build:294: recipe for target 'arch/x86/boot/compressed/kaslr.o' failed
> > > 
> > > ... which could be due to bad relocations, but I've not dug any further.
> > 
> > Thanks, Ingo!
> > 
> > I will find a x86_32 system to try allmodconfig.
> 
> No need, on a 64-bit system just do:
> 
> 	make ARCH=i386 allmodconfig
> 
> and build the kernel the regular way.

Thanks, trying.

[toc] | [prev] | [next] | [standalone]

#1627487 — Re: [PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr

FromBaoquan He <bhe@redhat.com>
Date2017-04-20 16:10 +0200
SubjectRe: [PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr
Message-ID<tykWt-1uY-3@gated-at.bofh.it>
In reply to#1625309
On 04/18/17 at 02:51pm, Ingo Molnar wrote:
> 
> * Baoquan He <bhe@redhat.com> wrote:
> 
> > On 04/18/17 at 11:47am, Ingo Molnar wrote:
> > > 
> > > * Baoquan He <bhe@redhat.com> wrote:
> > > 
> > > > People reported kernel panic occurs during system boots up with mem boot option.
> > > > After checking code, several problems are found about memmap= and mem= in boot stage
> > > > kaslr.
> > > > 
> > > > *) In commit f28442497b5c ("x86/boot: Fix KASLR and memmap= collision"), only one memmap
> > > >    entry is considered and only the last one if multiple memmap entries are specified.
> > > > 
> > > > *) mem= and memmap=nn[KMG] are not considered yet. They are used to limit max address
> > > >    of system. Kernel can't be randomized to be above the limit.
> > > > 
> > > > *) kernel-parameters.txt doesn't tell the updated behaviour of memmap=.
> > > > 
> > > > This patchset tries to solve above issues.
> > > > 
> > > > Baoquan He (4):
> > > >   param: Move function next_arg to lib/cmdline.c for later reuse
> > > >   KASLR: Parse all memmap entries in cmdline
> > > >   KASLR: Handle memory limit specified by memmap and mem option
> > > >   doc: Update description about memmap option in kernel-parameter.txt
> > > > 
> > > >  Documentation/admin-guide/kernel-parameters.txt |   9 ++
> > > >  arch/x86/boot/compressed/cmdline.c              |   2 +-
> > > >  arch/x86/boot/compressed/kaslr.c                | 161 ++++++++++++++----------
> > > >  arch/x86/boot/string.c                          |   8 ++
> > > >  include/linux/kernel.h                          |   1 +
> > > >  kernel/params.c                                 |  52 --------
> > > >  lib/cmdline.c                                   |  57 +++++++++
> > > >  7 files changed, 172 insertions(+), 118 deletions(-)
> > > 
> > > I ported this series to tip:x86/boot (please post future versions against that), 
> > > and beyond a trivial conflict with e820entry => e820_entry, it fails to build on 
> > > 32-bit allmodconfig:
> > > 
> > >   ld: -r and -shared may not be used together
> > >   scripts/Makefile.build:294: recipe for target 'arch/x86/boot/compressed/kaslr.o' failed
> > > 
> > > ... which could be due to bad relocations, but I've not dug any further.
> > 
> > Thanks, Ingo!
> > 
> > I will find a x86_32 system to try allmodconfig.
> 
> No need, on a 64-bit system just do:
> 
> 	make ARCH=i386 allmodconfig
> 
> and build the kernel the regular way.

Sorry for late update. I tried on a x86 64 system with "make ARCH=i386
allmodconfig", and saw the ld warning.  I added a '-r' after -pie, the
building passed. Seems including lib/ctype.c or lib/cmdline.c caused
this. Will dig further to see what's going on.

ifeq ($(CONFIG_X86_32),y)      
LDFLAGS += $(call ld-option, -pie -r) $(call ld-option, --no-dynamic-linker)
else

Thanks
Baoquan

[toc] | [prev] | [next] | [standalone]

#1629128 — Re: [PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr

FromBaoquan He <bhe@redhat.com>
Date2017-04-24 04:50 +0200
SubjectRe: [PATCH 0/4] Handle memmap and mem kernel options in boot stage kaslr
Message-ID<tzCeB-HU-1@gated-at.bofh.it>
In reply to#1625309
On 04/18/17 at 02:51pm, Ingo Molnar wrote:
> 
> * Baoquan He <bhe@redhat.com> wrote:
> 
> > On 04/18/17 at 11:47am, Ingo Molnar wrote:
> > > I ported this series to tip:x86/boot (please post future versions against that), 
> > > and beyond a trivial conflict with e820entry => e820_entry, it fails to build on 
> > > 32-bit allmodconfig:
> > > 
> > >   ld: -r and -shared may not be used together
> > >   scripts/Makefile.build:294: recipe for target 'arch/x86/boot/compressed/kaslr.o' failed
> > > 
> > > ... which could be due to bad relocations, but I've not dug any further.
> > 
> > Thanks, Ingo!
> > 
> > I will find a x86_32 system to try allmodconfig.
> 
> No need, on a 64-bit system just do:
> 
> 	make ARCH=i386 allmodconfig

Those EXPORT_SYMBOL(sym) in lib/ctype.c|cmdline.c caused this build
failure. I added below code to skip linux/export.h including, it works.
However I haven't found out why EXPORT_SYMBOL in boot stage caused the
failure.

#define _LINUX_EXPORT_H
#define EXPORT_SYMBOL(sym)

> 
> and build the kernel the regular way.
> 
> Thanks,
> 
> 	Ingo

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web