Date   

Re: Update week 47

Daniel Sangorrin
 

Hi,

(Cc'ed to Fuego and LTSI mailing lists).

-----Original Message-----
From: cip-dev-bounces@lists.cip-project.org [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Agustin Benito Bethencourt
Sent: Sunday, November 27, 2016 8:17 PM
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] Update week 47
...
++ Testing

* The testing project has been created in Gitlab. A couple of
colleagues at Codethink has picked up the initial effort done by Siemens
and move it forward, in order to create a virtual machine with kernelci[2].
**The goal of the first milestone is that any developer with a board at
her desk can test a kernel and see the results of those tests in her own
machine.
** A tutorial will be published for those of you not familiar with the
tools involved.

If you are interested in using kernelci in your company, please join our
effort. Collaboration is working.
[2] https://gitlab.com/cip-project/testing/tree/master
I am planning to add support for kernel-ci on Fuego (Jenkins + a bunch of tests)
using "https://ci.linaro.org/view/kernel-ci/" as a reference. That is, Fuego will git-trigger
and perform kernel builds, and then send the results to a kernel-ci server (e.g. a
local vagrant server or https://kernelci.org) using its REST API.

My short-term vision is:

[Fuego@toshiba]
.... ----build results--------> [Kernel-ci@server]
[Fuego@<company X>]

Fuego can also be used for visualizing the local build results (maybe not as pretty as kernel-ci's dashboard) but
as far as I know it doesn't have the kind of back-end API that kernel-ci has. For that reason, although for
local testing Fuego is enough, we need a way to publish the results (mostly so that
maintainers can see them).

However, my long-term vision would be:

[Fuego@toshiba]
.... ----build/boot/LTP/Cyclictest/other_tests results--------> [Fuego OR modified kernel-ci@server]
[Fuego@<company X>]

In other words, Build and Boot tests are good but not enough. There are many other tests that we
want to run (e.g. tests in Fuego for both the kernel and the root filesystem). I can see at least two options
for implementing that:
Option 1: Extend kernel-ci to support other type of tests.
Option 2: Add a backend REST API to Fuego similar to the one kernel-ci has.

Any feedback would be welcome.

Best regards,
Daniel

[1] http://bird.org/ffiles/Introduction-to-Fuego-LCJ-2016.pdf


Re: [Fuego] Update week 47

Bird, Timothy <Tim.Bird@...>
 

-----Original Message-----
From: fuego-bounces@lists.linuxfoundation.org [mailto:fuego-
bounces@lists.linuxfoundation.org] On Behalf Of Daniel Sangorrin
Sent: Tuesday, November 29, 2016 12:29 PM
To: 'Agustin Benito Bethencourt' <agustin.benito@codethink.co.uk>; cip-
dev@lists.cip-project.org
Cc: ltsi-dev@lists.linuxfoundation.org; fuego@lists.linuxfoundation.org
Subject: Re: [Fuego] [cip-dev] Update week 47

Hi,

(Cc'ed to Fuego and LTSI mailing lists).

-----Original Message-----
From: cip-dev-bounces@lists.cip-project.org [mailto:cip-dev-
bounces@lists.cip-project.org] On Behalf Of Agustin Benito Bethencourt
Sent: Sunday, November 27, 2016 8:17 PM
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] Update week 47
...
++ Testing

* The testing project has been created in Gitlab. A couple of
colleagues at Codethink has picked up the initial effort done by Siemens
and move it forward, in order to create a virtual machine with kernelci[2].
**The goal of the first milestone is that any developer with a board at
her desk can test a kernel and see the results of those tests in her own
machine.
** A tutorial will be published for those of you not familiar with the
tools involved.

If you are interested in using kernelci in your company, please join our
effort. Collaboration is working.
[2] https://gitlab.com/cip-project/testing/tree/master
I am planning to add support for kernel-ci on Fuego (Jenkins + a bunch of
tests)
using "https://ci.linaro.org/view/kernel-ci/" as a reference. That is, Fuego will
git-trigger
and perform kernel builds, and then send the results to a kernel-ci server
(e.g. a
local vagrant server or https://kernelci.org) using its REST API.

My short-term vision is:

[Fuego@toshiba]
.... ----build results--------> [Kernel-ci@server]
[Fuego@<company X>]

Fuego can also be used for visualizing the local build results (maybe not as
pretty as kernel-ci's dashboard) but
as far as I know it doesn't have the kind of back-end API that kernel-ci has.
For that reason, although for
local testing Fuego is enough, we need a way to publish the results (mostly
so that
maintainers can see them).

However, my long-term vision would be:

[Fuego@toshiba]
.... ----build/boot/LTP/Cyclictest/other_tests results-------->
[Fuego OR modified kernel-ci@server]
[Fuego@<company X>]

In other words, Build and Boot tests are good but not enough. There are
many other tests that we
want to run (e.g. tests in Fuego for both the kernel and the root filesystem).
I can see at least two options
for implementing that:
Option 1: Extend kernel-ci to support other type of tests.
Option 2: Add a backend REST API to Fuego similar to the one kernel-ci has.

Any feedback would be welcome.
This sounds really great.

I would really like to see how the two systems (kernelci and fuego) could be
integrated, so I am interested in this work. I see kernelci and fuego as complementary.
That's why I'm focusing on the runtime aspects of Fuego, and not on the
build/boot tests, at the moment.

If we extend kernel-ci to support other types of tests, it would be nice if
there were some ability to reuse aspects of fuego test definitions there.

I got together with Fenguang Wu (the author of the 0day test project) at plumbers,
and found that 0day and Fuego has some very similar concepts, and we might
be able to share some materials. 0day is missing visualization tools for results,
and doesn't support the notion of cross-compilation yet. But they have similar
test phases (download, build, deploy, test, gather logs, parse results). For an initial
attempt at writing a standard test API, I was hoping I could find enough common
ground between 0day and Fuego to support the same test collateral between the
two systems. From what I have seen so far, the test API for LAVA (which kernelci
is based on) also has some similar concepts, but they haven't gotten around
to formalizing the API in a way that could be used as the common shared API
with multiple systems.

Regards,
-- Tim


Re: Features backports

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

On 29/11/16 03:57, 小口琢夫 / KOGUCHI,TAKUO wrote:
Hi,

Regarding to Altera Socfpga Cyclone V, we might want to backport from 4.9;
- L2cache ECC(./arch/arm/mm/cache-l2x0.c)
- QSPI Flash controller(drivers/mtd/spi-nor/cadence-quadspi.c)

4.9 is still missing the followings which exist in the verdor tree(linux-socfpga);
- HPS2FPGA(drivers/fpga/altera-hps2fpga.c)
- NAND Flash controller(drivers/mtd/nand/denali_dt.c)
I hope we can encourage Altera to push these features upstream or do it ourselves.
I think we have a good chance once they see we are testing Beaglebone Black in the open. That would be a good opportunity we might add value to them.

Definitely I would talk to them before. If they are not pushing the patches upstream, it would be a good question why.


Takuo


-----Original Message-----
From: cip-dev-bounces@lists.cip-project.org
[mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Agustin Benito
Bethencourt
Sent: Friday, November 18, 2016 9:26 PM
To: cip-dev@lists.cip-project.org
Subject: [!][cip-dev] Features backports

Hi,

as you probably know, the more features we backport, the higher will be the
maintenance cost overtime so as a strategy, we need to be very
conservative.

I sent a mail some days ago about the features backported already by Linaro
for their LSK (Linaro Stable Kernel) for your evaluation. I bring today some
potential backports related with security features and hardware support that
has been identified by Ben H.

* UBSAN support:
<https://git.kernel.org/linus/c6d308534aef6c99904bf5862066360ae067abc4
* Increased user-space ASLR range for ARM:
<https://lwn.net/Articles/667790/>

* Page poisoning on free:
<https://git.kernel.org/linus/8823b1dbc05fab1a8bec275eeae4709257c2661
d>,
<https://git.kernel.org/linus/1414c7f4f7d72d138fff35f00151d15749b5beda>

* SLAB/SLUB freelist randomisation

* Hardened usercopy

* Do Members use SLUB? if not, we should take a look at KASAN support for
SLAB

* drm/tilcdc update? (many bug fixes post-4.4)

* AM33xx RTC support:

<https://git.kernel.org/linus/461932dfb54ebaf7da438fd8b769a01ce97a9360
,
<https://git.kernel.org/linus/b5a553c08bec14a058501df3fa6eb39f63f00a98>


Best Regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink agustin.benito@codethink.co.uk
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


Open Source OPC UA

Jan Kiszka
 

Hi all,

does anyone already have some experience with OSS OPC UA
implementations, specifically for resource constrained devices? We
stumbled over

http://open62541.org

which seems like being on the right path. There are more

https://github.com/open62541/open62541/wiki/List-of-Open-Source-OPC-UA-Implementations

but not all look that attractive for embedded devices, due to language,
license or main drivers.

I think, eventually, CIP should look into the topic free and
standard-conforming OPC UA as well because it is gaining a lot of
traction as THE protocol for data exchange in automation industry.

Regards,
Jan


Re: Open Source OPC UA

Wolfgang Mauerer <wm@...>
 

Am 29/11/2016 um 20:36 schrieb Jan Kiszka:

does anyone already have some experience with OSS OPC UA
implementations, specifically for resource constrained devices? We
stumbled over

http://open62541.org

which seems like being on the right path. There are more

https://github.com/open62541/open62541/wiki/List-of-Open-Source-OPC-UA-Implementations

but not all look that attractive for embedded devices, due to language,
license or main drivers.
there's another tiny implementation from some of the Ostwestfalen-Lippe
(OWL) group of people in Germany, but since it targets devices with
only 10s of KiB of RAM and ROM, I don't think it's suitable for our
purposes.

As for language and main drivers: Do we have an agreement or an idea
in the group what suitable languages are, and what characteristics main
drivers should have? Considering the size of systems we're targeting, I
personally would not see C (and possibly C++) as the only admissible
language.

Best regards, Wolfgang

I think, eventually, CIP should look into the topic free and
standard-conforming OPC UA as well because it is gaining a lot of
traction as THE protocol for data exchange in automation industry.

Regards,
Jan
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: Open Source OPC UA

Jan Kiszka
 

On 2016-11-30 11:41, Wolfgang Mauerer wrote:
Am 29/11/2016 um 20:36 schrieb Jan Kiszka:

does anyone already have some experience with OSS OPC UA
implementations, specifically for resource constrained devices? We
stumbled over

http://open62541.org

which seems like being on the right path. There are more

https://github.com/open62541/open62541/wiki/List-of-Open-Source-OPC-UA-Implementations

but not all look that attractive for embedded devices, due to language,
license or main drivers.
there's another tiny implementation from some of the Ostwestfalen-Lippe
(OWL) group of people in Germany, but since it targets devices with
only 10s of KiB of RAM and ROM, I don't think it's suitable for our
purposes.
If you have a link (and the project has a proper license), maybe send a
PR to the open62541.org to extend their list.


As for language and main drivers: Do we have an agreement or an idea
in the group what suitable languages are, and what characteristics main
drivers should have? Considering the size of systems we're targeting, I
personally would not see C (and possibly C++) as the only admissible
language.
If we only had higher languages, that would be a major limitation. It's
not so much about their size, more about their amount of dependencies
and their suitability for embedded processors (just having "fun" with Go
on Intel Quark...).

But also having bindings for Java, C#, python, JavaScript, Go,
you-name-them, would be valuable. So I would recommend to start with a
common core - thus a native one - and add those bindings to them. Later
on, if there is added value, we could also consider alternative core
implementations.

Regards,
Jan


Best regards, Wolfgang

I think, eventually, CIP should look into the topic free and
standard-conforming OPC UA as well because it is gaining a lot of
traction as THE protocol for data exchange in automation industry.

Regards,
Jan
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: Features backports

Yoshitake Kobayashi
 

Hi,

Since the Intel Apollo Lake has already released, we started to check the
patches for that. I think the basic functionality has already upstreamed
and it might be enough for expected use cases.

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-4.4/log/?h=standard/intel/bxt-rebase

I continue to clarify more details.

Best regards,
Yoshi

On 2016/11/18 21:26, Agustin Benito Bethencourt wrote:
Hi,

as you probably know, the more features we backport, the higher will be the maintenance cost overtime so as a strategy, we need to be very conservative.

I sent a mail some days ago about the features backported already by Linaro for their LSK (Linaro Stable Kernel) for your evaluation. I bring today some potential backports related with security features and hardware support that has been identified by Ben H.

* UBSAN support:
<https://git.kernel.org/linus/c6d308534aef6c99904bf5862066360ae067abc4>

* Increased user-space ASLR range for ARM:
<https://lwn.net/Articles/667790/>

* Page poisoning on free:
<https://git.kernel.org/linus/8823b1dbc05fab1a8bec275eeae4709257c2661d>,
<https://git.kernel.org/linus/1414c7f4f7d72d138fff35f00151d15749b5beda>

* SLAB/SLUB freelist randomisation

* Hardened usercopy

* Do Members use SLUB? if not, we should take a look at KASAN support for SLAB

* drm/tilcdc update? (many bug fixes post-4.4)

* AM33xx RTC support:

<https://git.kernel.org/linus/461932dfb54ebaf7da438fd8b769a01ce97a9360>,
<https://git.kernel.org/linus/b5a553c08bec14a058501df3fa6eb39f63f00a98>


Best Regards


The Problem with build.log

Don Brown <don.brown@...>
 

Hi Robert,

I may have found the problem with the links to the build.log,
kernel.config and zImage files.

As you can see from the attached Screenshots, when I hover over the
links, the URL has some duplicated information in it.

  * For instance, the link to the build.log file is shown as:
      o /localhost:5000/build/cip-dreiwettertaft/kernel/v4.4.27/localhost/cip-dreiwettertaft/kernel/v4.4.27/arm-tinyconfig/build.log/
  * The kernel.config link is shown as:
      o /localhost:5000/build/cip-dreiwettertaft/kernel/v4.4.27/localhost/cip-dreiwettertaft/kernel/v4.4.27/arm-tinyconfig/kernel.config/
  * The zImage link is shown as:
      o /localhost:5000/build/cip-dreiwettertaft/kernel/v4.4.27/localhost/cip-dreiwettertaft/kernel/v4.4.27/arm-tinyconfig/zImage/

The files are actually stored in the following location on disk:

//var/www/images/kernel-ci/cip-dreiwettertaft/v4.4.27/arm-tinyconfig/

So I think they are grabbing a string to append to the site URL and they
are grabbing more than they wanted.

P.S. I also created an Issue (#2) in the GitLab site for this, but I
wasn't sure how attaching the pics would go.

 
-- 
Don Brown
Codethink, Ltd.
Software Engineering Consultant
Indianapolis, IN USA
Email: don.brown@...
Mobile: +1 317-560-0513


[PATCH 4.4-cip 0/6] Extend user-space ASLR range

Ben Hutchings <ben.hutchings@...>
 

This is a backport of changes in 4.5 to extend the range of Address
Space Layout Randomisation for user-space processes. When enabled, this
should make some user-space vulnerabilities harder to exploit, but it
can also cause some applications to fail if they currently use a large
proportion of the virtual address space.

The default ASLR range remains the same, but it can be changed through
kernel config (CONFIG_ARCH_MMAP_RND_BITS) or at run-time through sysctl
(vm.mmap_rnd_bits). (For 32-bit compat tasks, the range is controlled
through CONFIG_ARCH_MMAP_RND_COMPAT_BITS and vm.mmap_rnd_compat_bits.)

This includes support for arm, arm64 and x86 (32- and 64-bit). (arm64
is not currently supported by CIP, but it was easier to include it in
the backport than to leave it out.)

For this and other backports, I'm looking for feedback like:
- Did I miss a follow-up fix or an earlier dependency?
- Does this cause a regression (other than as explained above)?
- Are you likely to use it?
- Are there related features you want in 4.4?

Ben.

Daniel Cashman (6):
mm: mmap: add new /proc tunable for mmap_base ASLR
arm: mm: support ARCH_MMAP_RND_BITS
arm64: mm: support ARCH_MMAP_RND_BITS
x86: mm: support ARCH_MMAP_RND_BITS
drivers: char: random: add get_random_long()
mm: ASLR: use get_random_long()

Documentation/sysctl/vm.txt | 29 +++++++++++++++++
arch/Kconfig | 68 ++++++++++++++++++++++++++++++++++++++++
arch/arm/Kconfig | 9 ++++++
arch/arm/mm/mmap.c | 3 +-
arch/arm64/Kconfig | 29 +++++++++++++++++
arch/arm64/mm/mmap.c | 8 +++--
arch/mips/mm/mmap.c | 4 +--
arch/powerpc/kernel/process.c | 4 +--
arch/powerpc/mm/mmap.c | 4 +--
arch/sparc/kernel/sys_sparc_64.c | 2 +-
arch/x86/Kconfig | 16 ++++++++++
arch/x86/mm/mmap.c | 12 +++----
drivers/char/random.c | 22 +++++++++++++
fs/binfmt_elf.c | 2 +-
include/linux/mm.h | 11 +++++++
include/linux/random.h | 1 +
kernel/sysctl.c | 22 +++++++++++++
mm/mmap.c | 12 +++++++
18 files changed, 240 insertions(+), 18 deletions(-)

--
2.10.2


--
Ben Hutchings
Software Developer, Codethink Ltd.


[PATCH 4.4-cip 1/6] mm: mmap: add new /proc tunable for mmap_base ASLR

Ben Hutchings <ben.hutchings@...>
 

From: Daniel Cashman <dcashman@google.com>

commit d07e22597d1d355829b7b18ac19afa912cf758d1 upstream.

Address Space Layout Randomization (ASLR) provides a barrier to
exploitation of user-space processes in the presence of security
vulnerabilities by making it more difficult to find desired code/data
which could help an attack. This is done by adding a random offset to
the location of regions in the process address space, with a greater
range of potential offset values corresponding to better protection/a
larger search-space for brute force, but also to greater potential for
fragmentation.

The offset added to the mmap_base address, which provides the basis for
the majority of the mappings for a process, is set once on process exec
in arch_pick_mmap_layout() and is done via hard-coded per-arch values,
which reflect, hopefully, the best compromise for all systems. The
trade-off between increased entropy in the offset value generation and
the corresponding increased variability in address space fragmentation
is not absolute, however, and some platforms may tolerate higher amounts
of entropy. This patch introduces both new Kconfig values and a sysctl
interface which may be used to change the amount of entropy used for
offset generation on a system.

The direct motivation for this change was in response to the
libstagefright vulnerabilities that affected Android, specifically to
information provided by Google's project zero at:

http://googleprojectzero.blogspot.com/2015/09/stagefrightened.html

The attack presented therein, by Google's project zero, specifically
targeted the limited randomness used to generate the offset added to the
mmap_base address in order to craft a brute-force-based attack.
Concretely, the attack was against the mediaserver process, which was
limited to respawning every 5 seconds, on an arm device. The hard-coded
8 bits used resulted in an average expected success rate of defeating
the mmap ASLR after just over 10 minutes (128 tries at 5 seconds a
piece). With this patch, and an accompanying increase in the entropy
value to 16 bits, the same attack would take an average expected time of
over 45 hours (32768 tries), which makes it both less feasible and more
likely to be noticed.

The introduced Kconfig and sysctl options are limited by per-arch
minimum and maximum values, the minimum of which was chosen to match the
current hard-coded value and the maximum of which was chosen so as to
give the greatest flexibility without generating an invalid mmap_base
address, generally a 3-4 bits less than the number of bits in the
user-space accessible virtual address space.

When decided whether or not to change the default value, a system
developer should consider that mmap_base address could be placed
anywhere up to 2^(value) bits away from the non-randomized location,
which would introduce variable-sized areas above and below the mmap_base
address such that the maximum vm_area_struct size may be reduced,
preventing very large allocations.

This patch (of 4):

ASLR only uses as few as 8 bits to generate the random offset for the
mmap base address on 32 bit architectures. This value was chosen to
prevent a poorly chosen value from dividing the address space in such a
way as to prevent large allocations. This may not be an issue on all
platforms. Allow the specification of a minimum number of bits so that
platforms desiring greater ASLR protection may determine where to place
the trade-off.

Signed-off-by: Daniel Cashman <dcashman@google.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: David Rientjes <rientjes@google.com>
Cc: Mark Salyzyn <salyzyn@android.com>
Cc: Jeff Vander Stoep <jeffv@google.com>
Cc: Nick Kralevich <nnk@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Hector Marco-Gisbert <hecmargi@upv.es>
Cc: Borislav Petkov <bp@suse.de>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
---
Documentation/sysctl/vm.txt | 29 +++++++++++++++++++
arch/Kconfig | 68 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/mm.h | 11 ++++++++
kernel/sysctl.c | 22 +++++++++++++++
mm/mmap.c | 12 ++++++++
5 files changed, 142 insertions(+)

diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index f72370b440b1..ee763f3d3b52 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -42,6 +42,8 @@ Currently, these files are in /proc/sys/vm:
- min_slab_ratio
- min_unmapped_ratio
- mmap_min_addr
+- mmap_rnd_bits
+- mmap_rnd_compat_bits
- nr_hugepages
- nr_overcommit_hugepages
- nr_trim_pages (only if CONFIG_MMU=n)
@@ -485,6 +487,33 @@ against future potential kernel bugs.

==============================================================

+mmap_rnd_bits:
+
+This value can be used to select the number of bits to use to
+determine the random offset to the base address of vma regions
+resulting from mmap allocations on architectures which support
+tuning address space randomization. This value will be bounded
+by the architecture's minimum and maximum supported values.
+
+This value can be changed after boot using the
+/proc/sys/vm/mmap_rnd_bits tunable
+
+==============================================================
+
+mmap_rnd_compat_bits:
+
+This value can be used to select the number of bits to use to
+determine the random offset to the base address of vma regions
+resulting from mmap allocations for applications run in
+compatibility mode on architectures which support tuning address
+space randomization. This value will be bounded by the
+architecture's minimum and maximum supported values.
+
+This value can be changed after boot using the
+/proc/sys/vm/mmap_rnd_compat_bits tunable
+
+==============================================================
+
nr_hugepages

Change the minimum size of the hugepage pool.
diff --git a/arch/Kconfig b/arch/Kconfig
index 4e949e58b192..ba1b626bca00 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -511,6 +511,74 @@ config ARCH_HAS_ELF_RANDOMIZE
- arch_mmap_rnd()
- arch_randomize_brk()

+config HAVE_ARCH_MMAP_RND_BITS
+ bool
+ help
+ An arch should select this symbol if it supports setting a variable
+ number of bits for use in establishing the base address for mmap
+ allocations, has MMU enabled and provides values for both:
+ - ARCH_MMAP_RND_BITS_MIN
+ - ARCH_MMAP_RND_BITS_MAX
+
+config ARCH_MMAP_RND_BITS_MIN
+ int
+
+config ARCH_MMAP_RND_BITS_MAX
+ int
+
+config ARCH_MMAP_RND_BITS_DEFAULT
+ int
+
+config ARCH_MMAP_RND_BITS
+ int "Number of bits to use for ASLR of mmap base address" if EXPERT
+ range ARCH_MMAP_RND_BITS_MIN ARCH_MMAP_RND_BITS_MAX
+ default ARCH_MMAP_RND_BITS_DEFAULT if ARCH_MMAP_RND_BITS_DEFAULT
+ default ARCH_MMAP_RND_BITS_MIN
+ depends on HAVE_ARCH_MMAP_RND_BITS
+ help
+ This value can be used to select the number of bits to use to
+ determine the random offset to the base address of vma regions
+ resulting from mmap allocations. This value will be bounded
+ by the architecture's minimum and maximum supported values.
+
+ This value can be changed after boot using the
+ /proc/sys/vm/mmap_rnd_bits tunable
+
+config HAVE_ARCH_MMAP_RND_COMPAT_BITS
+ bool
+ help
+ An arch should select this symbol if it supports running applications
+ in compatibility mode, supports setting a variable number of bits for
+ use in establishing the base address for mmap allocations, has MMU
+ enabled and provides values for both:
+ - ARCH_MMAP_RND_COMPAT_BITS_MIN
+ - ARCH_MMAP_RND_COMPAT_BITS_MAX
+
+config ARCH_MMAP_RND_COMPAT_BITS_MIN
+ int
+
+config ARCH_MMAP_RND_COMPAT_BITS_MAX
+ int
+
+config ARCH_MMAP_RND_COMPAT_BITS_DEFAULT
+ int
+
+config ARCH_MMAP_RND_COMPAT_BITS
+ int "Number of bits to use for ASLR of mmap base address for compatible applications" if EXPERT
+ range ARCH_MMAP_RND_COMPAT_BITS_MIN ARCH_MMAP_RND_COMPAT_BITS_MAX
+ default ARCH_MMAP_RND_COMPAT_BITS_DEFAULT if ARCH_MMAP_RND_COMPAT_BITS_DEFAULT
+ default ARCH_MMAP_RND_COMPAT_BITS_MIN
+ depends on HAVE_ARCH_MMAP_RND_COMPAT_BITS
+ help
+ This value can be used to select the number of bits to use to
+ determine the random offset to the base address of vma regions
+ resulting from mmap allocations for compatible applications This
+ value will be bounded by the architecture's minimum and maximum
+ supported values.
+
+ This value can be changed after boot using the
+ /proc/sys/vm/mmap_rnd_compat_bits tunable
+
config HAVE_COPY_THREAD_TLS
bool
help
diff --git a/include/linux/mm.h b/include/linux/mm.h
index f0ffa01c90d9..ee18791531e4 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -51,6 +51,17 @@ extern int sysctl_legacy_va_layout;
#define sysctl_legacy_va_layout 0
#endif

+#ifdef CONFIG_HAVE_ARCH_MMAP_RND_BITS
+extern const int mmap_rnd_bits_min;
+extern const int mmap_rnd_bits_max;
+extern int mmap_rnd_bits __read_mostly;
+#endif
+#ifdef CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS
+extern const int mmap_rnd_compat_bits_min;
+extern const int mmap_rnd_compat_bits_max;
+extern int mmap_rnd_compat_bits __read_mostly;
+#endif
+
#include <asm/page.h>
#include <asm/pgtable.h>
#include <asm/processor.h>
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 999e025bf68e..9bc9f56b8b3d 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1568,6 +1568,28 @@ static struct ctl_table vm_table[] = {
.mode = 0644,
.proc_handler = proc_doulongvec_minmax,
},
+#ifdef CONFIG_HAVE_ARCH_MMAP_RND_BITS
+ {
+ .procname = "mmap_rnd_bits",
+ .data = &mmap_rnd_bits,
+ .maxlen = sizeof(mmap_rnd_bits),
+ .mode = 0600,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = (void *)&mmap_rnd_bits_min,
+ .extra2 = (void *)&mmap_rnd_bits_max,
+ },
+#endif
+#ifdef CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS
+ {
+ .procname = "mmap_rnd_compat_bits",
+ .data = &mmap_rnd_compat_bits,
+ .maxlen = sizeof(mmap_rnd_compat_bits),
+ .mode = 0600,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = (void *)&mmap_rnd_compat_bits_min,
+ .extra2 = (void *)&mmap_rnd_compat_bits_max,
+ },
+#endif
{ }
};

diff --git a/mm/mmap.c b/mm/mmap.c
index 455772a05e54..d99cef70ad18 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -58,6 +58,18 @@
#define arch_rebalance_pgtables(addr, len) (addr)
#endif

+#ifdef CONFIG_HAVE_ARCH_MMAP_RND_BITS
+const int mmap_rnd_bits_min = CONFIG_ARCH_MMAP_RND_BITS_MIN;
+const int mmap_rnd_bits_max = CONFIG_ARCH_MMAP_RND_BITS_MAX;
+int mmap_rnd_bits __read_mostly = CONFIG_ARCH_MMAP_RND_BITS;
+#endif
+#ifdef CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS
+const int mmap_rnd_compat_bits_min = CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN;
+const int mmap_rnd_compat_bits_max = CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX;
+int mmap_rnd_compat_bits __read_mostly = CONFIG_ARCH_MMAP_RND_COMPAT_BITS;
+#endif
+
+
static void unmap_region(struct mm_struct *mm,
struct vm_area_struct *vma, struct vm_area_struct *prev,
unsigned long start, unsigned long end);
--
2.10.2



--
Ben Hutchings
Software Developer, Codethink Ltd.


[PATCH 4.4-cip 2/6] arm: mm: support ARCH_MMAP_RND_BITS

Ben Hutchings <ben.hutchings@...>
 

From: Daniel Cashman <dcashman@google.com>

commit e0c25d958f78acfd5c97df5776eeba3e0684101b upstream.

arm: arch_mmap_rnd() uses a hard-code value of 8 to generate the random
offset for the mmap base address. This value represents a compromise
between increased ASLR effectiveness and avoiding address-space
fragmentation. Replace it with a Kconfig option, which is sensibly
bounded, so that platform developers may choose where to place this
compromise. Keep 8 as the minimum acceptable value.

[arnd@arndb.de: ARM: avoid ARCH_MMAP_RND_BITS for NOMMU]
Signed-off-by: Daniel Cashman <dcashman@google.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: David Rientjes <rientjes@google.com>
Cc: Mark Salyzyn <salyzyn@android.com>
Cc: Jeff Vander Stoep <jeffv@google.com>
Cc: Nick Kralevich <nnk@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Hector Marco-Gisbert <hecmargi@upv.es>
Cc: Borislav Petkov <bp@suse.de>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 4.4: adjust context]
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
---
arch/arm/Kconfig | 9 +++++++++
arch/arm/mm/mmap.c | 3 +--
2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 34e1569a11ee..a1b8ca129a8a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -35,6 +35,7 @@ config ARM
select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32
select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32
+ select HAVE_ARCH_MMAP_RND_BITS if MMU
select HAVE_ARCH_SECCOMP_FILTER if (AEABI && !OABI_COMPAT)
select HAVE_ARCH_TRACEHOOK
select HAVE_BPF_JIT
@@ -308,6 +309,14 @@ config MMU
Select if you want MMU-based virtualised addressing space
support by paged memory management. If unsure, say 'Y'.

+config ARCH_MMAP_RND_BITS_MIN
+ default 8
+
+config ARCH_MMAP_RND_BITS_MAX
+ default 14 if PAGE_OFFSET=0x40000000
+ default 15 if PAGE_OFFSET=0x80000000
+ default 16
+
#
# The "ARM system type" choice list is ordered alphabetically by option
# text. Please add new entries in the option alphabetic order.
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index 407dc786583a..4b4058db0781 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -173,8 +173,7 @@ unsigned long arch_mmap_rnd(void)
{
unsigned long rnd;

- /* 8 bits of randomness in 20 address space bits */
- rnd = (unsigned long)get_random_int() % (1 << 8);
+ rnd = (unsigned long)get_random_int() & ((1 << mmap_rnd_bits) - 1);

return rnd << PAGE_SHIFT;
}
--
2.10.2



--
Ben Hutchings
Software Developer, Codethink Ltd.


[PATCH 4.4-cip 3/6] arm64: mm: support ARCH_MMAP_RND_BITS

Ben Hutchings <ben.hutchings@...>
 

From: Daniel Cashman <dcashman@google.com>

commit 8f0d3aa9de57662fe35d8bacfbd9d7ef85ffe98f upstream.

arm64: arch_mmap_rnd() uses STACK_RND_MASK to generate the random offset
for the mmap base address. This value represents a compromise between
increased ASLR effectiveness and avoiding address-space fragmentation.
Replace it with a Kconfig option, which is sensibly bounded, so that
platform developers may choose where to place this compromise. Keep
default values as new minimums.

Signed-off-by: Daniel Cashman <dcashman@google.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: David Rientjes <rientjes@google.com>
Cc: Mark Salyzyn <salyzyn@android.com>
Cc: Jeff Vander Stoep <jeffv@google.com>
Cc: Nick Kralevich <nnk@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Hector Marco-Gisbert <hecmargi@upv.es>
Cc: Borislav Petkov <bp@suse.de>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
---
arch/arm64/Kconfig | 29 +++++++++++++++++++++++++++++
arch/arm64/mm/mmap.c | 8 ++++++--
2 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 14cdc6dea493..edf62be35adc 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -51,6 +51,8 @@ config ARM64
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_KASAN if SPARSEMEM_VMEMMAP && !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
select HAVE_ARCH_KGDB
+ select HAVE_ARCH_MMAP_RND_BITS
+ select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
select HAVE_ARCH_SECCOMP_FILTER
select HAVE_ARCH_TRACEHOOK
select HAVE_BPF_JIT
@@ -104,6 +106,33 @@ config ARCH_PHYS_ADDR_T_64BIT
config MMU
def_bool y

+config ARCH_MMAP_RND_BITS_MIN
+ default 14 if ARM64_64K_PAGES
+ default 16 if ARM64_16K_PAGES
+ default 18
+
+# max bits determined by the following formula:
+# VA_BITS - PAGE_SHIFT - 3
+config ARCH_MMAP_RND_BITS_MAX
+ default 19 if ARM64_VA_BITS=36
+ default 24 if ARM64_VA_BITS=39
+ default 27 if ARM64_VA_BITS=42
+ default 30 if ARM64_VA_BITS=47
+ default 29 if ARM64_VA_BITS=48 && ARM64_64K_PAGES
+ default 31 if ARM64_VA_BITS=48 && ARM64_16K_PAGES
+ default 33 if ARM64_VA_BITS=48
+ default 14 if ARM64_64K_PAGES
+ default 16 if ARM64_16K_PAGES
+ default 18
+
+config ARCH_MMAP_RND_COMPAT_BITS_MIN
+ default 7 if ARM64_64K_PAGES
+ default 9 if ARM64_16K_PAGES
+ default 11
+
+config ARCH_MMAP_RND_COMPAT_BITS_MAX
+ default 16
+
config NO_IOPORT_MAP
def_bool y if !PCI

diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
index ed177475dd8c..4c893b5189dd 100644
--- a/arch/arm64/mm/mmap.c
+++ b/arch/arm64/mm/mmap.c
@@ -51,8 +51,12 @@ unsigned long arch_mmap_rnd(void)
{
unsigned long rnd;

- rnd = (unsigned long)get_random_int() & STACK_RND_MASK;
-
+#ifdef CONFIG_COMPAT
+ if (test_thread_flag(TIF_32BIT))
+ rnd = (unsigned long)get_random_int() & ((1 << mmap_rnd_compat_bits) - 1);
+ else
+#endif
+ rnd = (unsigned long)get_random_int() & ((1 << mmap_rnd_bits) - 1);
return rnd << PAGE_SHIFT;
}

--
2.10.2



--
Ben Hutchings
Software Developer, Codethink Ltd.


[PATCH 4.4-cip 4/6] x86: mm: support ARCH_MMAP_RND_BITS

Ben Hutchings <ben.hutchings@...>
 

From: Daniel Cashman <dcashman@google.com>

commit 9e08f57d684ac2f40685f55f659564bfd91a971e upstream.

x86: arch_mmap_rnd() uses hard-coded values, 8 for 32-bit and 28 for
64-bit, to generate the random offset for the mmap base address. This
value represents a compromise between increased ASLR effectiveness and
avoiding address-space fragmentation. Replace it with a Kconfig option,
which is sensibly bounded, so that platform developers may choose where
to place this compromise. Keep default values as new minimums.

Signed-off-by: Daniel Cashman <dcashman@google.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: David Rientjes <rientjes@google.com>
Cc: Mark Salyzyn <salyzyn@android.com>
Cc: Jeff Vander Stoep <jeffv@google.com>
Cc: Nick Kralevich <nnk@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Hector Marco-Gisbert <hecmargi@upv.es>
Cc: Borislav Petkov <bp@suse.de>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
---
arch/x86/Kconfig | 16 ++++++++++++++++
arch/x86/mm/mmap.c | 12 ++++++------
2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 436639a31624..ffbfa85271a3 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -82,6 +82,8 @@ config X86
select HAVE_ARCH_KASAN if X86_64 && SPARSEMEM_VMEMMAP
select HAVE_ARCH_KGDB
select HAVE_ARCH_KMEMCHECK
+ select HAVE_ARCH_MMAP_RND_BITS if MMU
+ select HAVE_ARCH_MMAP_RND_COMPAT_BITS if MMU && COMPAT
select HAVE_ARCH_SECCOMP_FILTER
select HAVE_ARCH_SOFT_DIRTY if X86_64
select HAVE_ARCH_TRACEHOOK
@@ -183,6 +185,20 @@ config HAVE_LATENCYTOP_SUPPORT
config MMU
def_bool y

+config ARCH_MMAP_RND_BITS_MIN
+ default 28 if 64BIT
+ default 8
+
+config ARCH_MMAP_RND_BITS_MAX
+ default 32 if 64BIT
+ default 16
+
+config ARCH_MMAP_RND_COMPAT_BITS_MIN
+ default 8
+
+config ARCH_MMAP_RND_COMPAT_BITS_MAX
+ default 16
+
config SBUS
bool

diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c
index 307f60ecfc6d..389939f74dd5 100644
--- a/arch/x86/mm/mmap.c
+++ b/arch/x86/mm/mmap.c
@@ -69,14 +69,14 @@ unsigned long arch_mmap_rnd(void)
{
unsigned long rnd;

- /*
- * 8 bits of randomness in 32bit mmaps, 20 address space bits
- * 28 bits of randomness in 64bit mmaps, 40 address space bits
- */
if (mmap_is_ia32())
- rnd = (unsigned long)get_random_int() % (1<<8);
+#ifdef CONFIG_COMPAT
+ rnd = (unsigned long)get_random_int() & ((1 << mmap_rnd_compat_bits) - 1);
+#else
+ rnd = (unsigned long)get_random_int() & ((1 << mmap_rnd_bits) - 1);
+#endif
else
- rnd = (unsigned long)get_random_int() % (1<<28);
+ rnd = (unsigned long)get_random_int() & ((1 << mmap_rnd_bits) - 1);

return rnd << PAGE_SHIFT;
}
--
2.10.2



--
Ben Hutchings
Software Developer, Codethink Ltd.


[PATCH 4.4-cip 5/6] drivers: char: random: add get_random_long()

Ben Hutchings <ben.hutchings@...>
 

Daniel Cashman <dcashman@android.com>

commit ec9ee4acd97c0039a61c0ae4f12705767ae62153 upstream.

Commit d07e22597d1d ("mm: mmap: add new /proc tunable for mmap_base
ASLR") added the ability to choose from a range of values to use for
entropy count in generating the random offset to the mmap_base address.

The maximum value on this range was set to 32 bits for 64-bit x86
systems, but this value could be increased further, requiring more than
the 32 bits of randomness provided by get_random_int(), as is already
possible for arm64. Add a new function: get_random_long() which more
naturally fits with the mmap usage of get_random_int() but operates
exactly the same as get_random_int().

Also, fix the shifting constant in mmap_rnd() to be an unsigned long so
that values greater than 31 bits generate an appropriate mask without
overflow. This is especially important on x86, as its shift instruction
uses a 5-bit mask for the shift operand, which meant that any value for
mmap_rnd_bits over 31 acts as a no-op and effectively disables mmap_base
randomization.

Finally, replace calls to get_random_int() with get_random_long() where
appropriate.

This patch (of 2):

Add get_random_long().

Signed-off-by: Daniel Cashman <dcashman@android.com>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: David S. Miller <davem@davemloft.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Nick Kralevich <nnk@google.com>
Cc: Jeff Vander Stoep <jeffv@google.com>
Cc: Mark Salyzyn <salyzyn@android.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
---
drivers/char/random.c | 22 ++++++++++++++++++++++
include/linux/random.h | 1 +
2 files changed, 23 insertions(+)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 491a4dce13fe..d93dfebae0bb 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1825,6 +1825,28 @@ unsigned int get_random_int(void)
EXPORT_SYMBOL(get_random_int);

/*
+ * Same as get_random_int(), but returns unsigned long.
+ */
+unsigned long get_random_long(void)
+{
+ __u32 *hash;
+ unsigned long ret;
+
+ if (arch_get_random_long(&ret))
+ return ret;
+
+ hash = get_cpu_var(get_random_int_hash);
+
+ hash[0] += current->pid + jiffies + random_get_entropy();
+ md5_transform(hash, random_int_secret);
+ ret = *(unsigned long *)hash;
+ put_cpu_var(get_random_int_hash);
+
+ return ret;
+}
+EXPORT_SYMBOL(get_random_long);
+
+/*
* randomize_range() returns a start address such that
*
* [...... <range> .....]
diff --git a/include/linux/random.h b/include/linux/random.h
index a75840c1aa71..9c29122037f9 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -34,6 +34,7 @@ extern const struct file_operations random_fops, urandom_fops;
#endif

unsigned int get_random_int(void);
+unsigned long get_random_long(void);
unsigned long randomize_range(unsigned long start, unsigned long end, unsigned long len);

u32 prandom_u32(void);
--
2.10.2



--
Ben Hutchings
Software Developer, Codethink Ltd.


[PATCH 4.4-cip 6/6] mm: ASLR: use get_random_long()

Ben Hutchings <ben.hutchings@...>
 

From: Daniel Cashman <dcashman@android.com>

commit 5ef11c35ce86b94bfb878b684de4cdaf96f54b2f upstream.

Replace calls to get_random_int() followed by a cast to (unsigned long)
with calls to get_random_long(). Also address shifting bug which, in
case of x86 removed entropy mask for mmap_rnd_bits values > 31 bits.

Signed-off-by: Daniel Cashman <dcashman@android.com>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: David S. Miller <davem@davemloft.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Nick Kralevich <nnk@google.com>
Cc: Jeff Vander Stoep <jeffv@google.com>
Cc: Mark Salyzyn <salyzyn@android.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
---
arch/arm/mm/mmap.c | 2 +-
arch/arm64/mm/mmap.c | 4 ++--
arch/mips/mm/mmap.c | 4 ++--
arch/powerpc/kernel/process.c | 4 ++--
arch/powerpc/mm/mmap.c | 4 ++--
arch/sparc/kernel/sys_sparc_64.c | 2 +-
arch/x86/mm/mmap.c | 6 +++---
fs/binfmt_elf.c | 2 +-
8 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index 4b4058db0781..66353caa35b9 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -173,7 +173,7 @@ unsigned long arch_mmap_rnd(void)
{
unsigned long rnd;

- rnd = (unsigned long)get_random_int() & ((1 << mmap_rnd_bits) - 1);
+ rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);

return rnd << PAGE_SHIFT;
}
diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
index 4c893b5189dd..232f787a088a 100644
--- a/arch/arm64/mm/mmap.c
+++ b/arch/arm64/mm/mmap.c
@@ -53,10 +53,10 @@ unsigned long arch_mmap_rnd(void)

#ifdef CONFIG_COMPAT
if (test_thread_flag(TIF_32BIT))
- rnd = (unsigned long)get_random_int() & ((1 << mmap_rnd_compat_bits) - 1);
+ rnd = get_random_long() & ((1UL << mmap_rnd_compat_bits) - 1);
else
#endif
- rnd = (unsigned long)get_random_int() & ((1 << mmap_rnd_bits) - 1);
+ rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);
return rnd << PAGE_SHIFT;
}

diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index 5c81fdd032c3..353037699512 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -146,7 +146,7 @@ unsigned long arch_mmap_rnd(void)
{
unsigned long rnd;

- rnd = (unsigned long)get_random_int();
+ rnd = get_random_long();
rnd <<= PAGE_SHIFT;
if (TASK_IS_32BIT_ADDR)
rnd &= 0xfffffful;
@@ -174,7 +174,7 @@ void arch_pick_mmap_layout(struct mm_struct *mm)

static inline unsigned long brk_rnd(void)
{
- unsigned long rnd = get_random_int();
+ unsigned long rnd = get_random_long();

rnd = rnd << PAGE_SHIFT;
/* 8MB for 32bit, 256MB for 64bit */
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index cf788d7d7e56..b7abf3cd2a67 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1651,9 +1651,9 @@ static inline unsigned long brk_rnd(void)

/* 8MB for 32bit, 1GB for 64bit */
if (is_32bit_task())
- rnd = (long)(get_random_int() % (1<<(23-PAGE_SHIFT)));
+ rnd = (get_random_long() % (1UL<<(23-PAGE_SHIFT)));
else
- rnd = (long)(get_random_int() % (1<<(30-PAGE_SHIFT)));
+ rnd = (get_random_long() % (1UL<<(30-PAGE_SHIFT)));

return rnd << PAGE_SHIFT;
}
diff --git a/arch/powerpc/mm/mmap.c b/arch/powerpc/mm/mmap.c
index 0f0502e12f6c..4087705ba90f 100644
--- a/arch/powerpc/mm/mmap.c
+++ b/arch/powerpc/mm/mmap.c
@@ -59,9 +59,9 @@ unsigned long arch_mmap_rnd(void)

/* 8MB for 32bit, 1GB for 64bit */
if (is_32bit_task())
- rnd = (unsigned long)get_random_int() % (1<<(23-PAGE_SHIFT));
+ rnd = get_random_long() % (1<<(23-PAGE_SHIFT));
else
- rnd = (unsigned long)get_random_int() % (1<<(30-PAGE_SHIFT));
+ rnd = get_random_long() % (1UL<<(30-PAGE_SHIFT));

return rnd << PAGE_SHIFT;
}
diff --git a/arch/sparc/kernel/sys_sparc_64.c b/arch/sparc/kernel/sys_sparc_64.c
index c690c8e16a96..b489e9759518 100644
--- a/arch/sparc/kernel/sys_sparc_64.c
+++ b/arch/sparc/kernel/sys_sparc_64.c
@@ -264,7 +264,7 @@ static unsigned long mmap_rnd(void)
unsigned long rnd = 0UL;

if (current->flags & PF_RANDOMIZE) {
- unsigned long val = get_random_int();
+ unsigned long val = get_random_long();
if (test_thread_flag(TIF_32BIT))
rnd = (val % (1UL << (23UL-PAGE_SHIFT)));
else
diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c
index 389939f74dd5..d2dc0438d654 100644
--- a/arch/x86/mm/mmap.c
+++ b/arch/x86/mm/mmap.c
@@ -71,12 +71,12 @@ unsigned long arch_mmap_rnd(void)

if (mmap_is_ia32())
#ifdef CONFIG_COMPAT
- rnd = (unsigned long)get_random_int() & ((1 << mmap_rnd_compat_bits) - 1);
+ rnd = get_random_long() & ((1UL << mmap_rnd_compat_bits) - 1);
#else
- rnd = (unsigned long)get_random_int() & ((1 << mmap_rnd_bits) - 1);
+ rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);
#endif
else
- rnd = (unsigned long)get_random_int() & ((1 << mmap_rnd_bits) - 1);
+ rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);

return rnd << PAGE_SHIFT;
}
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 3a93755e880f..0c52941dd62c 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -651,7 +651,7 @@ static unsigned long randomize_stack_top(unsigned long stack_top)

if ((current->flags & PF_RANDOMIZE) &&
!(current->personality & ADDR_NO_RANDOMIZE)) {
- random_variable = (unsigned long) get_random_int();
+ random_variable = get_random_long();
random_variable &= STACK_RND_MASK;
random_variable <<= PAGE_SHIFT;
}
--
2.10.2


--
Ben Hutchings
Software Developer, Codethink Ltd.


[PATCH 4.4-cip 0/5] Faster page poisoning for security

Ben Hutchings <ben.hutchings@...>
 

This is a backport of changes in 4.6 to add new config options to page
poisoning. Page poisoning was originally intended a debug feature for
finding use-after-free bugs in the kernel, but it can also be a security
feature, mitigating the security impact of such bugs. Unfortunately, it
normally has a significant performance cost. The new options
(CONFIG_PAGE_POISONING_NO_SANITY and CONFIG_PAGE_POISONING_ZERO) can be
enabled to reduce the performance cost, though they also reduce the
likelihood of detecting when such a bug has been triggered.

Enable CONFIG_PAGE_POISONING plus the new options can make some such
bugs harder to exploit, at a small performance cost (you'll need to
measure it yourself).

For this and other backports, I'm looking for feedback like:
- Did I miss a follow-up fix or an earlier dependency?
- Does this cause a regression (other than as explained above)?
- Are you likely to use it?
- Are there related features you want in 4.4?

Ben.

Joonsoo Kim (3):
mm/slab: activate debug_pagealloc in SLAB when it is actually enabled
mm/slab: use more appropriate condition check for debug_pagealloc
mm/slab: clean up DEBUG_PAGEALLOC processing code

Laura Abbott (2):
mm/page_poison.c: enable PAGE_POISONING as a separate option
mm/page_poisoning.c: allow for zero poisoning

Documentation/kernel-parameters.txt | 5 ++
include/linux/mm.h | 23 ++++++--
include/linux/poison.h | 4 ++
kernel/power/hibernate.c | 17 ++++++
mm/Kconfig.debug | 39 ++++++++++++-
mm/Makefile | 2 +-
mm/page_alloc.c | 13 ++++-
mm/page_ext.c | 10 +++-
mm/{debug-pagealloc.c => page_poison.c} | 67 +++++++++++++++++-----
mm/slab.c | 98 +++++++++++++++++----------------
10 files changed, 208 insertions(+), 70 deletions(-)
rename mm/{debug-pagealloc.c => page_poison.c} (64%)

--
2.10.2


--
Ben Hutchings
Software Developer, Codethink Ltd.


[PATCH 4.4-cip 1/5] mm/slab: activate debug_pagealloc in SLAB when it is actually enabled

Ben Hutchings <ben.hutchings@...>
 

From: Joonsoo Kim <iamjoonsoo.kim@lge.com>

commit a307ebd468e0b97c203f5a99a56a6017e4d1991a upstream.

Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Acked-by: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
---
mm/slab.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index 4765c97ce690..ed7eb6c92c81 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1847,7 +1847,8 @@ static void slab_destroy_debugcheck(struct kmem_cache *cachep,

if (cachep->flags & SLAB_POISON) {
#ifdef CONFIG_DEBUG_PAGEALLOC
- if (cachep->size % PAGE_SIZE == 0 &&
+ if (debug_pagealloc_enabled() &&
+ cachep->size % PAGE_SIZE == 0 &&
OFF_SLAB(cachep))
kernel_map_pages(virt_to_page(objp),
cachep->size / PAGE_SIZE, 1);
@@ -2187,7 +2188,8 @@ __kmem_cache_create (struct kmem_cache *cachep, unsigned long flags)
* to check size >= 256. It guarantees that all necessary small
* sized slab is initialized in current slab initialization sequence.
*/
- if (!slab_early_init && size >= kmalloc_size(INDEX_NODE) &&
+ if (debug_pagealloc_enabled() &&
+ !slab_early_init && size >= kmalloc_size(INDEX_NODE) &&
size >= 256 && cachep->object_size > cache_line_size() &&
ALIGN(size, cachep->align) < PAGE_SIZE) {
cachep->obj_offset += PAGE_SIZE - ALIGN(size, cachep->align);
@@ -2243,7 +2245,8 @@ __kmem_cache_create (struct kmem_cache *cachep, unsigned long flags)
* poisoning, then it's going to smash the contents of
* the redzone and userword anyhow, so switch them off.
*/
- if (size % PAGE_SIZE == 0 && flags & SLAB_POISON)
+ if (debug_pagealloc_enabled() &&
+ size % PAGE_SIZE == 0 && flags & SLAB_POISON)
flags &= ~(SLAB_RED_ZONE | SLAB_STORE_USER);
#endif
}
@@ -2737,7 +2740,8 @@ static void *cache_free_debugcheck(struct kmem_cache *cachep, void *objp,
set_obj_status(page, objnr, OBJECT_FREE);
if (cachep->flags & SLAB_POISON) {
#ifdef CONFIG_DEBUG_PAGEALLOC
- if ((cachep->size % PAGE_SIZE)==0 && OFF_SLAB(cachep)) {
+ if (debug_pagealloc_enabled() &&
+ (cachep->size % PAGE_SIZE) == 0 && OFF_SLAB(cachep)) {
store_stackinfo(cachep, objp, caller);
kernel_map_pages(virt_to_page(objp),
cachep->size / PAGE_SIZE, 0);
@@ -2874,7 +2878,8 @@ static void *cache_alloc_debugcheck_after(struct kmem_cache *cachep,
return objp;
if (cachep->flags & SLAB_POISON) {
#ifdef CONFIG_DEBUG_PAGEALLOC
- if ((cachep->size % PAGE_SIZE) == 0 && OFF_SLAB(cachep))
+ if (debug_pagealloc_enabled() &&
+ (cachep->size % PAGE_SIZE) == 0 && OFF_SLAB(cachep))
kernel_map_pages(virt_to_page(objp),
cachep->size / PAGE_SIZE, 1);
else
--
2.10.2



--
Ben Hutchings
Software Developer, Codethink Ltd.


[PATCH 4.4-cip 2/5] mm/slab: use more appropriate condition check for debug_pagealloc

Ben Hutchings <ben.hutchings@...>
 

From: Joonsoo Kim <iamjoonsoo.kim@lge.com>

commit 40323278b557a5909bbecfa181c91a3af7afbbe3 upstream.

debug_pagealloc debugging is related to SLAB_POISON flag rather than
FORCED_DEBUG option, although FORCED_DEBUG option will enable
SLAB_POISON. Fix it.

Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Acked-by: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
---
mm/slab.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index ed7eb6c92c81..62a7e4d3dde3 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2180,7 +2180,6 @@ __kmem_cache_create (struct kmem_cache *cachep, unsigned long flags)
else
size += BYTES_PER_WORD;
}
-#if FORCED_DEBUG && defined(CONFIG_DEBUG_PAGEALLOC)
/*
* To activate debug pagealloc, off-slab management is necessary
* requirement. In early phase of initialization, small sized slab
@@ -2188,7 +2187,7 @@ __kmem_cache_create (struct kmem_cache *cachep, unsigned long flags)
* to check size >= 256. It guarantees that all necessary small
* sized slab is initialized in current slab initialization sequence.
*/
- if (debug_pagealloc_enabled() &&
+ if (debug_pagealloc_enabled() && (flags & SLAB_POISON) &&
!slab_early_init && size >= kmalloc_size(INDEX_NODE) &&
size >= 256 && cachep->object_size > cache_line_size() &&
ALIGN(size, cachep->align) < PAGE_SIZE) {
@@ -2196,7 +2195,6 @@ __kmem_cache_create (struct kmem_cache *cachep, unsigned long flags)
size = PAGE_SIZE;
}
#endif
-#endif

/*
* Determine if the slab management is 'on' or 'off' slab.
--
2.10.2



--
Ben Hutchings
Software Developer, Codethink Ltd.


[PATCH 4.4-cip 3/5] mm/slab: clean up DEBUG_PAGEALLOC processing code

Ben Hutchings <ben.hutchings@...>
 

From: Joonsoo Kim <iamjoonsoo.kim@lge.com>

commit 40b44137971c2e5865a78f9f7de274449983ccb5 upstream.

Currently, open code for checking DEBUG_PAGEALLOC cache is spread to
some sites. It makes code unreadable and hard to change.

This patch cleans up this code. The following patch will change the
criteria for DEBUG_PAGEALLOC cache so this clean-up will help it, too.

[akpm@linux-foundation.org: fix build with CONFIG_DEBUG_PAGEALLOC=n]
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
---
include/linux/mm.h | 12 ++++---
mm/slab.c | 97 +++++++++++++++++++++++++++---------------------------
2 files changed, 57 insertions(+), 52 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index f0ffa01c90d9..b93d147439f9 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2148,14 +2148,18 @@ kernel_map_pages(struct page *page, int numpages, int enable)
}
#ifdef CONFIG_HIBERNATION
extern bool kernel_page_present(struct page *page);
-#endif /* CONFIG_HIBERNATION */
-#else
+#endif /* CONFIG_HIBERNATION */
+#else /* CONFIG_DEBUG_PAGEALLOC */
static inline void
kernel_map_pages(struct page *page, int numpages, int enable) {}
#ifdef CONFIG_HIBERNATION
static inline bool kernel_page_present(struct page *page) { return true; }
-#endif /* CONFIG_HIBERNATION */
-#endif
+#endif /* CONFIG_HIBERNATION */
+static inline bool debug_pagealloc_enabled(void)
+{
+ return false;
+}
+#endif /* CONFIG_DEBUG_PAGEALLOC */

#ifdef __HAVE_ARCH_GATE_AREA
extern struct vm_area_struct *get_gate_vma(struct mm_struct *mm);
diff --git a/mm/slab.c b/mm/slab.c
index 62a7e4d3dde3..aa11af56f139 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1670,6 +1670,14 @@ static void kmem_rcu_free(struct rcu_head *head)
}

#if DEBUG
+static bool is_debug_pagealloc_cache(struct kmem_cache *cachep)
+{
+ if (debug_pagealloc_enabled() && OFF_SLAB(cachep) &&
+ (cachep->size % PAGE_SIZE) == 0)
+ return true;
+
+ return false;
+}

#ifdef CONFIG_DEBUG_PAGEALLOC
static void store_stackinfo(struct kmem_cache *cachep, unsigned long *addr,
@@ -1703,6 +1711,23 @@ static void store_stackinfo(struct kmem_cache *cachep, unsigned long *addr,
}
*addr++ = 0x87654321;
}
+
+static void slab_kernel_map(struct kmem_cache *cachep, void *objp,
+ int map, unsigned long caller)
+{
+ if (!is_debug_pagealloc_cache(cachep))
+ return;
+
+ if (caller)
+ store_stackinfo(cachep, objp, caller);
+
+ kernel_map_pages(virt_to_page(objp), cachep->size / PAGE_SIZE, map);
+}
+
+#else
+static inline void slab_kernel_map(struct kmem_cache *cachep, void *objp,
+ int map, unsigned long caller) {}
+
#endif

static void poison_obj(struct kmem_cache *cachep, void *addr, unsigned char val)
@@ -1781,6 +1806,9 @@ static void check_poison_obj(struct kmem_cache *cachep, void *objp)
int size, i;
int lines = 0;

+ if (is_debug_pagealloc_cache(cachep))
+ return;
+
realobj = (char *)objp + obj_offset(cachep);
size = cachep->object_size;

@@ -1846,17 +1874,8 @@ static void slab_destroy_debugcheck(struct kmem_cache *cachep,
void *objp = index_to_obj(cachep, page, i);

if (cachep->flags & SLAB_POISON) {
-#ifdef CONFIG_DEBUG_PAGEALLOC
- if (debug_pagealloc_enabled() &&
- cachep->size % PAGE_SIZE == 0 &&
- OFF_SLAB(cachep))
- kernel_map_pages(virt_to_page(objp),
- cachep->size / PAGE_SIZE, 1);
- else
- check_poison_obj(cachep, objp);
-#else
check_poison_obj(cachep, objp);
-#endif
+ slab_kernel_map(cachep, objp, 1, 0);
}
if (cachep->flags & SLAB_RED_ZONE) {
if (*dbg_redzone1(cachep, objp) != RED_INACTIVE)
@@ -2237,16 +2256,6 @@ __kmem_cache_create (struct kmem_cache *cachep, unsigned long flags)
if (flags & CFLGS_OFF_SLAB) {
/* really off slab. No need for manual alignment */
freelist_size = calculate_freelist_size(cachep->num, 0);
-
-#ifdef CONFIG_PAGE_POISONING
- /* If we're going to use the generic kernel_map_pages()
- * poisoning, then it's going to smash the contents of
- * the redzone and userword anyhow, so switch them off.
- */
- if (debug_pagealloc_enabled() &&
- size % PAGE_SIZE == 0 && flags & SLAB_POISON)
- flags &= ~(SLAB_RED_ZONE | SLAB_STORE_USER);
-#endif
}

cachep->colour_off = cache_line_size();
@@ -2262,7 +2271,19 @@ __kmem_cache_create (struct kmem_cache *cachep, unsigned long flags)
cachep->size = size;
cachep->reciprocal_buffer_size = reciprocal_value(size);

- if (flags & CFLGS_OFF_SLAB) {
+#if DEBUG
+ /*
+ * If we're going to use the generic kernel_map_pages()
+ * poisoning, then it's going to smash the contents of
+ * the redzone and userword anyhow, so switch them off.
+ */
+ if (IS_ENABLED(CONFIG_PAGE_POISONING) &&
+ (cachep->flags & SLAB_POISON) &&
+ is_debug_pagealloc_cache(cachep))
+ cachep->flags &= ~(SLAB_RED_ZONE | SLAB_STORE_USER);
+#endif
+
+ if (OFF_SLAB(cachep)) {
cachep->freelist_cache = kmalloc_slab(freelist_size, 0u);
/*
* This is a possibility for one of the kmalloc_{dma,}_caches.
@@ -2489,9 +2510,6 @@ static void cache_init_objs(struct kmem_cache *cachep,
for (i = 0; i < cachep->num; i++) {
void *objp = index_to_obj(cachep, page, i);
#if DEBUG
- /* need to poison the objs? */
- if (cachep->flags & SLAB_POISON)
- poison_obj(cachep, objp, POISON_FREE);
if (cachep->flags & SLAB_STORE_USER)
*dbg_userword(cachep, objp) = NULL;

@@ -2515,10 +2533,11 @@ static void cache_init_objs(struct kmem_cache *cachep,
slab_error(cachep, "constructor overwrote the"
" start of an object");
}
- if ((cachep->size % PAGE_SIZE) == 0 &&
- OFF_SLAB(cachep) && cachep->flags & SLAB_POISON)
- kernel_map_pages(virt_to_page(objp),
- cachep->size / PAGE_SIZE, 0);
+ /* need to poison the objs? */
+ if (cachep->flags & SLAB_POISON) {
+ poison_obj(cachep, objp, POISON_FREE);
+ slab_kernel_map(cachep, objp, 0, 0);
+ }
#else
if (cachep->ctor)
cachep->ctor(objp);
@@ -2737,18 +2756,8 @@ static void *cache_free_debugcheck(struct kmem_cache *cachep, void *objp,

set_obj_status(page, objnr, OBJECT_FREE);
if (cachep->flags & SLAB_POISON) {
-#ifdef CONFIG_DEBUG_PAGEALLOC
- if (debug_pagealloc_enabled() &&
- (cachep->size % PAGE_SIZE) == 0 && OFF_SLAB(cachep)) {
- store_stackinfo(cachep, objp, caller);
- kernel_map_pages(virt_to_page(objp),
- cachep->size / PAGE_SIZE, 0);
- } else {
- poison_obj(cachep, objp, POISON_FREE);
- }
-#else
poison_obj(cachep, objp, POISON_FREE);
-#endif
+ slab_kernel_map(cachep, objp, 0, caller);
}
return objp;
}
@@ -2875,16 +2884,8 @@ static void *cache_alloc_debugcheck_after(struct kmem_cache *cachep,
if (!objp)
return objp;
if (cachep->flags & SLAB_POISON) {
-#ifdef CONFIG_DEBUG_PAGEALLOC
- if (debug_pagealloc_enabled() &&
- (cachep->size % PAGE_SIZE) == 0 && OFF_SLAB(cachep))
- kernel_map_pages(virt_to_page(objp),
- cachep->size / PAGE_SIZE, 1);
- else
- check_poison_obj(cachep, objp);
-#else
check_poison_obj(cachep, objp);
-#endif
+ slab_kernel_map(cachep, objp, 1, 0);
poison_obj(cachep, objp, POISON_INUSE);
}
if (cachep->flags & SLAB_STORE_USER)
--
2.10.2



--
Ben Hutchings
Software Developer, Codethink Ltd.


[PATCH 4.4-cip 4/5] mm/page_poison.c: enable PAGE_POISONING as a separate option

Ben Hutchings <ben.hutchings@...>
 

From: Laura Abbott <labbott@fedoraproject.org>

commit 8823b1dbc05fab1a8bec275eeae4709257c2661d upstream.

Page poisoning is currently set up as a feature if architectures don't
have architecture debug page_alloc to allow unmapping of pages. It has
uses apart from that though. Clearing of the pages on free provides an
increase in security as it helps to limit the risk of information leaks.
Allow page poisoning to be enabled as a separate option independent of
kernel_map pages since the two features do separate work. Because of
how hiberanation is implemented, the checks on alloc cannot occur if
hibernation is enabled. The runtime alloc checks can also be enabled
with an option when !HIBERNATION.

Credit to Grsecurity/PaX team for inspiring this work

Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Mathias Krause <minipli@googlemail.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Jianyu Zhan <nasa4836@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
---
Documentation/kernel-parameters.txt | 5 +++
include/linux/mm.h | 9 +++++
mm/Kconfig.debug | 25 +++++++++++++-
mm/Makefile | 2 +-
mm/page_alloc.c | 2 ++
mm/{debug-pagealloc.c => page_poison.c} | 60 ++++++++++++++++++++++++++-------
6 files changed, 89 insertions(+), 14 deletions(-)
rename mm/{debug-pagealloc.c => page_poison.c} (67%)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index c360f80c3473..37180e331185 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2672,6 +2672,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
we can turn it on.
on: enable the feature

+ page_poison= [KNL] Boot-time parameter changing the state of
+ poisoning on the buddy allocator.
+ off: turn off poisoning
+ on: turn on poisoning
+
panic= [KNL] Kernel behaviour on panic: delay <timeout>
timeout > 0: seconds before rebooting
timeout = 0: wait forever
diff --git a/include/linux/mm.h b/include/linux/mm.h
index b93d147439f9..56272e69c9a3 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2129,6 +2129,15 @@ static inline void vm_stat_account(struct mm_struct *mm,
}
#endif /* CONFIG_PROC_FS */

+#ifdef CONFIG_PAGE_POISONING
+extern bool page_poisoning_enabled(void);
+extern void kernel_poison_pages(struct page *page, int numpages, int enable);
+#else
+static inline bool page_poisoning_enabled(void) { return false; }
+static inline void kernel_poison_pages(struct page *page, int numpages,
+ int enable) { }
+#endif
+
#ifdef CONFIG_DEBUG_PAGEALLOC
extern bool _debug_pagealloc_enabled;
extern void __kernel_map_pages(struct page *page, int numpages, int enable);
diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
index 957d3da53ddd..35d68954ad34 100644
--- a/mm/Kconfig.debug
+++ b/mm/Kconfig.debug
@@ -27,4 +27,27 @@ config DEBUG_PAGEALLOC
a resume because free pages are not saved to the suspend image.

config PAGE_POISONING
- bool
+ bool "Poison pages after freeing"
+ select PAGE_EXTENSION
+ select PAGE_POISONING_NO_SANITY if HIBERNATION
+ ---help---
+ Fill the pages with poison patterns after free_pages() and verify
+ the patterns before alloc_pages. The filling of the memory helps
+ reduce the risk of information leaks from freed data. This does
+ have a potential performance impact.
+
+ Note that "poison" here is not the same thing as the "HWPoison"
+ for CONFIG_MEMORY_FAILURE. This is software poisoning only.
+
+ If unsure, say N
+
+config PAGE_POISONING_NO_SANITY
+ depends on PAGE_POISONING
+ bool "Only poison, don't sanity check"
+ ---help---
+ Skip the sanity checking on alloc, only fill the pages with
+ poison on free. This reduces some of the overhead of the
+ poisoning feature.
+
+ If you are only interested in sanitization, say Y. Otherwise
+ say N.
diff --git a/mm/Makefile b/mm/Makefile
index 2ed43191fc3b..cfdd481d27a5 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -48,7 +48,7 @@ obj-$(CONFIG_SPARSEMEM_VMEMMAP) += sparse-vmemmap.o
obj-$(CONFIG_SLOB) += slob.o
obj-$(CONFIG_MMU_NOTIFIER) += mmu_notifier.o
obj-$(CONFIG_KSM) += ksm.o
-obj-$(CONFIG_PAGE_POISONING) += debug-pagealloc.o
+obj-$(CONFIG_PAGE_POISONING) += page_poison.o
obj-$(CONFIG_SLAB) += slab.o
obj-$(CONFIG_SLUB) += slub.o
obj-$(CONFIG_KMEMCHECK) += kmemcheck.o
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 2bcdfbf8c36d..94e98734ecd9 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1004,6 +1004,7 @@ static bool free_pages_prepare(struct page *page, unsigned int order)
PAGE_SIZE << order);
}
arch_free_page(page, order);
+ kernel_poison_pages(page, 1 << order, 0);
kernel_map_pages(page, 1 << order, 0);

return true;
@@ -1399,6 +1400,7 @@ static int prep_new_page(struct page *page, unsigned int order, gfp_t gfp_flags,

arch_alloc_page(page, order);
kernel_map_pages(page, 1 << order, 1);
+ kernel_poison_pages(page, 1 << order, 1);
kasan_alloc_pages(page, order);

if (gfp_flags & __GFP_ZERO)
diff --git a/mm/debug-pagealloc.c b/mm/page_poison.c
similarity index 67%
rename from mm/debug-pagealloc.c
rename to mm/page_poison.c
index 5bf5906ce13b..89d3bc773633 100644
--- a/mm/debug-pagealloc.c
+++ b/mm/page_poison.c
@@ -6,22 +6,48 @@
#include <linux/poison.h>
#include <linux/ratelimit.h>

-static bool page_poisoning_enabled __read_mostly;
+static bool __page_poisoning_enabled __read_mostly;
+static bool want_page_poisoning __read_mostly;

-static bool need_page_poisoning(void)
+static int early_page_poison_param(char *buf)
{
- if (!debug_pagealloc_enabled())
- return false;
+ if (!buf)
+ return -EINVAL;
+
+ if (strcmp(buf, "on") == 0)
+ want_page_poisoning = true;
+ else if (strcmp(buf, "off") == 0)
+ want_page_poisoning = false;

- return true;
+ return 0;
+}
+early_param("page_poison", early_page_poison_param);
+
+bool page_poisoning_enabled(void)
+{
+ return __page_poisoning_enabled;
+}
+
+static bool need_page_poisoning(void)
+{
+ return want_page_poisoning;
}

static void init_page_poisoning(void)
{
- if (!debug_pagealloc_enabled())
- return;
+ /*
+ * page poisoning is debug page alloc for some arches. If either
+ * of those options are enabled, enable poisoning
+ */
+ if (!IS_ENABLED(CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC)) {
+ if (!want_page_poisoning && !debug_pagealloc_enabled())
+ return;
+ } else {
+ if (!want_page_poisoning)
+ return;
+ }

- page_poisoning_enabled = true;
+ __page_poisoning_enabled = true;
}

struct page_ext_operations page_poisoning_ops = {
@@ -83,6 +109,9 @@ static void check_poison_mem(unsigned char *mem, size_t bytes)
unsigned char *start;
unsigned char *end;

+ if (IS_ENABLED(CONFIG_PAGE_POISONING_NO_SANITY))
+ return;
+
start = memchr_inv(mem, PAGE_POISON, bytes);
if (!start)
return;
@@ -95,9 +124,9 @@ static void check_poison_mem(unsigned char *mem, size_t bytes)
if (!__ratelimit(&ratelimit))
return;
else if (start == end && single_bit_flip(*start, PAGE_POISON))
- printk(KERN_ERR "pagealloc: single bit error\n");
+ pr_err("pagealloc: single bit error\n");
else
- printk(KERN_ERR "pagealloc: memory corruption\n");
+ pr_err("pagealloc: memory corruption\n");

print_hex_dump(KERN_ERR, "", DUMP_PREFIX_ADDRESS, 16, 1, start,
end - start + 1, 1);
@@ -125,9 +154,9 @@ static void unpoison_pages(struct page *page, int n)
unpoison_page(page + i);
}

-void __kernel_map_pages(struct page *page, int numpages, int enable)
+void kernel_poison_pages(struct page *page, int numpages, int enable)
{
- if (!page_poisoning_enabled)
+ if (!page_poisoning_enabled())
return;

if (enable)
@@ -135,3 +164,10 @@ void __kernel_map_pages(struct page *page, int numpages, int enable)
else
poison_pages(page, numpages);
}
+
+#ifndef CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC
+void __kernel_map_pages(struct page *page, int numpages, int enable)
+{
+ /* This function does nothing, all work is done via poison pages */
+}
+#endif
--
2.10.2



--
Ben Hutchings
Software Developer, Codethink Ltd.

81 - 100 of 7061