1
0
Fork 0
mirror of https://github.com/followmsi/android_kernel_google_msm.git synced 2024-11-06 23:17:41 +00:00
Commit graph

70621 commits

Author SHA1 Message Date
Eric Dumazet
adc3caedd0 net: introduce SO_MAX_PACING_RATE
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
2020-11-30 19:31:32 +03:00
Stephen Boyd
09553d5278 msm: SSR: Remove useless warning
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>
2020-11-13 15:50:48 +01:00
Elektroschmock
bbafa74230 flo: defconfig: Remove unused USB storage drivers
reference:
https://source.android.com/devices/tech/perf/boot-times

Change-Id: Ie617f5e00587769a3e419ec6c8e1fb4678688842
2020-11-10 20:56:21 +01:00
elektroschmock
ed06b19dcc flo: defconfig: Disable CONFIG_USB_EHSET_TEST_FIXTURE
We're not going to do electrical tests on flo's usb ports

Change-Id: I4878b329a10ed0531beecec011fc7b578c15acb2
2020-11-09 21:31:14 +01:00
bohu
ff10168f46 Disable /dev/port
Bug: 36604779
BUG: 37646833

Signed-off-by: Bo Hu <bohu@google.com>
Test: run cts -m  CtsPermissionTestCases
-t android.permission.cts.FileSystemPermissionTest#testDevPortSane
Change-Id: Ie3155cb577e3f5e9c565129e3f007daded1a6328
2020-11-09 21:31:14 +01:00
Elektroschmock
a228ac4a97 flo: defconfig: disable some debug and logging options
Change-Id: I972aadc94d6e4e79b3ffa92f19b3d0f907bb5e13
2020-11-09 22:31:03 +02:00
Russell King
0fbdad1f0f ARM: wire up memfd_create syscall
Add the memfd_create syscall to ARM.

Change-Id: I857960ac11d1e574a7957325d2b754bcc31b902d
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2020-10-25 02:37:54 -04:00
Arne Coucheron
31a1482703 msm8960: Use tuned options when compiling
Change-Id: I52591c2eb5b6831e7302acf71e2c6c173d811c5e
2020-10-25 02:37:54 -04:00
Yatto
f24ec3f684 defconfig: flo: Enable CONFIG_NETFILTER_XT_TARGET_CT
* Fixes hotspot in many cases.

Change-Id: I30e3a58f91cb061ca6f4590e327ef91aeb44c73a
2020-10-25 02:36:11 -04:00
followmsi
af1c56580f defconfigs: flo: Regen defconfig: Enable connection tracking helper support
CONFIG_NF_CT_NETLINK_HELPER=y
CONFIG_NETFILTER_NETLINK_QUEUE_CT=y
CONFIG_NETFILTER_XT_TARGET_HMARK=y
CONFIG_NETFILTER_XT_MATCH_CONNLABEL=y
CONFIG_NF_NAT_IPV4=y
CONFIG_NF_NAT_IPV6=y

Change-Id: I731af9b5f316b0ce12e5c88cae9c21b4312017dc
2020-10-25 02:35:08 -04:00
Al Viro
2d7a35567b Safer ABI for O_TMPFILE
[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>
2018-12-07 22:28:48 +04:00
Al Viro
b390b8b86f [O_TMPFILE] it's still short a few helpers, but infrastructure should be OK now...
Change-Id: I6d19ad586df0185978a651a2e4ff126800e34570
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-12-07 22:28:48 +04:00
Jeff Layton
3df0a6646d vfs: define struct filename and have getname() return it
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>
2018-12-07 22:28:48 +04:00
Al Viro
2c1bd80538 new helper: done_path_create()
releases what needs to be released after {kern,user}_path_create()

Change-Id: If7fa7455e2ba8a6f4f4c4d2db502a38b4a60d7c7
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-12-07 22:28:48 +04:00
Arne Coucheron
9f01641774 defconfig: Enable connection tracking helper support
Change-Id: I02ec2743de16d3d25618b16636e66ce07edb4a98
2018-12-07 22:12:33 +04:00
Cong Wang
efd4c4ccf9 netfilter: remove xt_NOTRACK
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
2018-12-07 22:04:24 +04:00
Mitchel Humpherys
0423b88e29 msm: iommu: re-use existing buffers for `extra' mappings
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>
2018-08-27 14:52:30 +00:00
Artem Borisov
a4b9cf707b ARM: configs: flo: Go back to 100Hz
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
2018-03-23 18:43:28 +03:00
Artem Borisov
fa52784cac Revert "flo: defconfig: remove unused configs for Bluetooth"
This reverts commit 58045cdf8d.

Change-Id: I1f9bdaae551730b6d3dad31075095d9f2b940508
2018-03-23 18:43:27 +03:00
Artem Borisov
e2c600a1f3 sched_clock: Squashed revert of the latest updates
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
2018-02-20 21:56:17 +03:00
Lianwei Wang
3338634d04 IKHSS7-18791 msm:fix the list usage in msm_bus_dbg
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)
2018-02-16 20:15:06 -07:00
Siena Richard
aaab8b2495 ASoC: msm: qdsp6v2: extend validation of virtual address
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)
2018-02-16 20:15:05 -07:00
Wei Wang
3384f8b286 ANDROID: disable CONFIG_CC_OPTIMIZE_FOR_SIZE
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
2018-01-13 17:13:46 +03:00
Ecco Park
58045cdf8d flo: defconfig: remove unused configs for Bluetooth
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>
2018-01-13 17:13:40 +03:00
Patrick Tjin
029a1baa6f arm: configs: flo: set CONFIG_HZ to 300
Bug: 26444620

Change-Id: Idebc12682281e33e8f41e338482132cb881b9e85
Signed-off-by: Patrick Tjin <pattjin@google.com>
2018-01-02 22:36:47 +03:00
Artem Borisov
a63fd90f21 ARM: msm: flo: fix idle_timeout value to 100ms
Change-Id: Ia4dd5f9d8fef504e8c6a67668bca9857e7958f61
2018-01-02 22:36:47 +03:00
Stephen Boyd
ebb97da74a sched_clock: Make ARM's sched_clock generic for all architectures
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
2018-01-02 22:35:27 +03:00
Stephen Boyd
086da6a6c4 ARM: 7699/1: sched_clock: Add more notrace to prevent recursion
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>
2018-01-02 22:35:25 +03:00
Rob Herring
0dd4fad6c9 ARM: make sched_clock just call a function pointer
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>
2018-01-02 22:35:22 +03:00
Rob Herring
4a3cf85432 ARM: sched_clock: allow changing to higher frequency counter
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>
2018-01-02 22:35:18 +03:00
Artem Borisov
1b912a8c40 flo: defconfig: update for ZRAM and regen
Enable CONFIG_SWAP, CONFIG_ZSMALLOC, CONFIG_ZRAM, CONFIG_ZRAM_LZ4_COMPRESS.

Change-Id: I85c82680512d98c43ba90fcd55e117343ae89103
2018-01-01 22:16:23 +03:00
dcashman
4b659025f0 BACKPORT: FROMLIST: mm: ASLR: use get_random_long()
(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
2017-12-27 22:50:17 +03:00
dcashman
a4d7dd9c69 FROMLIST: x86: mm: support ARCH_MMAP_RND_BITS.
(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
2017-12-27 22:50:06 +03:00
Artem Borisov
d7992e6feb Merge remote-tracking branch 'stable/linux-3.4.y' into lineage-15.1
All bluetooth-related changes were omitted because of our ancient incompatible bt stack.

Change-Id: I96440b7be9342a9c1adc9476066272b827776e64
2017-12-27 17:13:15 +03:00
Artem Borisov
09cdfb2d97 flo: defconfig: enable CONFIG_INET_DIAG_DESTROY
Change-Id: Id6ad62ec7abcab618dfb06f3e60f07f0528a55b7
2017-12-15 22:54:59 +03:00
Artem Borisov
4315ddc3a6 flo: defconfig: use 64-bit binder API
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
2017-11-09 15:27:07 +00:00
Daniel Thompson
e52a7c847d BACKPORT: ARM: 8091/2: add get_user() support for 8 byte types
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>
2017-11-09 15:26:22 +00:00
Russell King
efcb02f166 BACKPORT: ARM: wire up getrandom syscall
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
2017-10-27 21:48:03 +03:00
Theodore Ts'o
86739403f2 BACKPORT: random: introduce getrandom(2) system call
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
2017-10-27 21:48:02 +03:00
Artem Borisov
800861e47a flo: defconfig: update PM configuration
Change-Id: I54ccad639b59f8fcd030ca255745147d4eaddc85
2017-10-15 17:05:14 +03:00
Iliyan Malchev
7e87a4dc87 PM: wakeup_reason: correctly deduce wakeup interrupts
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
2017-10-15 17:05:07 +03:00
Iliyan Malchev
4dbec3e7db irq_flow_handler_t now returns bool
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>
2017-10-15 17:05:07 +03:00
Artem Borisov
05767121c5 msm: smd_tty: fix build error after switching to upstream wakeup sources
Change-Id: If56ca52510b9298236bd0cf1ca20056af8afc0ea
2017-10-15 15:46:58 +03:00
Artem Borisov
1f98b31568 defconfig: enable sdcardfs
Change-Id: I9623d89dcfa77ddb32ce0246c53d8bfbaee30e9f
2017-09-22 19:13:13 +03:00
Eric W. Biederman
5c1997410b fs: Limit sys_mount to only request filesystem modules.
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>
2017-09-22 19:12:20 +03:00
Al Viro
be084ce9f1 move d_rcu from overlapping d_child to overlapping d_alias
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]
2017-09-22 19:11:55 +03:00
Artem Borisov
722370c1a0 flo: defconfig: don't disable NET_NS
Change-Id: I4082679c3f5d5d0f48f9a257232f06b066b86c5f
2017-09-14 21:07:54 +03:00
Adrian DC
a2b7343846 defconfig: flo: enable CONFIG_QUOTA
* Follows I7cb6b641f72085e69b90dca11d2ea68adcd02390

Change-Id: Ifbbadf90d91ac8e40dfbf17f7e1ed30c774939fc
2017-09-01 13:38:09 +03:00
Adrian DC
b37223073f defconfig: flo: Enable CONFIG_ANDROID_BINDER_IPC_32BIT
* 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
2017-08-27 19:06:59 +03:00
Kees Cook
159eb103ba mm: Tighten x86 /dev/mem with zeroing reads
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>
2017-07-04 12:34:19 +03:00