As mentioned in commit afe4fd0624 ("pkt_sched: fq: Fair Queue packet
scheduler"), this patch adds a new socket option.
SO_MAX_PACING_RATE offers the application the ability to cap the
rate computed by transport layer. Value is in bytes per second.
u32 val = 1000000;
setsockopt(sockfd, SOL_SOCKET, SO_MAX_PACING_RATE, &val, sizeof(val));
To be effectively paced, a flow must use FQ packet scheduler.
Note that a packet scheduler takes into account the headers for its
computations. The effective payload rate depends on MSS and retransmits
if any.
I chose to make this pacing rate a SOL_SOCKET option instead of a
TCP one because this can be used by other protocols.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Steinar H. Gunderson <sesse@google.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Change-Id: Iea51b6104a5420d5c9ed1ea7382cbd53bdb8f4be
This is a warning so that developers know to add more restart
order lists to SSR when a new chip is added. This is mostly
irrelevant now because we assume either entire SoC restart on SSR
or independent restart on SSR, not group restarts. Remove this
warning as it is mostly a reminder that nobody is listening for.
Change-Id: Icbf955cb18395d8d5d086b2167c5c329588b9256
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
[suggested by Rasmus Villemoes] make O_DIRECTORY | O_RDWR part of O_TMPFILE;
that will fail on old kernels in a lot more cases than what I came up with.
And make sure O_CREAT doesn't get there...
Change-Id: I90b6ad396a8053eadd5cb32501f55cbb1d4be2db
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
getname() is intended to copy pathname strings from userspace into a
kernel buffer. The result is just a string in kernel space. It would
however be quite helpful to be able to attach some ancillary info to
the string.
For instance, we could attach some audit-related info to reduce the
amount of audit-related processing needed. When auditing is enabled,
we could also call getname() on the string more than once and not
need to recopy it from userspace.
This patchset converts the getname()/putname() interfaces to return
a struct instead of a string. For now, the struct just tracks the
string in kernel space and the original userland pointer for it.
Later, we'll add other information to the struct as it becomes
convenient.
Change-Id: Ib690c3dd4d56624f0ddb081e1c1d4f23c2dd0cd1
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
releases what needs to be released after {kern,user}_path_create()
Change-Id: If7fa7455e2ba8a6f4f4c4d2db502a38b4a60d7c7
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
It was scheduled to be removed for a long time.
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netfilter@vger.kernel.org
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Change-Id: Iae2ab6490a36ecde8fb9ee5b65e4448969f74b07
There is a bug on some hardware that requires us to overmap Iommu
mappings by 2x. Currently, we set aside a dummy buffer onto which we
map all of these dummy mappings. In general, for large mappings it's
nice to use the more efficient iommu_map_range instead of calling
iommu_map repeatedly. However, with our current approach in
msm_iommu_map_extra we can't use iommu_map_range for page_sizes larger
than the dummy buffer. To avoid wasting memory by increasing the size
of the dummy buffer, we can simply remap on top of the the buffer
being mapped in the first place. Since the second mapping should never
be used (besides by the buggy hardware) this should not be a problem.
Re-use existing buffers for all `extra' mappings. Essentially, map the
same physical address range twice. To be extra safe, make the second
mapping read-only.
Change-Id: I35462ad50de8da1f2befa3e3f0895925535cdc98
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
On the low-class hardware like flo this only introduces issues
and performance degradation due to increased scheduler overhead.
Revert "arm: configs: flo: set CONFIG_HZ to 300"
This reverts commit 029a1baa6f.
Revert "ARM: msm: flo: fix idle_timeout value to 100ms"
This reverts commit a63fd90f21.
Revert "msm: kgsl: Fix direct references to HZ"
This reverts commit 38d48e1127.
Change-Id: Ib65977c959bff9cce43f5039f8f543e074992fec
Revert "sched_clock: Avoid corrupting hrtimer tree during suspend"
This reverts commit 8aad725c70.
Revert "sched_clock: Add support for >32 bit sched_clock"
This reverts commit 657eb100e4.
Revert "sched_clock: Use an hrtimer instead of timer"
This reverts commit b2ee62ec51.
Revert "sched_clock: Use seqcount instead of rolling our own"
This reverts commit 538b187b6e.
Revert "ARM: sched_clock: Load cycle count after epoch stabilizes"
This reverts commit 8c7175ba39.
Revert "sched_clock: Make ARM's sched_clock generic for all architectures"
This reverts commit ebb97da74a.
Revert "ARM: 7699/1: sched_clock: Add more notrace to prevent recursion"
This reverts commit 086da6a6c4.
Revert "ARM: make sched_clock just call a function pointer"
This reverts commit 0dd4fad6c9.
Revert "ARM: sched_clock: allow changing to higher frequency counter"
This reverts commit 4a3cf85432.
Change-Id: I98aaec7b554a2e11be4c551a864d952e0d8c3e22
The list usage in msm_bus_dbg driver are not correct which will cause
kernel panic.
. The list operation should be protected by a lock, e.g. mutex_lock.
. The list entry should only be operated on a valid entry.
Change-Id: I19efeb346d1bacf129ccfd7a6511bc795c029afc
Signed-off-by: Lianwei Wang <lian-wei.wang@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/384275
Reviewed-by: Guo-Jian Chen <A21757@motorola.com>
Reviewed-by: Ke Lv <a2435c@motorola.com>
Tested-by: Jira Key <JIRAKEY@motorola.com>
Reviewed-by: Jeffrey Carlyle <jeff.carlyle@motorola.com>
Reviewed-by: Check Patch <CHEKPACH@motorola.com>
Reviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>
Reviewed-by: Tao Hu <taohu@motorola.com>
(cherry picked from commit d109d8d7e2998a635406215a559e298fa7ef4bb8)
Validate a buffer virtual address is fully within the region before
returning the region to ensure functionality for an extended edge
case.
Change-Id: Iba3e080889980f393d6a9f0afe0231408b92d654
Signed-off-by: Siena Richard <sienar@codeaurora.org>
CRs-fixed: 1108461
(cherry picked from commit 208e72e59c8411e75d4118b48648a5b7d42b1682)
CONFIG_CC_OPTIMIZE_FOR_SIZE is set on modern android devices.
Originally this config was set with the assumption that smaller
code size would yield hot cache lines and faster code, however,
that's not the case today.
Signed-off-by: Wei Wang <wvw@google.com>
Change-Id: Ib127ede04e700650b97541d6cca16da659f45c69
The configs for this is used for Bluez.
So, there is no reason to keep this that causes the Security
Vulnerability.
Bug: 63527053
Change-Id: Ia25a8268412ce58c6a162953af3602634b219669
Signed-off-by: Ecco Park <eccopark@google.com>
Nothing about the sched_clock implementation in the ARM port is
specific to the architecture. Generalize the code so that other
architectures can use it by selecting GENERIC_SCHED_CLOCK.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
[jstultz: Merge minor collisions with other patches in my tree]
Signed-off-by: John Stultz <john.stultz@linaro.org>
Git-commit: 38ff87f77a
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[imaund@codeaurora.org: resolve merge conflicts]
Signed-off-by: Ian Maund <imaund@codeaurora.org>
[flex1911: backport to 3.4]
Signed-off-by: Artem Borisov <dedsa2002@gmail.com>
Change-Id: I798c7c58dc9f476b07e60958a970aff7ceb4b797
cyc_to_sched_clock() is called by sched_clock() and cyc_to_ns()
is called by cyc_to_sched_clock(). I suspect that some compilers
inline both of these functions into sched_clock() and so we've
been getting away without having a notrace marking. It seems that
my compiler isn't inlining cyc_to_sched_clock() though, so I'm
hitting a recursion bug when I enable the function graph tracer,
causing my system to crash. Marking these functions notrace fixes
it. Technically cyc_to_ns() doesn't need the notrace because it's
already marked inline, but let's just add it so that if we ever
remove inline from that function it doesn't blow up.
Change-Id: I18b0b4a41eb22fd454a9cd11cfeb73cec1327e92
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This converts sched_clock to simply a call to a function pointer in order
to allow overriding it. This will allow for use with 64-bit counters where
overflow handling is not needed.
Change-Id: Ia2b5c1382f845e28efc80365d52debd3d122b519
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Allow multiple calls to setup_sched_clock and switch to the new counter
if it is higher frequency.
Change-Id: I482ee5d2ce20f114041347110c63d140d47e7da5
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
(cherry picked from commit https://lkml.org/lkml/2016/2/4/833)
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.
Bug: 26963541
Signed-off-by: Daniel Cashman <dcashman@android.com>
Signed-off-by: Daniel Cashman <dcashman@google.com>
Change-Id: Iac34b63294ec120edcbf8760186667a84a5cf556
(cherry picked from commit https://lkml.org/lkml/2015/12/21/339)
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.
Bug: 24047224
Signed-off-by: Daniel Cashman <dcashman@android.com>
Signed-off-by: Daniel Cashman <dcashman@google.com>
Change-Id: Id1fb53df5fedc909b79f3d952f120e6104900f24
IPC_32BIT originally was intended to be used on 4.4 and older userspaces,
because they didn't support new API and 64-bit pointers, but then it was
forced on 32-bit platforms because ARM didn't have essential 64-bit get_user() calls.
The main limitation of this option is that it is incompatible with new API,
so kernel and userspace should have same binder version to work properly.
Necessary calls were later introduced in commit "ARM: 8091/2: add get_user() support for 8 byte types"
and now AOSP and mainline are going towards removing old 32-bit binder API support.
64-bit binder is 100% compatible with 32-bit kernel and userspace,
so there is no reason for us to keep using the old solution anymore.
Change-Id: I91ce91a1a17ceb7110184657663e957bd8793d3f
Recent contributions, including to DRM and binder, introduce 64-bit
values in their interfaces. A common motivation for this is to allow
the same ABI for 32- and 64-bit userspaces (and therefore also a shared
ABI for 32/64 hybrid userspaces). Anyhow, the developers would like to
avoid gotchas like having to use copy_from_user().
This feature is already implemented on x86-32 and the majority of other
32-bit architectures. The current list of get_user_8 hold out
architectures are: arm, avr32, blackfin, m32r, metag, microblaze,
mn10300, sh.
Credit:
My name sits rather uneasily at the top of this patch. The v1 and
v2 versions of the patch were written by Rob Clark and to produce v4
I mostly copied code from Russell King and H. Peter Anvin. However I
have mangled the patch sufficiently that *blame* is rightfully mine
even if credit should more widely shared.
Changelog:
v5: updated to use the ret macro (requested by Russell King)
v4: remove an inlined add on big endian systems (spotted by Russell King),
used __ARMEB__ rather than BIG_ENDIAN (to match rest of file),
cleared r3 on EFAULT during __get_user_8.
v3: fix a couple of checkpatch issues
v2: pass correct size to check_uaccess, and better handling of narrowing
double word read with __get_user_xb() (Russell King's suggestion)
v1: original
Change-Id: I41787d73f0844c15b6bd0424a5f83cafaba8b508
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[flex1911: backport to 3.4: use "mov pc" instruction instead of
nonexistent here "ret" macro]
Signed-off-by: Artem Borisov <dedsa2002@gmail.com>
Clean cherry pick of eb6452537b.
Add the new getrandom syscall for ARM.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Bug: http://b/29621447
Change-Id: I6d50b57f3a61fbf9102c69103b9a5b7ebf239860
(cherry picked from commit eb6452537b)
[flex1911]: backport to 3.4
Almost clean cherry pick of c6e9d6f388,
includes change made by merge 0891ad829d.
The getrandom(2) system call was requested by the LibreSSL Portable
developers. It is analoguous to the getentropy(2) system call in
OpenBSD.
The rationale of this system call is to provide resiliance against
file descriptor exhaustion attacks, where the attacker consumes all
available file descriptors, forcing the use of the fallback code where
/dev/[u]random is not available. Since the fallback code is often not
well-tested, it is better to eliminate this potential failure mode
entirely.
The other feature provided by this new system call is the ability to
request randomness from the /dev/urandom entropy pool, but to block
until at least 128 bits of entropy has been accumulated in the
/dev/urandom entropy pool. Historically, the emphasis in the
/dev/urandom development has been to ensure that urandom pool is
initialized as quickly as possible after system boot, and preferably
before the init scripts start execution.
This is because changing /dev/urandom reads to block represents an
interface change that could potentially break userspace which is not
acceptable. In practice, on most x86 desktop and server systems, in
general the entropy pool can be initialized before it is needed (and
in modern kernels, we will printk a warning message if not). However,
on an embedded system, this may not be the case. And so with this new
interface, we can provide the functionality of blocking until the
urandom pool has been initialized. Any userspace program which uses
this new functionality must take care to assure that if it is used
during the boot process, that it will not cause the init scripts or
other portions of the system startup to hang indefinitely.
SYNOPSIS
#include <linux/random.h>
int getrandom(void *buf, size_t buflen, unsigned int flags);
DESCRIPTION
The system call getrandom() fills the buffer pointed to by buf
with up to buflen random bytes which can be used to seed user
space random number generators (i.e., DRBG's) or for other
cryptographic uses. It should not be used for Monte Carlo
simulations or other programs/algorithms which are doing
probabilistic sampling.
If the GRND_RANDOM flags bit is set, then draw from the
/dev/random pool instead of the /dev/urandom pool. The
/dev/random pool is limited based on the entropy that can be
obtained from environmental noise, so if there is insufficient
entropy, the requested number of bytes may not be returned.
If there is no entropy available at all, getrandom(2) will
either block, or return an error with errno set to EAGAIN if
the GRND_NONBLOCK bit is set in flags.
If the GRND_RANDOM bit is not set, then the /dev/urandom pool
will be used. Unlike using read(2) to fetch data from
/dev/urandom, if the urandom pool has not been sufficiently
initialized, getrandom(2) will block (or return -1 with the
errno set to EAGAIN if the GRND_NONBLOCK bit is set in flags).
The getentropy(2) system call in OpenBSD can be emulated using
the following function:
int getentropy(void *buf, size_t buflen)
{
int ret;
if (buflen > 256)
goto failure;
ret = getrandom(buf, buflen, 0);
if (ret < 0)
return ret;
if (ret == buflen)
return 0;
failure:
errno = EIO;
return -1;
}
RETURN VALUE
On success, the number of bytes that was filled in the buf is
returned. This may not be all the bytes requested by the
caller via buflen if insufficient entropy was present in the
/dev/random pool, or if the system call was interrupted by a
signal.
On error, -1 is returned, and errno is set appropriately.
ERRORS
EINVAL An invalid flag was passed to getrandom(2)
EFAULT buf is outside the accessible address space.
EAGAIN The requested entropy was not available, and
getentropy(2) would have blocked if the
GRND_NONBLOCK flag was not set.
EINTR While blocked waiting for entropy, the call was
interrupted by a signal handler; see the description
of how interrupted read(2) calls on "slow" devices
are handled with and without the SA_RESTART flag
in the signal(7) man page.
NOTES
For small requests (buflen <= 256) getrandom(2) will not
return EINTR when reading from the urandom pool once the
entropy pool has been initialized, and it will return all of
the bytes that have been requested. This is the recommended
way to use getrandom(2), and is designed for compatibility
with OpenBSD's getentropy() system call.
However, if you are using GRND_RANDOM, then getrandom(2) may
block until the entropy accounting determines that sufficient
environmental noise has been gathered such that getrandom(2)
will be operating as a NRBG instead of a DRBG for those people
who are working in the NIST SP 800-90 regime. Since it may
block for a long time, these guarantees do *not* apply. The
user may want to interrupt a hanging process using a signal,
so blocking until all of the requested bytes are returned
would be unfriendly.
For this reason, the user of getrandom(2) MUST always check
the return value, in case it returns some error, or if fewer
bytes than requested was returned. In the case of
!GRND_RANDOM and small request, the latter should never
happen, but the careful userspace code (and all crypto code
should be careful) should check for this anyway!
Finally, unless you are doing long-term key generation (and
perhaps not even then), you probably shouldn't be using
GRND_RANDOM. The cryptographic algorithms used for
/dev/urandom are quite conservative, and so should be
sufficient for all purposes. The disadvantage of GRND_RANDOM
is that it can block, and the increased complexity required to
deal with partially fulfilled getrandom(2) requests.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Zach Brown <zab@zabbo.net>
Bug: http://b/29621447
Change-Id: I189ba74070dd6d918b0fdf83ff30bb74ec0f7556
(cherry picked from commit 4af712e8df)
[flex1911]: backport to 3.4
The wakeup_reason driver works by having a callback log_wakeup_reason(), be
called by the resume path once for each wakeup interrupt, with the irq number
as argument. It then saves this interrupt in an array, and reports it when
requested (via /sys/kernel/wakeup_reasons/last_resume_reason) and also prints
the information out in kmsg.
This approach works, but it has the deficiency that often the reported wakeup
interrupt, while correct, is not the interrupt truly responsible for the
wakeup. The reason for this is due to chained interrupt controllers (whether
in hardware or simulated in software). It could be, for example, that the
power button is wired to a GPIO handled by a single interrupt for all GPIOs,
which interrupt then determines the GPIO and maps this to a software interrupt.
Whether this is done in software, or by chaining interrupt controllers, the end
result is that the wakeup reason will show not the interrupt associated with
the power button, but the base-GPIO interrupt instead.
This patch reworks the wakeup_sources driver such that it reports those final
interrupts we are interested in, and not the intermediate (and not the base)
ones. It does so as follows:
-- The assumption is that generic_handle_irq() is called to dispatch all
interrupts; due to this, chained interrupts result in recursive calls of
generic_handle_irq().
-- We reconstruct the chains of interrupts that originate with the base wakeup
interrupt and terminate with the interrupt we are interested in by tracing
the calls to generic_handle_irq()
-- The tracing works by maitaining a per-cpu counter that is incremented with
each call to generic_handle_irq(); that counter is reported to the
wakeup_sources driver by a pair of functions, called
log_possible_wakeup_reason_start() and log_possible_wakeup_reason_complete().
The former is called before generic_handle_irq() handles the interrupt
(thereby potentially calling itself recusively) and the latter afterward.
-- The two functions mentioned above are complemented by log_base_wake_reason()
(renamed from log_wakeup_reason()), which is used to report the base wakeup
interrupts to the wakeup_reason driver.
-- The three functions work together to build a set of trees, one per base
wakeup reason, the leaves of which correspond to the interrupts we are
interesed in; these trees can be arbitratily complex, though in reality they
most often are a single node, or a chain of two nodes. The complexity
supports arbitrarily involved interrupt dispatch.
-- On resume, we build the tree; once the tree is completed, we walk it
recursively, and print out to kmesg the (more useful) list of wakeup
sources; simiarly, we walk the tree and print the leaves when
/sys/kernel/wakeup_reasons/last_resume_reason is read.
Signed-off-by: Iliyan Malchev <malchev@google.com>
Change-Id: If8acb2951b61d2c6bcf4d011fe04d7f91057d139
Alter the signature of irq_flow_handler_t to return true for those interrupts
whose handlers were invoked, and false otherwise. Also rework the actual
handlers, handle_.*_irq, to support the new signature.
Change-Id: I8a50410c477692bbcd39a0fefdac14253602d1f5
Signed-off-by: Iliyan Malchev <malchev@google.com>
Modify the request_module to prefix the file system type with "fs-"
and add aliases to all of the filesystems that can be built as modules
to match.
A common practice is to build all of the kernel code and leave code
that is not commonly needed as modules, with the result that many
users are exposed to any bug anywhere in the kernel.
Looking for filesystems with a fs- prefix limits the pool of possible
modules that can be loaded by mount to just filesystems trivially
making things safer with no real cost.
Using aliases means user space can control the policy of which
filesystem modules are auto-loaded by editing /etc/modprobe.d/*.conf
with blacklist and alias directives. Allowing simple, safe,
well understood work-arounds to known problematic software.
This also addresses a rare but unfortunate problem where the filesystem
name is not the same as it's module name and module auto-loading
would not work. While writing this patch I saw a handful of such
cases. The most significant being autofs that lives in the module
autofs4.
This is relevant to user namespaces because we can reach the request
module in get_fs_type() without having any special permissions, and
people get uncomfortable when a user specified string (in this case
the filesystem type) goes all of the way to request_module.
After having looked at this issue I don't think there is any
particular reason to perform any filtering or permission checks beyond
making it clear in the module request that we want a filesystem
module. The common pattern in the kernel is to call request_module()
without regards to the users permissions. In general all a filesystem
module does once loaded is call register_filesystem() and go to sleep.
Which means there is not much attack surface exposed by loading a
filesytem module unless the filesystem is mounted. In a user
namespace filesystems are not mounted unless .fs_flags = FS_USERNS_MOUNT,
which most filesystems do not set today.
Change-Id: I623b13dbdb44bb9ba7481f29575e1ca4ad8102f4
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Acked-by: Kees Cook <keescook@chromium.org>
Reported-by: Kees Cook <keescook@google.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
commit 946e51f2bf37f1656916eb75bd0742ba33983c28 upstream.
Change-Id: I85366e6ce0423ec9620bcc9cd3e7695e81aa1171
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
[bwh: Backported to 3.2:
- Apply name changes in all the different places we use d_alias and d_child
- Move the WARN_ON() in __d_free() to d_free() as we don't have dentry_free()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[lizf: Backported to 3.4:
- adjust context
- need one more name change in debugfs]
* Use the old 32-bits binder API as our kernel runs on
ARM 32bits, it should not compile elements in 64bits,
which would end in failures with following output:
"undefined reference to `__get_user_bad'"
Change-Id: Ib27c00f19847d19ad574e07d6f3c0a53cfeebb32
Under CONFIG_STRICT_DEVMEM, reading System RAM through /dev/mem is
disallowed. However, on x86, the first 1MB was always allowed for BIOS
and similar things, regardless of it actually being System RAM. It was
possible for heap to end up getting allocated in low 1MB RAM, and then
read by things like x86info or dd, which would trip hardened usercopy:
usercopy: kernel memory exposure attempt detected from ffff880000090000 (dma-kmalloc-256) (4096 bytes)
This changes the x86 exception for the low 1MB by reading back zeros for
System RAM areas instead of blindly allowing them. More work is needed to
extend this to mmap, but currently mmap doesn't go through usercopy, so
hardened usercopy won't Oops the kernel.
Change-Id: I27594af6146e7643217e3babcfd088592b7dbd4b
Reported-by: Tommi Rantala <tommi.t.rantala@nokia.com>
Tested-by: Tommi Rantala <tommi.t.rantala@nokia.com>
Signed-off-by: Kees Cook <keescook@chromium.org>