xavi/android_kernel_m2note/arch, branch ng-7.1.2

defconfig: remove useless usb storage stuff

2019-08-01T16:12:03+00:00

defconfig: remove unused comp algos

2019-08-01T16:11:39+00:00

crypto: arm - replace memset by memzero_explicit

2019-07-08T11:36:44+00:00

Memset on a local variable may be removed when it is called just before the variable goes out of scope. Using memzero_explicit defeats this optimization. A simplified version of the semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // @@ identifier x; type T; @@ { ... when any T x[...]; ... when any when exists - memset + memzero_explicit (x, -0, ...) ... when != x when strict } // This change was suggested by Daniel Borkmann Signed-off-by: Julia Lawall Acked-by: Ard Biesheuvel Signed-off-by: Herbert Xu Change-Id: I89b5957f922b7e5568a405c212eb186449f1deab (cherry picked from commit 025f4cbff16e284192b04bfa1f7b19551c1f5af3)

crypto: arm/sha256 - Use memzero_explicit to fill memory with 0

2019-07-08T11:36:43+00:00

memzero_explicit should be used instead in order to prevent the compiler from optimising away zeroing. Change-Id: I248925e4c3e934a98f1341b6649ca7cb200a7781 (cherry picked from commit af92d4cf4b0a9ffc39fbd242c2659267ea62fb97)

partial merge fix - BACKPORT: random: introduce getrandom(2) system call

2019-07-07T20:32:50+00:00

Almost clean cherry pick of c6e9d6f38894798696f23c8084ca7edbf16ee895, includes change made by merge 0891ad829d2a0501053703df66029e843e3b8365. 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 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 Reviewed-by: Zach Brown Bug: http://b/29621447 Change-Id: I189ba74070dd6d918b0fdf83ff30bb74ec0f7556 (cherry picked from commit 4af712e8df998475736f3e2727701bd31e3751a9)

Fix "BACKPORT: ARM: wire up getrandom syscall"

2019-07-07T20:32:50+00:00

* Syscalls need to be greater than __NR_last_syscall+1 in order to account for the padding in the syscall table Change-Id: Ide15e25e8a2287fff29c75d898c935318b660ea2

BACKPORT: ARM: wire up getrandom syscall Clean cherry pick of eb6452537b280652eee66801ec97cc369e27e5d8.

2019-07-07T20:32:50+00:00

Add the new getrandom syscall for ARM. Signed-off-by: Russell King Bug: http://b/29621447 Change-Id: I6d50b57f3a61fbf9102c69103b9a5b7ebf239860 (cherry picked from commit eb6452537b280652eee66801ec97cc369e27e5d8)

Enlarge ram console size from 12KB to 15KB.

2019-05-03T16:44:20+00:00

BUG:67857304 Change-Id: I7bb176458bd6b8d62218dea3e5e9a9d815afc5ee Signed-off-by: Piazza Lo Signed-off-by: Moyster

ARM: 7933/1: rename ioremap_cached to ioremap_cache

2019-05-03T16:34:20+00:00

ioremap_cache is more aligned with other architectures. There are only 2 users of this in the kernel: pxa2xx-flash and Xen. This fixes Xen build failures on arm64: drivers/tty/hvc/hvc_xen.c:233:2: error: implicit declaration of function 'ioremap_cached' [-Werror=implicit-function-declaration] drivers/xen/grant-table.c:1174:3: error: implicit declaration of function 'ioremap_cached' [-Werror=implicit-function-declaration] drivers/xen/xenbus/xenbus_probe.c:778:4: error: implicit declaration of function 'ioremap_cached' [-Werror=implicit-function-declaration] Signed-off-by: Rob Herring Signed-off-by: Stefano Stabellini Signed-off-by: Russell King Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Git-commit: 0a5ccc86507f45b80831dac1049197c4d45be955 [joonwoop@codeaurora.org: fixed trivial merge conflict.] Signed-off-by: Joonwoo Park Change-Id: I867b893aa63bc8647ed0d7cbf66b7fbb464ef8f0

arm64/xen: implement ioremap_cached on arm64

2019-05-03T16:34:14+00:00

Change-Id: I567349ba54959b45e817e8ebacbb8babca1ca453 Signed-off-by: Stefano Stabellini Git-Repo: git://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ Git-commit: 22d4102f778df9cab47e871b8de3400f6e685378 Signed-off-by: Abhimanyu Kapur