Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 12 5月, 2014 1 次提交
  3. 17 4月, 2014 1 次提交
  5. 08 4月, 2014 1 次提交
  7. 07 4月, 2014 1 次提交
  9. 26 3月, 2014 3 次提交
  11. 21 3月, 2014 1 次提交
  13. 14 3月, 2014 1 次提交
  15. 26 2月, 2014 1 次提交
    • K
      x86, kaslr: randomize module base load address · e2b32e67
      由 Kees Cook 提交于 
      Randomize the load address of modules in the kernel to make kASLR
effective for modules.  Modules can only be loaded within a particular
range of virtual address space.  This patch adds 10 bits of entropy to
the load address by adding 1-1024 * PAGE_SIZE to the beginning range
where modules are loaded.

The single base offset was chosen because randomizing each module
load ends up wasting/fragmenting memory too much. Prior approaches to
minimizing fragmentation while doing randomization tend to result in
worse entropy than just doing a single base address offset.

Example kASLR boot without this change, with a single module loaded:
---[ Modules ]---
0xffffffffc0000000-0xffffffffc0001000           4K     ro     GLB x  pte
0xffffffffc0001000-0xffffffffc0002000           4K     ro     GLB NX pte
0xffffffffc0002000-0xffffffffc0004000           8K     RW     GLB NX pte
0xffffffffc0004000-0xffffffffc0200000        2032K                   pte
0xffffffffc0200000-0xffffffffff000000        1006M                   pmd
---[ End Modules ]---

Example kASLR boot after this change, same module loaded:
---[ Modules ]---
0xffffffffc0000000-0xffffffffc0200000           2M                   pmd
0xffffffffc0200000-0xffffffffc03bf000        1788K                   pte
0xffffffffc03bf000-0xffffffffc03c0000           4K     ro     GLB x  pte
0xffffffffc03c0000-0xffffffffc03c1000           4K     ro     GLB NX pte
0xffffffffc03c1000-0xffffffffc03c3000           8K     RW     GLB NX pte
0xffffffffc03c3000-0xffffffffc0400000         244K                   pte
0xffffffffc0400000-0xffffffffff000000        1004M                   pmd
---[ End Modules ]---
Signed-off-by: NAndy Honig <ahonig@google.com>
Link: http://lkml.kernel.org/r/20140226005916.GA27083@www.outflux.netSigned-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      e2b32e67
  17. 13 2月, 2014 1 次提交
    • L
      ACPICA: Add boot option to disable auto return object repair · 4dde507f
      由 Lv Zheng 提交于 
      Sometimes, there might be bugs caused by unexpected AML which is compliant
to the Windows but not compliant to the Linux implementation.

There is a predefined validation mechanism implemented in ACPICA to repair
the unexpected AML evaluation results that are caused by the unexpected
AMLs.  For example, BIOS may return misorder _CST result and the repair
mechanism can make an ascending order on the returned _CST package object
based on the C-state type.
This mechanism is quite useful to implement an AML interpreter with better
compliance with the real world where Windows is the de-facto standard and
BIOS codes are only tested on one platform thus not compliant to the
ACPI specification.

But if a compliance issue hasn't been figured out yet, it will be
difficult for developers to identify if the unexpected evaluation result
is caused by this mechanism or by the AML interpreter.
For example, _PR0 is expected to be a control method, but BIOS may use
Package: "Name(_PR0, Package(1) {P1PR})".
This boot option can disable the predefined validation mechanism so that
developers can make sure the root cause comes from the parser/executer.

This patch adds a new kernel parameter to disable this feature.

A build test has been made on a Dell Inspiron mini 1100 (i386 z530)
machine when this patch is applied and the corresponding boot test is
performed w/ or w/o the new kernel parameter specified.

References: https://bugzilla.kernel.org/show_bug.cgi?id=67901Tested-by: NFabian Wehning <fabian.wehning@googlemail.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4dde507f
  19. 07 2月, 2014 1 次提交
  21. 24 1月, 2014 2 次提交
  23. 18 1月, 2014 1 次提交
  25. 16 1月, 2014 2 次提交
    • P
      ACPI / memhotplug: add parameter to disable memory hotplug · 00159a20
      由 Prarit Bhargava 提交于 
      When booting a kexec/kdump kernel on a system that has specific memory
hotplug regions the boot will fail with warnings like:

 swapper/0: page allocation failure: order:9, mode:0x84d0
 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-65.el7.x86_64 #1
 Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.S013.032920111005 03/29/2011
  0000000000000000 ffff8800341bd8c8 ffffffff815bcc67 ffff8800341bd950
  ffffffff8113b1a0 ffff880036339b00 0000000000000009 00000000000084d0
  ffff8800341bd950 ffffffff815b87ee 0000000000000000 0000000000000200
 Call Trace:
  [<ffffffff815bcc67>] dump_stack+0x19/0x1b
  [<ffffffff8113b1a0>] warn_alloc_failed+0xf0/0x160
  [<ffffffff815b87ee>] ?  __alloc_pages_direct_compact+0xac/0x196
  [<ffffffff8113f14f>] __alloc_pages_nodemask+0x7ff/0xa00
  [<ffffffff815b417c>] vmemmap_alloc_block+0x62/0xba
  [<ffffffff815b41e9>] vmemmap_alloc_block_buf+0x15/0x3b
  [<ffffffff815b1ff6>] vmemmap_populate+0xb4/0x21b
  [<ffffffff815b461d>] sparse_mem_map_populate+0x27/0x35
  [<ffffffff815b400f>] sparse_add_one_section+0x7a/0x185
  [<ffffffff815a1e9f>] __add_pages+0xaf/0x240
  [<ffffffff81047359>] arch_add_memory+0x59/0xd0
  [<ffffffff815a21d9>] add_memory+0xb9/0x1b0
  [<ffffffff81333b9c>] acpi_memory_device_add+0x18d/0x26d
  [<ffffffff81309a01>] acpi_bus_device_attach+0x7d/0xcd
  [<ffffffff8132379d>] acpi_ns_walk_namespace+0xc8/0x17f
  [<ffffffff81309984>] ? acpi_bus_type_and_status+0x90/0x90
  [<ffffffff81309984>] ? acpi_bus_type_and_status+0x90/0x90
  [<ffffffff81323c8c>] acpi_walk_namespace+0x95/0xc5
  [<ffffffff8130a6d6>] acpi_bus_scan+0x8b/0x9d
  [<ffffffff81a2019a>] acpi_scan_init+0x63/0x160
  [<ffffffff81a1ffb5>] acpi_init+0x25d/0x2a6
  [<ffffffff81a1fd58>] ? acpi_sleep_proc_init+0x2a/0x2a
  [<ffffffff810020e2>] do_one_initcall+0xe2/0x190
  [<ffffffff819e20c4>] kernel_init_freeable+0x17c/0x207
  [<ffffffff819e18d0>] ? do_early_param+0x88/0x88
  [<ffffffff8159fea0>] ? rest_init+0x80/0x80
  [<ffffffff8159feae>] kernel_init+0xe/0x180
  [<ffffffff815cca2c>] ret_from_fork+0x7c/0xb0
  [<ffffffff8159fea0>] ? rest_init+0x80/0x80
 Mem-Info:
 Node 0 DMA per-cpu:
 CPU    0: hi:    0, btch:   1 usd:   0
 Node 0 DMA32 per-cpu:
 CPU    0: hi:   42, btch:   7 usd:   0
 active_anon:0 inactive_anon:0 isolated_anon:0
  active_file:0 inactive_file:0 isolated_file:0
  unevictable:0 dirty:0 writeback:0 unstable:0
  free:872 slab_reclaimable:13 slab_unreclaimable:1880
  mapped:0 shmem:0 pagetables:0 bounce:0
  free_cma:0

because the system has run out of memory at boot time.  This occurs
because of the following sequence in the boot:

Main kernel boots and sets E820 map.  The second kernel is booted with a
map generated by the kdump service using memmap= and memmap=exactmap.
These parameters are added to the kernel parameters of the kexec/kdump
kernel.   The kexec/kdump kernel has limited memory resources so as not
to severely impact the main kernel.

The system then panics and the kdump/kexec kernel boots (which is a
completely new kernel boot).  During this boot ACPI is initialized and the
kernel (as can be seen above) traverses the ACPI namespace and finds an
entry for a memory device to be hotadded.

ie)

  [<ffffffff815a1e9f>] __add_pages+0xaf/0x240
  [<ffffffff81047359>] arch_add_memory+0x59/0xd0
  [<ffffffff815a21d9>] add_memory+0xb9/0x1b0
  [<ffffffff81333b9c>] acpi_memory_device_add+0x18d/0x26d
  [<ffffffff81309a01>] acpi_bus_device_attach+0x7d/0xcd
  [<ffffffff8132379d>] acpi_ns_walk_namespace+0xc8/0x17f
  [<ffffffff81309984>] ? acpi_bus_type_and_status+0x90/0x90
  [<ffffffff81309984>] ? acpi_bus_type_and_status+0x90/0x90
  [<ffffffff81323c8c>] acpi_walk_namespace+0x95/0xc5
  [<ffffffff8130a6d6>] acpi_bus_scan+0x8b/0x9d
  [<ffffffff81a2019a>] acpi_scan_init+0x63/0x160
  [<ffffffff81a1ffb5>] acpi_init+0x25d/0x2a6

At this point the kernel adds page table information and the the kexec/kdump
kernel runs out of memory.

This can also be reproduced by using the memmap=exactmap and mem=X
parameters on the main kernel and booting.

This patchset resolves the problem by adding a kernel parameter,
acpi_no_memhotplug, to disable ACPI memory hotplug.
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Acked-by: NVivek Goyal <vgoyal@redhat.com>
Acked-by: NToshi Kani <toshi.kani@hp.com>
Acked-by: NDavid Rientjes <rientjes@google.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      00159a20
    • H
      x86, apic, kexec: Add disable_cpu_apicid kernel parameter · 151e0c7d
      由 HATAYAMA Daisuke 提交于 
      Add disable_cpu_apicid kernel parameter. To use this kernel parameter,
specify an initial APIC ID of the corresponding CPU you want to
disable.

This is mostly used for the kdump 2nd kernel to disable BSP to wake up
multiple CPUs without causing system reset or hang due to sending INIT
from AP to BSP.

Kdump users first figure out initial APIC ID of the BSP, CPU0 in the
1st kernel, for example from /proc/cpuinfo and then set up this kernel
parameter for the 2nd kernel using the obtained APIC ID.

However, doing this procedure at each boot time manually is awkward,
which should be automatically done by user-land service scripts, for
example, kexec-tools on fedora/RHEL distributions.

This design is more flexible than disabling BSP in kernel boot time
automatically in that in kernel boot time we have no choice but
referring to ACPI/MP table to obtain initial APIC ID for BSP, meaning
that the method is not applicable to the systems without such BIOS
tables.

One assumption behind this design is that users get initial APIC ID of
the BSP in still healthy state and so BSP is uniquely kept in
CPU0. Thus, through the kernel parameter, only one initial APIC ID can
be specified.

In a comparison with disabled_cpu_apicid, we use read_apic_id(), not
boot_cpu_physical_apicid, because on some platforms, the variable is
modified to the apicid reported as BSP through MP table and this
function is executed with the temporarily modified
boot_cpu_physical_apicid. As a result, disabled_cpu_apicid kernel
parameter doesn't work well for apicids of APs.

Fixing the wrong handling of boot_cpu_physical_apicid requires some
reviews and tests beyond some platforms and it could take some
time. The fix here is a kind of workaround to focus on the main topic
of this patch.
Signed-off-by: NHATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Link: http://lkml.kernel.org/r/20140115064458.1545.38775.stgit@localhost6.localdomain6Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      151e0c7d
  27. 14 1月, 2014 3 次提交
    • E
      audit: documentation of audit= kernel parameter · d7961148
      由 Eric Paris 提交于 
      Further documentation of the 3 possible kernel value of the audit
command line option.
Signed-off-by: NEric Paris <eparis@redhat.com>
      d7961148
    • R
      audit: add kernel set-up parameter to override default backlog limit · f910fde7
      由 Richard Guy Briggs 提交于 
      The default audit_backlog_limit is 64.  This was a reasonable limit at one time.

systemd causes so much audit queue activity on startup that auditd doesn't
start before the backlog queue has already overflowed by more than a factor of
2.  On a system with audit= not set on the kernel command line, this isn't an
issue since that history isn't kept for auditd when it is available.  On a
system with audit=1 set on the kernel command line, kaudit tries to keep that
history until auditd is able to drain the queue.

This default can be changed by the "-b" option in audit.rules once the system
has booted, but won't help with lost messages on boot.

One way to solve this would be to increase the default backlog queue size to
avoid losing any messages before auditd is able to consume them.  This would
be overkill to the embedded community and insufficient for some servers.

Another way to solve it might be to add a kconfig option to set the default
based on the system type.  An embedded system would get the current (or
smaller) default, while Workstations might get more than now and servers might
get more.

None of these solutions helps if a system's compiled default is too small to
see the lost messages without compiling a new kernel.

This patch adds a kernel set-up parameter (audit already has one to
enable/disable it) "audit_backlog_limit=<n>" that overrides the default to
allow the system administrator to set the backlog limit.
Signed-off-by: NRichard Guy Briggs <rgb@redhat.com>
Signed-off-by: NEric Paris <eparis@redhat.com>
      f910fde7
    • R
      documentation: document the audit= kernel start-up parameter · a106fb0c
      由 Richard Guy Briggs 提交于 
      Add the "audit=" kernel start-up parameter to Documentation/kernel-parameters.txt.
Signed-off-by: NRichard Guy Briggs <rgb@redhat.com>
Signed-off-by: NEric Paris <eparis@redhat.com>
      a106fb0c
  29. 31 12月, 2013 1 次提交
  31. 17 12月, 2013 1 次提交
  33. 12 12月, 2013 1 次提交
  35. 04 12月, 2013 1 次提交
  37. 02 12月, 2013 1 次提交
  39. 13 11月, 2013 2 次提交
    • P
      drivers/char/hpet.c: allow user controlled mmap for user processes · 3d035f58
      由 Prarit Bhargava 提交于 
      The CONFIG_HPET_MMAP Kconfig option exposes the memory map of the HPET
registers to userspace.  The Kconfig help points out that in some cases
this can be a security risk as some systems may erroneously configure the
map such that additional data is exposed to userspace.

This is a problem for distributions -- some users want the MMAP
functionality but it comes with a significant security risk.  In an effort
to mitigate this risk, and due to the low number of users of the MMAP
functionality, I've introduced a kernel parameter, hpet_mmap_enable, that
is required in order to actually have the HPET MMAP exposed.
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Acked-by: NMatt Wilson <msw@amazon.com>
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3d035f58
    • T
      mem-hotplug: introduce movable_node boot option · c5320926
      由 Tang Chen 提交于 
      The hot-Pluggable field in SRAT specifies which memory is hotpluggable.
As we mentioned before, if hotpluggable memory is used by the kernel, it
cannot be hot-removed.  So memory hotplug users may want to set all
hotpluggable memory in ZONE_MOVABLE so that the kernel won't use it.

Memory hotplug users may also set a node as movable node, which has
ZONE_MOVABLE only, so that the whole node can be hot-removed.

But the kernel cannot use memory in ZONE_MOVABLE.  By doing this, the
kernel cannot use memory in movable nodes.  This will cause NUMA
performance down.  And other users may be unhappy.

So we need a way to allow users to enable and disable this functionality.
In this patch, we introduce movable_node boot option to allow users to
choose to not to consume hotpluggable memory at early boot time and later
we can set it as ZONE_MOVABLE.

To achieve this, the movable_node boot option will control the memblock
allocation direction.  That said, after memblock is ready, before SRAT is
parsed, we should allocate memory near the kernel image as we explained in
the previous patches.  So if movable_node boot option is set, the kernel
does the following:

1. After memblock is ready, make memblock allocate memory bottom up.
2. After SRAT is parsed, make memblock behave as default, allocate memory
   top down.

Users can specify "movable_node" in kernel commandline to enable this
functionality.  For those who don't use memory hotplug or who don't want
to lose their NUMA performance, just don't specify anything.  The kernel
will work as before.
Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com>
Signed-off-by: NZhang Yanfei <zhangyanfei@cn.fujitsu.com>
Suggested-by: NKamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Suggested-by: NIngo Molnar <mingo@kernel.org>
Acked-by: NTejun Heo <tj@kernel.org>
Acked-by: NToshi Kani <toshi.kani@hp.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Jiang Liu <jiang.liu@huawei.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c5320926
  41. 02 11月, 2013 1 次提交
    • B
      x86/efi: Runtime services virtual mapping · d2f7cbe7
      由 Borislav Petkov 提交于 
      We map the EFI regions needed for runtime services non-contiguously,
with preserved alignment on virtual addresses starting from -4G down
for a total max space of 64G. This way, we provide for stable runtime
services addresses across kernels so that a kexec'd kernel can still use
them.

Thus, they're mapped in a separate pagetable so that we don't pollute
the kernel namespace.

Add an efi= kernel command line parameter for passing miscellaneous
options and chicken bits from the command line.

While at it, add a chicken bit called "efi=old_map" which can be used as
a fallback to the old runtime services mapping method in case there's
some b0rkage with a particular EFI implementation (haha, it is hard to
hold up the sarcasm here...).

Also, add the UEFI RT VA space to Documentation/x86/x86_64/mm.txt.
Signed-off-by: NBorislav Petkov <bp@suse.de>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      d2f7cbe7
  43. 29 10月, 2013 1 次提交
  45. 27 10月, 2013 2 次提交
    • M
      ima: enable support for larger default filedata hash algorithms · e7a2ad7e
      由 Mimi Zohar 提交于 
      The IMA measurement list contains two hashes - a template data hash
and a filedata hash.  The template data hash is committed to the TPM,
which is limited, by the TPM v1.2 specification, to 20 bytes.  The
filedata hash is defined as 20 bytes as well.

Now that support for variable length measurement list templates was
added, the filedata hash is not limited to 20 bytes.  This patch adds
Kconfig support for defining larger default filedata hash algorithms
and replacing the builtin default with one specified on the kernel
command line.

<uapi/linux/hash_info.h> contains a list of hash algorithms.  The
Kconfig default hash algorithm is a subset of this list, but any hash
algorithm included in the list can be specified at boot, using the
'ima_hash=' kernel command line option.

Changelog v2:
- update Kconfig

Changelog:
- support hashes that are configured
- use generic HASH_ALGO_ definitions
- add Kconfig support
- hash_setup must be called only once (Dmitry)
- removed trailing whitespaces (Roberto Sassu)
Signed-off-by: NMimi Zohar <zohar@us.ibm.com>
Signed-off-by: NRoberto Sassu <roberto.sassu@polito.it>
      e7a2ad7e
    • R
      ima: define kernel parameter 'ima_template=' to change configured default · 9b9d4ce5
      由 Roberto Sassu 提交于 
      This patch allows users to specify from the kernel command line the
template descriptor, among those defined, that will be used to generate
and display measurement entries. If an user specifies a wrong template,
IMA reverts to the template descriptor set in the kernel configuration.
Signed-off-by: NRoberto Sassu <roberto.sassu@polito.it>
Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      9b9d4ce5
  47. 18 10月, 2013 1 次提交
  49. 16 10月, 2013 1 次提交
  51. 13 10月, 2013 1 次提交
  53. 01 10月, 2013 2 次提交
  55. 25 9月, 2013 1 次提交
  57. 05 9月, 2013 1 次提交
  59. 24 8月, 2013 1 次提交
  61. 05 8月, 2013 1 次提交
    • C
      vt: make the default color configurable · 3855ae1c
      由 Clemens Ladisch 提交于 
      The virtual console has (undocumented) module parameters to set the
colors for italic and underlined text, but the default text color was
hardcoded for some reason.  This made it impossible to change the color
for startup messages, or to set the default for new virtual consoles.
Add a module parameter for that, and document the entire bunch.

Any hacker who thinks that a command prompt on a "black screen with
white font" is not supicious enough can now use the kernel parameter
vt.color=10 to get a nice, evil green.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3855ae1c