add sysfs for vibration intensity control

Allows incredible ~3% increase in vibration intensity. :P
Going down to about a third of the original intensity
seems to be enough to disable the vibrator.

Based on codeworkx's commit somewhere.

Change-Id: Ie4f96362d774f596c7c013cfe38cf0d2c9502cc6
ashmem: avoid deadlock between read and mmap calls

Avoid holding ashmem_mutex across code that can page fault.  Page faults
grab the mmap_sem for the process, which are also held by mmap calls
prior to calling ashmem_mmap, which locks ashmem_mutex.  The reversed
order of locking between the two can deadlock.

The calls that can page fault are read() and the ASHMEM_SET_NAME and
ASHMEM_GET_NAME ioctls.  Move the code that accesses userspace pages
outside the ashmem_mutex.

Bug: 9261835
Change-Id: If1322e981d29c889a56cdc9dfcbc6df2729a45e9
Signed-off-by: Todd Poynor <toddpoynor@google.com>
msm: kgsl: Detect and avoid malformed ioctl codes

Because we were using _IO_NR, one could construct a malformed ioctl
code that would avoid allocating memory yet go to a function that
expected that memory. Still use _IO_NR to index the array of ioctls,
but check that the full values match before jumping to the helper
function.

CRs-fixed: 385592
Change-Id: Ic0dedbaded469035bd0a2bb0f20fecb2a3045ca5
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>

CVE-2012-4222:
Several integer overflows in the processing of DIAG ioctl system call
parameters allow a locally installed application to conduct denial of
service (DoS) attacks or possibly execute arbitrary code in kernel
context.
https://www.codeaurora.org/projects/security-advisories/multiple-issues-diagkgsl-system-call-handling-cve-2012-4220-cve-2012
msm: msm_fb: remove mmio access through mmap

Disable access to mm io and add
appropriate range checks to ensure valid accesses
through framebuffer mmap. This prevents illegal
access into memory.

CRs-Fixed: 474706
Change-Id: If25166f2732433ef967e99c716440030b567aae9
Signed-off-by: Manoj Rao <manojraj@codeaurora.org>

Integer overflow in range check when mapping framebuffer memory (CVE-2013-2596).
https://www.codeaurora.org/projects/security-advisories/integer-overflow-range-check-when-mapping-framebuffer-memory-cve-2013-2596
add extra free kbytes tunable

Add a userspace visible knob to tell the VM to keep an extra amount
of memory free, by increasing the gap between each zone's min and
low watermarks.

This is useful for realtime applications that call system
calls and have a bound on the number of allocations that happen
in any short time period.  In this application, extra_free_kbytes
would be left at an amount equal to or larger than than the
maximum number of allocations that happen in any burst.

It may also be useful to reduce the memory use of virtual
machines (temporarily?), in a way that does not cause memory
fragmentation like ballooning does.

[ccross]
Revived for use on old kernels where no other solution exists.
The tunable will be removed on kernels that do better at avoiding
direct reclaim.

Change-Id: I765a42be8e964bfd3e2886d1ca85a29d60c3bb3e
Signed-off-by: Rik van Riel<riel@redhat.com>
Signed-off-by: Colin Cross <ccross@android.com>
Backport: PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs

Original message:

Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs

With this set, a lot of dangerous operations (chroot, unshare, etc)
become a lot less dangerous because there is no possibility of
subverting privileged binaries.

This patch completely breaks apparmor.  Someone who understands (and
uses) apparmor should fix it or at least give me a hint.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>

Change-Id: I370e8cc0fd6046c0b733c35447698e4e4531454f