Replaces the seccomp_t typedef with struct seccomp to match modern
kernel style.
Signed-off-by: Will Drewry <wad@chromium.org>
Reviewed-by: James Morris <jmorris@namei.org>
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Acked-by: Eric Paris <eparis@redhat.com>
v18: rebase
...
v14: rebase/nochanges
v13: rebase on to 88ebdda615
v12: rebase on to linux-next
v8-v11: no changes
v7: struct seccomp_struct -> struct seccomp
v6: original inclusion in this series.
Any other users of bpf_*_filter that take a struct sock_fprog from
userspace will need to be able to also accept a compat_sock_fprog
if the arch supports compat calls. This change allows the existing
compat_sock_fprog be shared.
Signed-off-by: Will Drewry <wad@chromium.org>
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Eric Paris <eparis@redhat.com>
v18: tasered by the apostrophe police
v14: rebase/nochanges
v13: rebase on to 88ebdda615
v12: rebase on to linux-next
v11: introduction
Introduces a new BPF ancillary instruction that all LD calls will be
mapped through when skb_run_filter() is being used for seccomp BPF. The
rewriting will be done using a secondary chk_filter function that is run
after skb_chk_filter.
The code change is guarded by CONFIG_SECCOMP_FILTER which is added,
along with the seccomp_bpf_load() function later in this series.
This is based on http://lkml.org/lkml/2012/3/2/141
Suggested-by: Indan Zupancic <indan@nul.nu>
Signed-off-by: Will Drewry <wad@chromium.org>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Eric Paris <eparis@redhat.com>
v18: rebase
...
v15: include seccomp.h explicitly for when seccomp_bpf_load exists.
v14: First cut using a single additional instruction
... v13: made bpf functions generic.
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
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>
v18: updated change desc
v17: using new define values as per 3.4
Conflicts:
include/linux/prctl.h
kernel/sys.c
bug: 17968808 Kernel change for new eMMC v5.0 parts for FLO/DEB
Change-Id: Ia18152457fe3ff70401b199c267fa37374b9d544
Signed-off-by: hsuan-chih_chen <hsuan-chih_chen@asus.com>
The __GFP_CMA mask is now placed after all available GFP masks.
With this we need to increase the total number of GFP flags.
Do so accordingly.
Bug: 17494249
CRs-Fixed: 648978
Change-Id: I53f5f064ac16a50ee10c84ff2bb50fdb7e085bd0
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Naveen Ramaraj <nramaraj@codeaurora.org>
Currenlty most memory reclaim is done through kswapd.
Since kswapd uses a gfp mask of GFP_KERNEL, and because
the lowmemorykiller is zone aware, the lowmemorykiller will
ignore highmem most of the time.
This results in the lowmemorykiller being overly aggressive.
The fix to this issue is to allow the lowmemorykiller to
count highmem when being called by the kswapd if the lowmem
watermarks are satisfied.
Bug: 17494249
Change-Id: I938644584f374763d10d429d835e74daa4854a38
Signed-off-by: Liam Mark <lmark@codeaurora.org>
Signed-off-by: Naveen Ramaraj <nramaraj@codeaurora.org>
Add a flag in /sys/kernel/debug/kgsl/kgsl-3do/proc/<pid>/mem
file to indicate for each GPU buffer if it is mapped to userspace
in <pid> or not.
CRs-fixed: 634962
Change-Id: I8abda74ef5656aca6b1c0315af8deb77460fa5a9
Signed-off-by: Harsh Vardhan Dwivedi <hdwivedi@codeaurora.org>
Add VM_DONTCOPY to the default set of mmap flags to keep VM objects
from being copied on fork() and causing issues. KGSL file descriptors
copied to a child are not expected to be usable.
Change-Id: Ic0dedbad85c07118a931ccb9f7a6fd0507da3e5a
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
VM_IO prevents mapped memory from being peeked by ptrace(). That
kind of protection isn't really needed for nominal GPU buffers.
A process given itself up to ptrace() already expects to be
examined so there is no additional risk to let the parent examine
GPU buffers too. This is done universally now, but there is no
reason why we wouldn't let the process choose which buffers to
keep private in the future.
That said; there is more of a concern about including GPU buffers
in a core dump since that is a more permanent and less secure
record of the memory so add VM_DONTDUMP for all GPU buffers to
protect against that.
CRs-Fixed: 654751
Change-Id: Ic0dedbade91a2ec458bcb27eff3312d4ec6e4389
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
We don't need to define a function to return a constant. Save
ourselves some source code and some .text space too.
Change-Id: Ic0dedbadc72c2fdd473cd4369ed772c84a923a15
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Reserves CMA memory for kgsl driver early during bootup and then
uses dma_alloc_coherent() to allocate physically contiguous memory
instead of using the MMU
Change-Id: Ica9b244fe9b9d8a902d670293a0bec2edf81bd5d
Signed-off-by: Shrenuj Bansal <shrenujb@codeaurora.org>
Only set the default constraint when we come out of slumber if there
is no current constraint set. The current behavior will always override
the constraint that was set when coming out of slumber.
Signed-off-by: Carter Cooper <ccooper@codeaurora.org>
Change-Id: I58a5e2338bbee64e885edf697e83869820be2c22
No matter what type of constraint leave it in effect until
the constraint has expired.
Change-Id: I75118823fd484f87dda8e0f26fa3fe1ae12ca07d
Signed-off-by: Lucille Sylester <lsylvest@codeaurora.org>
Add missing trace to ensure debug logs show everything
Change-Id: I5da21b15ba498e1266d6c96b700c6c18135f92e9
Signed-off-by: Carter Cooper <ccooper@codeaurora.org>
Remove power constraint if parent context is
deleted before constraint expires.
Change-Id: I6a28fec842132733b2e9015333cc4d14c77daa8e
Signed-off-by: Oleg Perelet <operelet@codeaurora.org>
When creating a context, we add the event group much before
initializing the memstore for that context. Between these events,
its possible that events are registered and retired and the
timestamp read in retire_events() gets us the last timestamp of
the last destroyed context. This results in the processed
timestamp to be greater than the actual retired timestamp in the
memstore which is very problematic for us.
CRs-Fixed: 640550
Change-Id: I2ace6d99e2ce417ba38f6bbbeeb787478eb4e372
Signed-off-by: Shrenuj Bansal <shrenujb@codeaurora.org>
Cpufreq time_in_state data for all CPUs is made persistent across
hotplug and exposed to userspace via sysfs file
/sys/devices/system/cpu/cpufreq/all_time_in_state
Change-Id: I97cb5de24b6de16189bf8b5df9592d0a6e6ddf32
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
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>
Running a 3.4 kernel + Fedora-18 (systemd) userland on my Allwinner A10
(arm cortex a8), I'm seeing repeated, reproducable list_del list corruption
errors when build with CONFIG_DEBUG_LIST, and the backtrace always shows
free_css_set_work as the function making the problematic list_del call.
I've tracked this doen to a use after free of the cgrp struct, specifically
of the cgrp->css_sets list_head, which gets cleared by free_css_set_work.
Since free_css_set_work runs form a workqueue, it is possible for it to not be
done with clearing the list when the cgrp gets free-ed. To avoid this the code
adding the links increases cgrp->count, and the freeing code running from the
workqueue decreases cgrp->count *after* doing list_del, and then if the count
goes to 0 calls cgroup_wakeup_rmdir_waiter().
However cgroup_rmdir() is missing a check for cgrp->count != 0, causing it
to still continue with the rmdir (which leads to the free-ing of the cgrp),
before free_css_set_work is done. Sometimes the free-ed memory is re-used
before free_css_set_work gets around to unlinking link->cgrp_link_list,
triggering the list_del list corruption messages.
This patch fixes this by properly checking for cgrp->count != 0 and waiting
for the cgroup_rmdir_waitq in that case.
Change-Id: I9dbc02a0a75d5dffa1b65d67456e00139dea57c3
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
As indicated in the comment above cgroup_css_sets_empty it needs the
css_set_lock. But neither of the 2 call points have it, so rather then fixing
the callers just take the lock inside cgroup_css_sets_empty().
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Change-Id: If7aea71824f6d0e3f2cc6c1ce236c3ae6be2037b
The l2tp [get|set]sockopt() code has fallen back to the UDP functions
for socket option levels != SOL_PPPOL2TP since day one, but that has
never actually worked, since the l2tp socket isn't an inet socket.
As David Miller points out:
"If we wanted this to work, it'd have to look up the tunnel and then
use tunnel->sk, but I wonder how useful that would be"
Since this can never have worked so nobody could possibly have depended
on that functionality, just remove the broken code and return -EINVAL.
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Acked-by: James Chapman <jchapman@katalix.com>
Acked-by: David Miller <davem@davemloft.net>
Cc: Phil Turnbull <phil.turnbull@oracle.com>
Cc: Vegard Nossum <vegard.nossum@oracle.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ed Tam <etam@google.com>
Switching from a MAX to a MIN power constraint in the same
context is broken. So is switching from a MAX context constraint
to a MIN constraint on a different context. Clarify constraint
ownership, update the timestamps accordingly, and reset constraints
when changed by the context.
Change-Id: Id27dbc20e2aac994101817af3857451c1703219e
Signed-off-by: Lucille Sylvester <lsylvest@codeaurora.org>
Put CP_STATE_DEBUG_INDEX and CP_STATE_DEBUG_DATA under protection
to keep it from being written from an IB1. Doing so however opens
up a subtle "feature" in the microcode: memory read opcodes turn off
protected mode in the microcode to do the read and then turns it
back on regardless of the initial state. This is a problem if the
memory read happens while protected mode is turned off and then we
try to access a protected register which then complains and goes boom.
To account for this irregularity explicitly turn back off protected
mode in all the places where we know this will be a problem.
Change-Id: Ic0dedbad1397ca9b80132241ac006560a615e042
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
When we get a protected mode error print out the register information
that caused the exception.
Change-Id: Ic0dedbad4f586c5715669226619b51665ef9681f
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Put the SMMU register range in protected mode to shield them from
IB1/IB2 writes from userspace.
CRs-Fixed: 599971
Change-Id: Ic0dedbad8c03fc1c54ff73221231e2440d3c34dd
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Turn on protected register mode for the A3XX GPU family and add 0x63
(RBBM_INT_0_MASK) to the list of protected registers.
Change-Id: Ic0dedbad10ebfa6eb6d3d815b5aa9b6b6f0e8e35
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Mark the IOMMU setstate memory as read only in the pagetable.
Change-Id: Ic0dedbadb19e499c749cd744c3e89be3bcb4c2a2
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Over time chery-picks for KGSL have been skipped or
have been resolved differently between branches. As
a result, this branch of KGSL has become increasingly
difficult to maintain due to merge conflicts. With a
few exceptions KGSL should match the msm-3.4 mainline
exactly. To rectify the situation, this change brings
KGSL up-to-date with the msm-3.4 mainline as a bulk
change because cherry-picks are not practical.
Change-Id: I53f9f7fbf4942e147dea486ff5dbf179af75ea8c
Signed-off-by: Jeff Boody <jboody@codeaurora.org>
Nico Golde reports a few straggling uses of [io_]remap_pfn_range() that
really should use the vm_iomap_memory() helper. This trivially converts
two of them to the helper, and comments about why the third one really
needs to continue to use remap_pfn_range(), and adds the missing size
check.
CRs-Fixed: 570735
Change-Id: I927a67ea80fea5ed706749ead9defb1e72633952
Reported-by: Nico Golde <nico@ngolde.de>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org.
Git-commit: 7314e613d5
Git-repo: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
[pratibha@codeaurora.org:resolve trivial merge conflicts]
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
Signed-off-by: Ed Tam <etam@google.com>
This makes it possible to let gdb access mappings of the process that is
being debugged.
uio_mmap_logical was moved and uio_vm_ops renamed to group related code
and differentiate to new stuff.
CRs-Fixed: 570735
Change-Id: I8a5ff343727cc58fedfeb73f3466cc9a7f153e84
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: 7294151d05
Git-repo: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
Signed-off-by: Ed Tam <etam@google.com>
Update the driver to support backward compatibility for devices
relying on board files for platform data.
CRs-Fixed: 592586
Bug: 12784954
Change-Id: I04d4195a7fd4b926e52b0cbb2bb33cfcc054689f
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
Signed-off-by: Mekala Natarajan <mekalan@codeaurora.org>
The RemoteFS server now uses the UIO driver. So add the UIO
device for APQ8064
CRs-Fixed: 592586
Bug: 12784954
Change-Id: Ia0d643a10827869bfe527bf15ba064842e509487
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
Signed-off-by: Mekala Natarajan <mekalan@codeaurora.org>
Add new device driver to provide a standard interface for its
clients (like RemoteFS and RFSA) to be able to memory map their
respective allotted shared memory address in the client's address space.
The shared memory (a transport buffer) address is unique for each
individual client and is made available to the driver via device tree.
This driver uses the existing UIO framework to facilitate the clients
mmap requirements. Each individual client will be able to use a unique
UIO device for this purpose.
CRs-Fixed: 477427
Bug: 12784954
Change-Id: If07b88086b5f1b87845962818094644575629fcf
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Signed-off-by: Mekala Natarajan <mekalan@codeaurora.org>
The existing code does not have dependencies to check the flag
based on the new KGSL_* flags. A subsequent change will restore
the flag check when the dependencies have been merged.
Change-Id: Ibc3de28d2c21467f9b31887282c00726750e079e
Signed-off-by: Jeff Boody <jboody@codeaurora.org>
Make stop scheduler class do the same accounting as other classes,
Migration threads can be caught in the act while doing exec balancing,
leading to the below due to use of unmaintained ->se.exec_start. The
load that triggered this particular instance was an apparently out of
control heavily threaded application that does system monitoring in
what equated to an exec bomb, with one of the VERY frequently migrated
tasks being ps.
%CPU PID USER CMD
99.3 45 root [migration/10]
97.7 53 root [migration/12]
97.0 57 root [migration/13]
90.1 49 root [migration/11]
89.6 65 root [migration/15]
88.7 17 root [migration/3]
80.4 37 root [migration/8]
78.1 41 root [migration/9]
44.2 13 root [migration/2]
Signed-off-by: Mike Galbraith <mgalbraith@suse.de>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1344051854.6739.19.camel@marge.simpson.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
This contains the following commits:
1. 0149763 net: core: Add a UID range to fib rules.
2. 1650474 net: core: Use the socket UID in routing lookups.
3. 0b16771 net: ipv4: Add the UID to the route cache.
4. ee058f1 net: core: Add a RTA_UID attribute to routes.
This is so that userspace can do per-UID route lookups.
Bug: 15413527
Change-Id: I1285474c6734614d3bda6f61d88dfe89a4af7892
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
For contexts created with the KGSL_CONTEXT_USER_GENERATED_TS,
allow events to be created for timestamps that have not
been issued yet. Presumably these contexts know what they
are doing.
Change-Id: Iccf2e549b38e1a11850d26ee64b7279ab0b8a1ae
Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org>
Make sure that a power constraint is given a full DCVS interval to
influence the GPU before having it adjusted back down.
Change-Id: Ic0dedbad22e74ce6e62e26c386b900442d7bab40
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Add an interface to hint the user specified power
constraint. User can specify a particular GPU power level
or a bandwidth vote. The power constraints are per context
or command batch. Power constraints are only for hinting
and should be used judiciously.
Change-Id: Ic10a5fff4abc88c51cd45a7d7ac58c0d4e5dcb25
Signed-off-by: Suman Tatiraju <sumant@codeaurora.org>
Signed-off-by: Lucille Sylvester <lsylvest@codeaurora.org>
There is a possible race condition where the process can be going
away while its debugfs 'mem' file is being read, which could cause
memory corruption.
CRs-Fixed: 627780
Change-Id: I697486faeb3f186fd1220d0acc1e449a4f7b77b0
Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org>
Restructure IOMMU clock management code to enable/disable clocks
based on iommu unit instead of context. In hardware IOMMU clocks
are associated with each IOMMU unit. There is no granularity of
clock control for each iommu context. Turning on the clocks for
one context in a IOMMU unit automatically turns on the clocks for
all the contexts in IOMMU unit. Reduce the number of clock
enable/disable calls and structure the software design as per
hardware design by doing clock management per IOMMU unit.
Change-Id: Ib54dbb7a31d6b30b65c07ef130bee149e3e587d8
Signed-off-by: Tarun Karra <tkarra@codeaurora.org>
Allow each mmu clock enable call to enable the clock and let the
clock driver refcounting mechanism deal with switching the clock
off at the right time. This also means that each enable call should
have a disable call or a disable event registered, so allow for
multiple disable events to be registered. This simplifies the mmu
clock handling mechanism which is better for multiple ringbuffer
implementation. With multiple ringbuffers each global timestamp is
tied to a specific ringbuffer and with a single clock disable event
it is hard to figure out when the clock should be turned off.
Change-Id: I924c545140bd19d95890a5fdfd0382c511abe973
Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org>
