Lineage 15.1#2
Open
christoks618 wants to merge 105 commits intozf2-laser-dev:lineage-15.0from
christoks618:lineage-15.1
Open
Lineage 15.1#2christoks618 wants to merge 105 commits intozf2-laser-dev:lineage-15.0from christoks618:lineage-15.1
christoks618 wants to merge 105 commits intozf2-laser-dev:lineage-15.0from
christoks618:lineage-15.1
Conversation
Check validity of command before processing. Change-Id: Icc5c57eac999b7c40fbb9505b2b88745167adc66 Signed-off-by: Trishansh Bhardwaj <tbhardwa@codeaurora.org>
Compress framework considers the stream as PLAYBACK always irrespective of the direction. The substream is updated based on the direction. Change-Id: I62c51c23a47f26b221dccef6f83c03aef9f095a7 Signed-off-by: Satish Babu Patakokila <sbpata@codeaurora.org>
The detection of direction for compress was only taking into account codec capabilities and not CPU ones. Fix this by checking the CPU side capabilities as well. Cc: <stable@vger.kernel.org> Tested-by: Ashish Panwar <ashish.panwar@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org> (cherry picked from commit a1068045883ed4a18363a4ebad0c3d55e473b716) Change-Id: I04a0c4e34a0e1120cc5c0f121df6127d103b22f4 Signed-off-by: Satish Babu Patakokila <sbpata@codeaurora.org> Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
Add support for compress capture in compress driver Change-Id: I7c6ab8bc0e88010eb221788cf8ce4c182e3128d9 Added TX app type support in compress driver. Change-Id: I8e84577b5aff5e932632c4612a88808615d764ae Add support for configuration of FE DAI app type for TX Session in platform routing driver Additional bug fixes related to mapping/unmapping calibration data CRs-Fixed: 2143246 Change-Id: I86c8236f9e123ed29e35cc50a9f2a2704adf0b67 Signed-off-by: pavanc <pavanc@codeaurora.org>
This reverts commit b956189. So as to avoid running into other issues. Change-Id: I6709b3cbcd49c837506eb2b00e6bdc8822ced16d Signed-off-by: Sai Krishna Juturi <jsaikrishna@codeaurora.org>
LSM needs to connect to ADM in cases where processing of captured data is required. App type config support is added to configure ADM in such cases. Change-Id: I2e429235e0486c958cacf18e5b704736791c2f7e Signed-off-by: Chaithanya Krishna Bacharaju <chaithan@codeaurora.org>
In rmnet_usb_ctrl_init dev is freed agian it is dereferenced with in same block. Fix this issue by taking derefernced value into a local variable prior to freeing dev Change-Id: Ic51accc8949e97c8aaeda558adcc9d404fb2a26d Signed-off-by: Sai Krishna Juturi <jsaikrishna@codeaurora.org>
We should call ipxitf_put() if the copy_to_user() fails. Change-Id: I365777e4a07923a2c96c5523d9046b9c9007f289 Reported-by: 李强 <liqiang6-s@360.cn> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> Git-commit: ee0d8d8482345ff97a75a7d747efc309f13b0d80 Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git Signed-off-by: Srinivasa Rao Kuppala <srkupp@codeaurora.org>
Andrey Konovalov reported out of bound accesses in ip6gre_err() If GRE flags contains GRE_KEY, the following expression *(((__be32 *)p) + (grehlen / 4) - 1) accesses data ~40 bytes after the expected point, since grehlen includes the size of IPv6 headers. Let's use a "struct gre_base_hdr *greh" pointer to make this code more readable. p[1] becomes greh->protocol. grhlen is the GRE header length. Change-Id: I5e0ff2b03734a0251e5b687fe2630bea84a1e163 Fixes: c12b395 ("gre: Support GRE over IPv6") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Git-commit: 7892032cfe67f4bde6fc2ee967e45a8fbaf33756 Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git Signed-off-by: Srinivasa Rao Kuppala <srkupp@codeaurora.org>
Create new function ext4_issue_zeroout() to zeroout contiguous (both logically and physically) part of inode data. We will need to issue zeroout when extent structure is not readily available and this function will allow us to do it without making up fake extent structures. Change-Id: I5deb04b49d3ebdd1ac12f8bb950faf46d08f5d80 Signed-off-by: Jan Kara <jack@suse.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Git-commit: 53085fac02d12fcd29a9cb074ec480ff0f77ae5c Git-repo: https://source.codeaurora.org/quic/la/kernel/msm-4.4 [srkupp@codeaurora.org: Resolved minor conflict] Signed-off-by: Srinivasa Rao Kuppala <srkupp@codeaurora.org>
In the case that compat_get_bitmap fails we do not want to copy the bitmap to the user as it will contain uninitialized stack data and leak sensitive data. Change-Id: I4f66a1c3ef7e616d06d3301b145973ed8cd9e449 Signed-off-by: Chris Salls <salls@cs.ucsb.edu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Git-commit: cf01fb9985e8deb25ccf0ea54d916b8871ae0e62 Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Signed-off-by: Arun KS <arunks@codeaurora.org>
sg_ioctl could be spammed by requests, leading to a double free in __free_pages. This protects the entry points of sg_ioctl where the memory could be corrupted by a double call to __free_pages if multiple requests are happening concurrently. Bug:35644812 Change-Id: Ie13f65beb6974430f90292e2742841b26aecb8b1 Signed-off-by: Robb Glasser <rglasser@google.com> Git-commit: 22d8e80738b5ce8784d59b48b0b051a520da4bec Git-repo: https://source.codeaurora.org/quic/la/kernel/msm-3.10/commit Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
Huang has reported that in his powerfail testing he is seeing stale block contents in some of recently allocated blocks although he mounts ext4 in data=ordered mode. After some investigation I have found out that indeed when delayed allocation is used, we don't add inode to transaction's list of inodes needing flushing before commit. Originally we were doing that but commit f3b5929 removed the logic with a flawed argument that it is not needed. The problem is that although for delayed allocated blocks we write their contents immediately after allocating them, there is no guarantee that the IO scheduler or device doesn't reorder things and thus transaction allocating blocks and attaching them to inode can reach stable storage before actual block contents. Actually whenever we attach freshly allocated blocks to inode using a written extent, we should add inode to transaction's ordered inode list to make sure we properly wait for block contents to be written before committing the transaction. So that is what we do in this patch. This also handles other cases where stale data exposure was possible - like filling hole via mmap in data=ordered,nodelalloc mode. The only exception to the above rule are extending direct IO writes where blkdev_direct_IO() waits for IO to complete before increasing i_size and thus stale data exposure is not possible. For now we don't complicate the code with optimizing this special case since the overhead is pretty low. In case this is observed to be a performance problem we can always handle it using a special flag to ext4_map_blocks(). Change-Id: Idc78b64e4f23e6085301c60057af6029b49a8193 Git-commit: 1200efcca9b5174bc8de5ac8440f49fab3bcd0f8 Git-repo: https://source.codeaurora.org/quic/la/kernel/msm-4.4 CC: stable@vger.kernel.org Fixes: f3b5929 Reported-by: "HUANG Weller (CM/ESW12-CN)" <Weller.Huang@cn.bosch.com> Tested-by: "HUANG Weller (CM/ESW12-CN)" <Weller.Huang@cn.bosch.com> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Connor O'Brien <connoro@google.com> Bug: 62198330 Signed-off-by: Srinivasa Rao Kuppala <srkupp@codeaurora.org>
Add null terminator at the end of string extend_ioctl_data.u.rmnet_mux_val.vchannel_name to avoid potential security issue. Change-Id: I57fe3a9f7e3ad6a499b62a9cfc49bc6b2f3b42e0 Acked-by: Shihuan Liu <shihuanl@qti.qualcomm.com> Signed-off-by: Skylar Chang <chiaweic@codeaurora.org>
Update rounting table to support compress record usecase for external codec CRs-Fixed: 2143246 Change-Id: I797aad2eed4e9b1a3cf9523e061d408385210174 Signed-off-by: Divya Narayanan Poojary <dnaray@codeaurora.org>
Pointer after kfree is not sanitized. Set pointer to NULL. CRs-Fixed: 2008031 Change-Id: I4366619e922202630c8307e21ee9a82a009e9ca9 Signed-off-by: Xiaojun Sang <xsang@codeaurora.org> Signed-off-by: smanag <smanag@codeaurora.org>
Drivers can implement 'struct snd_pcm_ops.ioctl' to handle some requests from ALSA PCM core. These requests are internal purpose in kernel land. Usually common set of operations are used for it. SNDRV_PCM_IOCTL1_INFO is one of the requests. According to code comment, it has been obsoleted in the old days. We can see old releases in ftp.alsa-project.org. The command was firstly introduced in v0.5.0 release as SND_PCM_IOCTL1_INFO, to allow drivers to fill data of 'struct snd_pcm_channel_info' type. In v0.9.0 release, this was obsoleted by the other commands for ioctl(2) such as SNDRV_PCM_IOCTL_CHANNEL_INFO. This commit removes the long-abandoned command, bye. CRs-fixed: 2112663 Change-Id: I17d9c0a759fce81d3dc9b9375f5d5f35dac583b8 Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de> Git-commit: e11f0f90a626f93899687b1cc909ee37dd6c5809 Git-repo: git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Signed-off-by: Karthikeyan Mani <kmani@codeaurora.org>
Remove unused 'runtime' variable from function snd_pcm_info().
The last usage of this variable was removed with the
'commit e11f0f90a626f9 ("ALSA: pcm: remove SNDRV_PCM_IOCTL1_INFO
internal command")'.
Change-Id: I3964d84f7cced811d15ff45a1c31cc28d20dc721
Signed-off-by: Banajit Goswami <bgoswami@codeaurora.org>
Move the context manager state into a separate struct context, and allow for each process to have its own context associated with it. Change-Id: Ifa934370241a2d447dd519eac3fd0682c6d00ab4 Signed-off-by: Martijn Coenen <maco@google.com>
Properly print the context in debugfs entries. Change-Id: If10c2129536d9f39bae542afd7318ca79af60e3a Signed-off-by: Martijn Coenen <maco@google.com>
Add a new module parameter 'devices', that can be used to specify the names of the binder device nodes we want to populate in /dev. Each device node has its own context manager, and is therefore logically separated from all the other device nodes. The config option CONFIG_ANDROID_BINDER_DEVICES can be used to set the default value of the parameter. This approach was favored over using IPC namespaces, mostly because we require a single process to be a part of multiple binder contexts, which seemed harder to achieve with namespaces. Change-Id: I3df72b2a19b5ad5a0360e6322482db7b00a12b24 Signed-off-by: Martijn Coenen <maco@google.com>
flat_binder_object is used for both handling binder objects and file descriptors, even though the two are mostly independent. Since we'll have more fixup objects in binder in the future, instead of extending flat_binder_object again, split out file descriptors to their own object while retaining backwards compatibility to existing user-space clients. All binder objects just share a header. Change-Id: Ifffa8cb749335d0ee79226c98f70786190516355 Signed-off-by: Martijn Coenen <maco@google.com>
Moved handling of fixup for binder objects, handles and file descriptors into separate functions. Change-Id: If6849f1caee3834aa87d0ab08950bb1e21ec6e38 Signed-off-by: Martijn Coenen <maco@google.com>
The binder_buffer allocator currently only allocates space for the data and offsets buffers of a Parcel. This change allows for requesting an additional chunk of data in the buffer, which can for example be used to hold additional meta-data about the transaction (eg a security context). Change-Id: I58ab9c383a2e1a3057aae6adaa596ce867f1b157 Signed-off-by: Martijn Coenen <maco@google.com>
Previously all data passed over binder needed to be serialized, with the exception of Binder objects and file descriptors. This patchs adds support for scatter-gathering raw memory buffers into a binder transaction, avoiding the need to first serialize them into a Parcel. To remain backwards compatibile with existing binder clients, it introduces two new command ioctls for this purpose - BC_TRANSACTION_SG and BC_REPLY_SG. These commands may only be used with the new binder_transaction_data_sg structure, which adds a field for the total size of the buffers we are scatter-gathering. Because memory buffers may contain pointers to other buffers, we allow callers to specify a parent buffer and an offset into it, to indicate this is a location pointing to the buffer that we are fixing up. The kernel will then take care of fixing up the pointer to that buffer as well. Change-Id: Ibe17f4f5629d1d541a03f1e826cfd153b64f0d8c Signed-off-by: Martijn Coenen <maco@google.com>
This patch introduces a new binder_fd_array object, that allows us to support one or more file descriptors embedded in a buffer that is scatter-gathered. Change-Id: I647a53cf0d905c7be0dfd9333806982def68dd74 Signed-off-by: Martijn Coenen <maco@google.com>
To keep the driver consistent, and until we have fine-grained locking in place. Change-Id: Id780c8391a5a2a0cfa4963c6a06efec8e32dcac6 Signed-off-by: Martijn Coenen <maco@android.com>
The binder allocator assumes that the thread that called binder_open will never die for the lifetime of that proc. That thread is normally the group_leader, however it may not be. Use the group_leader instead of current. Bug: 35707103 Test: Created test case to open with temporary thread Change-Id: Id693f74b3591f3524a8c6e9508e70f3e5a80c588 Signed-off-by: Todd Kjos <tkjos@google.com>
These will be required going forward. Change-Id: I8f24e1e9f87a6773bd84fb9f173a3725c376c692 Signed-off-by: Martijn Coenen <maco@google.com>
(cherry pick from 572b57fc6f7fb6ffaa979d505ec2b0a9e9840cca) Use wake_up_interruptible_sync() to hint to the scheduler binder transactions are synchronous wakeups. Disable preemption while waking to avoid ping-ponging on the binder lock. Signed-off-by: Riley Andrews <riandrews@google.com> Bug: 30141999 Change-Id: If570d94ef3fed09c328052922d5a9e83d7ba479a
…ock. Change-Id: I90fe02cdedb8a5677b900a68528fb443b9204322 Signed-off-by: Riley Andrews <riandrews@google.com>
Credit where credit is due: this idea comes from Christoph Lameter with a lot of valuable input from Serge Hallyn. This patch is heavily based on Christoph's patch. ===== The status quo ===== On Linux, there are a number of capabilities defined by the kernel. To perform various privileged tasks, processes can wield capabilities that they hold. Each task has four capability masks: effective (pE), permitted (pP), inheritable (pI), and a bounding set (X). When the kernel checks for a capability, it checks pE. The other capability masks serve to modify what capabilities can be in pE. Any task can remove capabilities from pE, pP, or pI at any time. If a task has a capability in pP, it can add that capability to pE and/or pI. If a task has CAP_SETPCAP, then it can add any capability to pI, and it can remove capabilities from X. Tasks are not the only things that can have capabilities; files can also have capabilities. A file can have no capabilty information at all [1]. If a file has capability information, then it has a permitted mask (fP) and an inheritable mask (fI) as well as a single effective bit (fE) [2]. File capabilities modify the capabilities of tasks that execve(2) them. A task that successfully calls execve has its capabilities modified for the file ultimately being excecuted (i.e. the binary itself if that binary is ELF or for the interpreter if the binary is a script.) [3] In the capability evolution rules, for each mask Z, pZ represents the old value and pZ' represents the new value. The rules are: pP' = (X & fP) | (pI & fI) pI' = pI pE' = (fE ? pP' : 0) X is unchanged For setuid binaries, fP, fI, and fE are modified by a moderately complicated set of rules that emulate POSIX behavior. Similarly, if euid == 0 or ruid == 0, then fP, fI, and fE are modified differently (primary, fP and fI usually end up being the full set). For nonroot users executing binaries with neither setuid nor file caps, fI and fP are empty and fE is false. As an extra complication, if you execute a process as nonroot and fE is set, then the "secure exec" rules are in effect: AT_SECURE gets set, LD_PRELOAD doesn't work, etc. This is rather messy. We've learned that making any changes is dangerous, though: if a new kernel version allows an unprivileged program to change its security state in a way that persists cross execution of a setuid program or a program with file caps, this persistent state is surprisingly likely to allow setuid or file-capped programs to be exploited for privilege escalation. ===== The problem ===== Capability inheritance is basically useless. If you aren't root and you execute an ordinary binary, fI is zero, so your capabilities have no effect whatsoever on pP'. This means that you can't usefully execute a helper process or a shell command with elevated capabilities if you aren't root. On current kernels, you can sort of work around this by setting fI to the full set for most or all non-setuid executable files. This causes pP' = pI for nonroot, and inheritance works. No one does this because it's a PITA and it isn't even supported on most filesystems. If you try this, you'll discover that every nonroot program ends up with secure exec rules, breaking many things. This is a problem that has bitten many people who have tried to use capabilities for anything useful. ===== The proposed change ===== This patch adds a fifth capability mask called the ambient mask (pA). pA does what most people expect pI to do. pA obeys the invariant that no bit can ever be set in pA if it is not set in both pP and pI. Dropping a bit from pP or pI drops that bit from pA. This ensures that existing programs that try to drop capabilities still do so, with a complication. Because capability inheritance is so broken, setting KEEPCAPS, using setresuid to switch to nonroot uids, and then calling execve effectively drops capabilities. Therefore, setresuid from root to nonroot conditionally clears pA unless SECBIT_NO_SETUID_FIXUP is set. Processes that don't like this can re-add bits to pA afterwards. The capability evolution rules are changed: pA' = (file caps or setuid or setgid ? 0 : pA) pP' = (X & fP) | (pI & fI) | pA' pI' = pI pE' = (fE ? pP' : pA') X is unchanged If you are nonroot but you have a capability, you can add it to pA. If you do so, your children get that capability in pA, pP, and pE. For example, you can set pA = CAP_NET_BIND_SERVICE, and your children can automatically bind low-numbered ports. Hallelujah! Unprivileged users can create user namespaces, map themselves to a nonzero uid, and create both privileged (relative to their namespace) and unprivileged process trees. This is currently more or less impossible. Hallelujah! You cannot use pA to try to subvert a setuid, setgid, or file-capped program: if you execute any such program, pA gets cleared and the resulting evolution rules are unchanged by this patch. Users with nonzero pA are unlikely to unintentionally leak that capability. If they run programs that try to drop privileges, dropping privileges will still work. It's worth noting that the degree of paranoia in this patch could possibly be reduced without causing serious problems. Specifically, if we allowed pA to persist across executing non-pA-aware setuid binaries and across setresuid, then, naively, the only capabilities that could leak as a result would be the capabilities in pA, and any attacker *already* has those capabilities. This would make me nervous, though -- setuid binaries that tried to privilege-separate might fail to do so, and putting CAP_DAC_READ_SEARCH or CAP_DAC_OVERRIDE into pA could have unexpected side effects. (Whether these unexpected side effects would be exploitable is an open question.) I've therefore taken the more paranoid route. We can revisit this later. An alternative would be to require PR_SET_NO_NEW_PRIVS before setting ambient capabilities. I think that this would be annoying and would make granting otherwise unprivileged users minor ambient capabilities (CAP_NET_BIND_SERVICE or CAP_NET_RAW for example) much less useful than it is with this patch. ===== Footnotes ===== [1] Files that are missing the "security.capability" xattr or that have unrecognized values for that xattr end up with has_cap set to false. The code that does that appears to be complicated for no good reason. [2] The libcap capability mask parsers and formatters are dangerously misleading and the documentation is flat-out wrong. fE is *not* a mask; it's a single bit. This has probably confused every single person who has tried to use file capabilities. [3] Linux very confusingly processes both the script and the interpreter if applicable, for reasons that elude me. The results from thinking about a script's file capabilities and/or setuid bits are mostly discarded. Preliminary userspace code is here, but it needs updating: https://git.kernel.org/cgit/linux/kernel/git/luto/util-linux-playground.git/commit/?h=cap_ambient&id=7f5afbd175d2 Here is a test program that can be used to verify the functionality (from Christoph): /* * Test program for the ambient capabilities. This program spawns a shell * that allows running processes with a defined set of capabilities. * * (C) 2015 Christoph Lameter <cl@linux.com> * Released under: GPL v3 or later. * * * Compile using: * * gcc -o ambient_test ambient_test.o -lcap-ng * * This program must have the following capabilities to run properly: * Permissions for CAP_NET_RAW, CAP_NET_ADMIN, CAP_SYS_NICE * * A command to equip the binary with the right caps is: * * setcap cap_net_raw,cap_net_admin,cap_sys_nice+p ambient_test * * * To get a shell with additional caps that can be inherited by other processes: * * ./ambient_test /bin/bash * * * Verifying that it works: * * From the bash spawed by ambient_test run * * cat /proc/$$/status * * and have a look at the capabilities. */ /* * Definitions from the kernel header files. These are going to be removed * when the /usr/include files have these defined. */ static void set_ambient_cap(int cap) { int rc; capng_get_caps_process(); rc = capng_update(CAPNG_ADD, CAPNG_INHERITABLE, cap); if (rc) { printf("Cannot add inheritable cap\n"); exit(2); } capng_apply(CAPNG_SELECT_CAPS); /* Note the two 0s at the end. Kernel checks for these */ if (prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, cap, 0, 0)) { perror("Cannot set cap"); exit(1); } } int main(int argc, char **argv) { int rc; set_ambient_cap(CAP_NET_RAW); set_ambient_cap(CAP_NET_ADMIN); set_ambient_cap(CAP_SYS_NICE); printf("Ambient_test forking shell\n"); if (execv(argv[1], argv + 1)) perror("Cannot exec"); return 0; } Signed-off-by: Christoph Lameter <cl@linux.com> # Original author Signed-off-by: Andy Lutomirski <luto@kernel.org> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com> Acked-by: Kees Cook <keescook@chromium.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Aaron Jones <aaronmdjones@gmail.com> Cc: Ted Ts'o <tytso@mit.edu> Cc: Andrew G. Morgan <morgan@kernel.org> Cc: Mimi Zohar <zohar@linux.vnet.ibm.com> Cc: Austin S Hemmelgarn <ahferroin7@gmail.com> Cc: Markku Savela <msa@moth.iki.fi> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: James Morris <james.l.morris@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 58319057b7847667f0c9585b9de0e8932b0fdb08) Bug: 31038224 Test: Builds. Change-Id: I55fbe6e6d3fbb48edbea15bedd81d90ed50fd575 Signed-off-by: Jorge Lucangeli Obes <jorgelo@google.com>
…task_prctl In function cap_task_prctl(), we would allocate a credential unconditionally and then check if we support the requested function. If not we would release this credential with abort_creds() by using RCU method. But on some archs such as powerpc, the sys_prctl is heavily used to get/set the floating point exception mode. So the unnecessary allocating/releasing of credential not only introduce runtime overhead but also do cause OOM due to the RCU implementation. This patch removes abort_creds() from cap_task_prctl() by calling prepare_creds() only when we need to modify it. Reported-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reviewed-by: Paul Moore <paul@paul-moore.com> Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com> (cherry picked from commit 6d6f3328422a3bc56b0d8dd026a5de845d2abfa7) Bug: 35074030 Test: Builds. Change-Id: Ic7b0d01f4c23328b134084a5585599883aed6345 Signed-off-by: Jorge Lucangeli Obes <jorgelo@google.com>
Correcting syscall numbers for seccomp Signed-off-by: Lee Campbell <leecam@chromium.org> Git-commit: 900e9fd0d5d15c596cacfb89ce007c933cea6e1c Git-repo: https://android.googlesource.com/kernel/common.git [imaund@codeaurora.org: Resolved context conflicts] Signed-off-by: Ian Maund <imaund@codeaurora.org>
Clean cherry pick of commmit 6d31920246a9fc80be4f16acd27c0bbe8d7b8494. The current Tausworthe PRNG is never reseeded with truly random data after the first attempt in late_initcall. As this PRNG is used for some critical random data as e.g. UDP port randomization we should try better and reseed the PRNG once in a while with truly random data from get_random_bytes(). When we reseed with prandom_seed we now make also sure to throw the first output away. This suffices the reseeding procedure. The delay calculation is based on a proposal from Eric Dumazet. Joint work with Daniel Borkmann. Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Bug: http://b/29621447 Change-Id: I990d00f4a29a56a22357cec1c17477c4721054ae (cherry picked from commit 6d31920246a9fc80be4f16acd27c0bbe8d7b8494)
…ng pool becomes initialized Clean cherry pick of commit 4af712e8df998475736f3e2727701bd31e3751a9. The Tausworthe PRNG is initialized at late_initcall time. At that time the entropy pool serving get_random_bytes is not filled sufficiently. This patch adds an additional reseeding step as soon as the nonblocking pool gets marked as initialized. On some machines it might be possible that late_initcall gets called after the pool has been initialized. In this situation we won't reseed again. (A call to prandom_seed_late blocks later invocations of early reseed attempts.) Joint work with Daniel Borkmann. Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Acked-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: David S. Miller <davem@davemloft.net> Bug: http://b/29621447 Change-Id: I4d20e60b5df16228f3a3699d16ed2b1dddcceb2b (cherry picked from commit 4af712e8df998475736f3e2727701bd31e3751a9)
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 <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 4af712e8df998475736f3e2727701bd31e3751a9)
Clean cherry pick of 1d9de44e268d880cbe2d0bd3be1ef0661f93fd34. If more than one application invokes getrandom(2) before the pool is ready, then all bar one will be stuck forever because we use wake_up_interruptible which wakes up a single task. This patch replaces it with wake_up_all. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Bug: http://b/29621447 Change-Id: I5dfd7abac10898802f030e0a2af7110809283328 (cherry picked from commit 1d9de44e268d880cbe2d0bd3be1ef0661f93fd34)
Clean cherry pick of eb6452537b280652eee66801ec97cc369e27e5d8. 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 eb6452537b280652eee66801ec97cc369e27e5d8)
upstream commit 6f29997f4a3117169eeabd41dbea4c1bd94a739c Add support for per-file labeling of debugfs files so that we can distinguish them in policy. This is particularly important in Android where certain debugfs files have to be writable by apps and therefore the debugfs directory tree can be read and searched by all. Since debugfs is entirely kernel-generated, the directory tree is immutable by userspace, and the inodes are pinned in memory, we can simply use the same approach as with proc and label the inodes from policy based on pathname from the root of the debugfs filesystem. Generalize the existing labeling support used for proc and reuse it for debugfs too. [sds: Back-ported to 3.10. superblock_security_struct flags field is only unsigned char in 3.10 so we have to redefine SE_SBGENFS. However, this definition is kernel-private, not exposed to userspace or stored anywhere persistent.] Change-Id: I6460fbed6bb6bd36eb8554ac8c4fdd574edf3b07 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Support per-file labeling of sysfs and pstore files based on genfscon policy entries. This is safe because the sysfs and pstore directory tree cannot be manipulated by userspace, except to unlink pstore entries. This provides an alternative method of assigning per-file labeling to sysfs or pstore files without needing to set the labels from userspace on each boot. The advantages of this approach are that the labels are assigned as soon as the dentry is first instantiated and userspace does not need to walk the sysfs or pstore tree and set the labels on each boot. The limitations of this approach are that the labels can only be assigned based on pathname prefix matching. You can initially assign labels using this mechanism and then change them at runtime via setxattr if allowed to do so by policy. Change-Id: If5999785fdc1d24d869b23ae35cd302311e94562 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Suggested-by: Dominick Grift <dac.override@gmail.com>
Fix double free on error paths
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: I1c25a175e87e5dd5cafcdcf9d78bf4c0dc3f88ef
Bug: 65386954
Fixes: aa6d3ace42f9 ("mnt: Add filesystem private data to mount points")
This moves the code to adjust the gid/uid of lower filesystem files under the mount flag derive_gid. Signed-off-by: Daniel Rosenberg <drosen@google.com> Change-Id: I44eaad4ef67c7fcfda3b6ea3502afab94442610c Bug: 63245673
Signed-off-by: Daniel Rosenberg <drosen@google.com> Bug: 63245673 Change-Id: I5fc596420301045895e5a9a7e297fd05434babf9
* Required for early mount support.
Add support to early mount system partition so that system modules can be loaded during early init. Change-Id: Ib9a3e5dca8923a900f76b276ed05b34f45a84063 Signed-off-by: Swetha Chikkaboraiah <schikk@codeaurora.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
19 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.