wlan: Store avoid channel list

Store avoid channel list into recoverable location.
If Softap mode detects current channel is not safe to use,
WLAN kernel module will be restarted.
Then WLAN kernel module internal storage will lost
unsafe channel information.
To avoid start softap with unsafe channel, channel information
should be stored in static location.

Change-Id: I5a6d7ab7314936d7bbaaf7a005e58179a4dc0613
CRs-fixed: 576020
Signed-off-by: Leo Chang <leochang@codeaurora.org>
Merge "Merge "msm: ipc: Possible memory corruption due to Sign Conversion""
Merge "Merge "Merge "msm: ipc: Possible memory corruption due to Sign Conversion"""
Merge "Merge "msm: ipc: Possible memory corruption due to Sign Conversion""
Merge "Merge "Merge "msm: ipc: Possible memory corruption due to Sign Conversion"""
Merge "Merge "Merge "msm: ipc: Possible memory corruption due to Sign Conversion"""
Merge "wlan: Store avoid channel list"
Merge "Merge "wlan: Store avoid channel list""
Merge "wlan: Store avoid channel list"
Merge "Merge "wlan: Store avoid channel list""
Merge AU_LINUX_ANDROID_KK_2.7_RB1.04.04.02.007.031 on remote branch

Change-Id: Ic2d4e85b233c7df5947c0f463d4045568168ed0d
Merge "Merge AU_LINUX_ANDROID_KK_2.7_RB1.04.04.02.007.031 on remote branch"
driver: mfd: Restore FIH changes

Change-Id: Ia697c2ef43361f7009be52a7f54b57e3737f282b
Merge commit 'AU_LINUX_ANDROID_KK_2.7_RB1.04.04.02.007.032' into cm-11.0
wlan: Prima Release 3.2.7.33

Change-Id: I2095cb5b23a03e0fd96dffb92f04d1ab0d013f08
ASoC:wcd9304:Modified code to acquire codec_resource_lock
 only once.

POP noise is heard as DAC is enabled during fast insertion/removal of
headset, due to wrong handling of codec_resource_lock. There is no need
to acquire the lock separately for HPHL and HPHR channel, hence modified
such that lock is acquired only once for both HPHL and HPHR PA's.

Change-Id: Ibceced072a9b19f0ecd0b156057973520f241a4f
CRs-Fixed: 580366
Signed-off-by: Asish Bhattacharya <asishb@codeaurora.org>
tcp: add a sysctl to config the tcp_default_init_rwnd

The default initial rwnd is hardcoded to 10.

Now we allow it to be controlled via
  /proc/sys/net/ipv4/tcp_default_init_rwnd
which limits the values from 3 to 100

This is somewhat needed because ipv6 routes are
autoconfigured by the kernel.

See "An Argument for Increasing TCP's Initial Congestion Window"
in https://developers.google.com/speed/articles/tcp_initcwnd_paper.pdf

Change-Id: I386b2a9d62de0ebe05c1ebe1b4bd91b314af5c54
Signed-off-by: JP Abgrall <jpa@google.com>
Enable setting security contexts on rootfs inodes.

rootfs (ramfs) can support setting of security contexts
by userspace due to the vfs fallback behavior of calling
the security module to set the in-core inode state
for security.* attributes when the filesystem does not
provide an xattr handler.  No xattr handler required
as the inodes are pinned in memory and have no backing
store.

This is useful in allowing early userspace to label individual
files within a rootfs while still providing a policy-defined
default via genfs.

Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Change-Id: I3436cf9ae27ade445e37376d7b9125746b1e506f
Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs

With this change, calling
  prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)
disables privilege granting operations at execve-time.  For example, a
process will not be able to execute a setuid binary to change their uid
or gid if this bit is set.  The same is true for file capabilities.

Additionally, LSM_UNSAFE_NO_NEW_PRIVS is defined to ensure that
LSMs respect the requested behavior.

To determine if the NO_NEW_PRIVS bit is set, a task may call
  prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0);
It returns 1 if set and 0 if it is not set. If any of the arguments are
non-zero, it will return -1 and set errno to -EINVAL.
(PR_SET_NO_NEW_PRIVS behaves similarly.)

This functionality is desired for the proposed seccomp filter patch
series.  By using PR_SET_NO_NEW_PRIVS, it allows a task to modify the
system call behavior for itself and its child tasks without being
able to impact the behavior of a more privileged task.

Another potential use is making certain privileged operations
unprivileged.  For example, chroot may be considered "safe" if it cannot
affect privileged tasks.

Note, this patch causes execve to fail when PR_SET_NO_NEW_PRIVS is
set and AppArmor is in use.  It is fixed in a subsequent patch.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Will Drewry <wad@chromium.org>
Acked-by: Eric Paris <eparis@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>

v18: updated change desc
v17: using new define values as per 3.4
Signed-off-by: James Morris <james.l.morris@oracle.com>
Fix execve behavior apparmor for PR_{GET,SET}_NO_NEW_PRIVS

Add support for AppArmor to explicitly fail requested domain transitions
if NO_NEW_PRIVS is set and the task is not unconfined.

Transitions from unconfined are still allowed because this always results
in a reduction of privileges.

Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Will Drewry <wad@chromium.org>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>

v18: new acked-by, new description
Signed-off-by: James Morris <james.l.morris@oracle.com>