perf kvm: Finding struct machine fails for PERF_RECORD_MMAP - kernel - Hosts the 0x221E linux distro kernel.

Hosts the 0x221E linux distro kernel.

Ubuntu

summary refs log tree commit diff

path: root/tools/perf/scripts/python/bin

diff options

author	Nikunj A. Dadhania <nikunj@linux.vnet.ibm.com>	2012-04-09 13:52:23 +0530
committer	Arnaldo Carvalho de Melo <acme@redhat.com>	2012-04-11 11:45:12 -0300
commit	7fb0a5ee8889488f7568ffddffeb66ddeb50917e (patch)
tree	9116fdaba568f251c328f8a2cbe5ad828c0e71bc /tools/perf/scripts/python/bin
parent	31d68e7b66f168e623902e194af1e52b8cf75d71 (diff)
download	kernel-7fb0a5ee8889488f7568ffddffeb66ddeb50917e.tar.gz

perf kvm: Finding struct machine fails for PERF_RECORD_MMAP

Running 'perf kvm --host --guest --guestmount /tmp/guestmount record -a -g -- sleep 2' Was resulting in a segfault. For event type PERF_RECORD_MMAP, event->ip.pid is being used in perf_session__find_machine_for_cpumode, which is not correct. The event->ip.pid field happens to be 0 in this case and results in returning a NULL machine object. Finally, access to self->pid in machine__mmap_name, results in a segfault later. For PERF_RECORD_MMAP type, pass event->mmap.pid. Signed-off-by: Nikunj A. Dadhania <nikunj@linux.vnet.ibm.com> Reviewed-by: David Ahern <dsahern@gmail.com> Tested-by: David Ahern <dsahern@gmail.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Stephane Eranian <eranian@google.com> Cc: Nikunj A. Dadhania <nikunj@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/20120409081835.10576.22018.stgit@abhimanyu.in.ibm.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

Diffstat (limited to 'tools/perf/scripts/python/bin')

0 files changed, 0 insertions, 0 deletions

and ensure their changes fit in well with the rest of the SELinux kernel code. Signed-off-by: Paul Moore <paul@paul-moore.com> 2023-11-21selinux: introduce an initial SID for early boot processesOndrej Mosnacek Currently, SELinux doesn't allow distinguishing between kernel threads and userspace processes that are started before the policy is first loaded - both get the label corresponding to the kernel SID. The only way a process that persists from early boot can get a meaningful label is by doing a voluntary dyntransition or re-executing itself. Reusing the kernel label for userspace processes is problematic for several reasons: 1. The kernel is considered to be a privileged domain and generally needs to have a wide range of permissions allowed to work correctly, which prevents the policy writer from effectively hardening against early boot processes that might remain running unintentionally after the policy is loaded (they represent a potential extra attack surface that should be mitigated). 2. Despite the kernel being treated as a privileged domain, the policy writer may want to impose certain special limitations on kernel threads that may conflict with the requirements of intentional early boot processes. For example, it is a good hardening practice to limit what executables the kernel can execute as usermode helpers and to confine the resulting usermode helper processes. However, a (legitimate) process surviving from early boot may need to execute a different set of executables. 3. As currently implemented, overlayfs remembers the security context of the process that created an overlayfs mount and uses it to bound subsequent operations on files using this context. If an overlayfs mount is created before the SELinux policy is loaded, these "mounter" checks are made against the kernel context, which may clash with restrictions on the kernel domain (see 2.). To resolve this, introduce a new initial SID (reusing the slot of the former "init" initial SID) that will be assigned to any userspace process started before the policy is first loaded. This is easy to do, as we can simply label any process that goes through the bprm_creds_for_exec LSM hook with the new init-SID instead of propagating the kernel SID from the parent. To provide backwards compatibility for existing policies that are unaware of this new semantic of the "init" initial SID, introduce a new policy capability "userspace_initial_context" and set the "init" SID to the same context as the "kernel" SID unless this capability is set by the policy. Another small backwards compatibility measure is needed in security_sid_to_context_core() for before the initial SELinux policy load - see the code comment for explanation. Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com> Reviewed-by: Stephen Smalley <stephen.smalley.work@gmail.com> [PM: edited comments based on feedback/discussion] Signed-off-by: Paul Moore <paul@paul-moore.com> 2022-05-03selinux: declare data arrays constChristian Göttsche The arrays for the policy capability names, the initial sid identifiers and the class and permission names are not changed at runtime. Declare them const to avoid accidental modification. Do not override the classmap and the initial sid list in the build time script genheaders. Check flose(3) is successful in genheaders.c, otherwise the written data might be corrupted or incomplete. Signed-off-by: Christian Göttsche <cgzones@googlemail.com> [PM: manual merge due to fuzz, minor style tweaks] Signed-off-by: Paul Moore <paul@paul-moore.com> 2022-03-02selinux: shorten the policy capability enum namesPaul Moore The SELinux policy capability enum names are rather long and follow the "POLICYDB_CAPABILITY_XXX format". While the "POLICYDB_" prefix is helpful in tying the enums to other SELinux policy constants, macros, etc. there is no reason why we need to spell out "CAPABILITY" completely. Shorten "CAPABILITY" to "CAP" in order to make things a bit shorter and cleaner. Moving forward, the SELinux policy capability enum names should follow the "POLICYDB_CAP_XXX" format. Signed-off-by: Paul Moore <paul@paul-moore.com> 2022-02-25selinux: allow FIOCLEX and FIONCLEX with policy capabilityRichard Haines These ioctls are equivalent to fcntl(fd, F_SETFD, flags), which SELinux always allows too. Furthermore, a failed FIOCLEX could result in a file descriptor being leaked to a process that should not have access to it. As this patch removes access controls, a policy capability needs to be enabled in policy to always allow these ioctls. Based-on-patch-by: Demi Marie Obenour <demiobenour@gmail.com> Signed-off-by: Richard Haines <richard_c_haines@btinternet.com> [PM: subject line tweak] Signed-off-by: Paul Moore <paul@paul-moore.com> 2020-08-17scripts/selinux,selinux: update mdp to enable policy capabilitiesStephen Smalley Presently mdp does not enable any SELinux policy capabilities in the dummy policy it generates. Thus, policies derived from it will by default lack various features commonly used in modern policies such as open permission, extended socket classes, network peer controls, etc. Split the policy capability definitions out into their own headers so that we can include them into mdp without pulling in other kernel headers and extend mdp generate policycap statements for the policy capabilities known to the kernel. Policy authors may wish to selectively remove some of these from the generated policy. Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com> Signed-off-by: Paul Moore <paul@paul-moore.com>