[Bug uprobes/10595] New: uprobe return probes causes selinux failures

[Bug uprobes/10595] New: uprobe return probes causes selinux failures

[mjw at redhat dot com]

When selinux is in enforcing mode and allow_execstack=false trying to set uprobe
return probes on an executable causes selinux denials (and failing to insert the
probe).

Take for example the bz10078.exp testcase, which simply does:

probe process("./bz10078").function("mkpoint*").return {
	printf("%s returns\n", probefunc())
}

With selinux in enforcing mode and disallowing executable stacks:
$ setenforce Enforcing
$ setsebool allow_execstack=false
$ stap systemtap.base/bz10078.stp -c ./bz10078

/var/log/messages:
setroubleshoot: SELinux is preventing bz10078 from changing a writable memory
segment executable. For complete SELinux messages. run sealert -l
725eeb90-824c-4e00-b0c5-3575cdf7d070

$ sealert -l 725eeb90-824c-4e00-b0c5-3575cdf7d070

Summary:

SELinux is preventing bz10078 from changing a writable memory segment
executable.

Detailed Description:

The bz10078 application attempted to change the access protection of memory
(e.g., allocated using malloc). This is a potential security problem.
Applications should not be doing this. Applications are sometimes coded
incorrectly and request this permission. The SELinux Memory Protection Tests
(http://people.redhat.com/drepper/selinux-mem.html) web page explains how to
remove this requirement. If bz10078 does not work and you need it to work, you
can configure SELinux temporarily to allow this access until the application is
fixed. Please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package.

Allowing Access:

If you trust bz10078 to run correctly, you can change the context of the
executable to execmem_exec_t. "chcon -t execmem_exec_t '<Unknown>'". You must
also change the default file context files on the system in order to preserve
them even on a full relabel. "semanage fcontext -a -t execmem_exec_t '<Unknown>'"

Fix Command:

chcon -t execmem_exec_t '<Unknown>'

Additional Information:

Source Context                unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Target Context                unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Target Objects                None [ process ]
Source                        bz10078
Source Path                   <Unknown>
Port                          <Unknown>
Host                          springer.wildebeest.org
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.12-80.fc11
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   allow_execmem
Host Name                     springer.wildebeest.org
Platform                      Linux springer.wildebeest.org
                              2.6.29.6-217.2.16.fc11.x86_64 #1 SMP Mon Aug 24
                              17:17:40 EDT 2009 x86_64 x86_64
Alert Count                   2
First Seen                    Thu Sep  3 14:08:51 2009
Last Seen                     Thu Sep  3 14:10:20 2009
Local ID                      725eeb90-824c-4e00-b0c5-3575cdf7d070
Line Numbers                  

Raw Audit Messages            

node=springer.wildebeest.org type=AVC msg=audit(1251979820.974:270): avc: 
denied  { execmem } for  pid=12251 comm="bz10078"
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process

-- 
           Summary: uprobe return probes causes selinux failures
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: uprobes
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: mjw at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=10595

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10595] uprobe return probes causes selinux failures

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-09-03 14:18 -------
We discussed a bit on irc (and I had a little help interpreting what happened
from eparis). Some extra info:

- allow_execstack implies allow_execmem.
  The failure is not really about anything stack related.
  It comes from setting writable memory executable.
- The most likely candidate triggering this issue is in
  uprobe_setup_ssol_vma:
      addr = do_mmap_pgoff(NULL, addr, nbytes, PROT_EXEC,
                                    MAP_PRIVATE|MAP_ANONYMOUS, 0);

As http://people.redhat.com/drepper/selinux-mem.html explains:
execmem
   There are two situations when this error can appear:
      * The program maps anonymous memory with mmap with PROT_EXEC.
        Note that because anonymous memory is zero'd out by the system
        it makes not much sense to not have it writable as well.

For user space working around that issue is also explained on that page.
That might not be completely trivial in kernel space since it involves mmaping a
file twice (we could do that with do_mmap_pgoff where user space uses mmap).

ananth suggested we might want to look how vdso/vmap areas get around these
restrictions.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10595

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10595] uprobe probes causes selinux failures

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-09-03 16:25 -------
It isn't return probe specific like I first thought.
With both normal and return probes there is this hint in /var/log/messages:
kernel: Uprobes failed to allocate a vma for pid/tgid 17519/17519 for
single-stepping out of line.

The strange thing is that normal uprobes still seem to work, they trigger their
handler as expected even though you get a selinux denial message, but return
probes don't trigger.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|uprobe return probes causes |uprobe probes causes selinux
                   |selinux failures            |failures


http://sourceware.org/bugzilla/show_bug.cgi?id=10595

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10595] uprobe probes causes selinux failures

[jkenisto at us dot ibm dot com]

------- Additional Comments From jkenisto at us dot ibm dot com  2009-09-03 17:43 -------
(In reply to comment #2)
> It isn't return probe specific like I first thought.
> With both normal and return probes there is this hint in /var/log/messages:
> kernel: Uprobes failed to allocate a vma for pid/tgid 17519/17519 for
> single-stepping out of line.
> 
> The strange thing is that normal uprobes still seem to work, they trigger their
> handler as expected even though you get a selinux denial message, but return
> probes don't trigger.

When uprobes fails to create the vma, it falls back to single-stepping inline,
which doesn't require the vma.  We don't have a Plan B for uretprobes, though:
the only place we know to put the uretprobe trampoline is in slot 0 of our vma 
(There are, of course, alternatives, but they're not currently coded for.)

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10595

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10595] uprobe probes causes selinux failures

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-09-03 20:13 -------
Roland made the observation that a private mapping of a file as executable is
allowed and that you can create one through shmem_file_setup (which has as an
extra benefit that /proc/<pid>/maps shows the mapping as /uprobes/ssol). That
seems to work.

Currently testing this patch:

diff --git a/runtime/uprobes2/uprobes.c b/runtime/uprobes2/uprobes.c
index 07ad398..195a79b 100644
--- a/runtime/uprobes2/uprobes.c
+++ b/runtime/uprobes2/uprobes.c
@@ -1387,6 +1387,7 @@ static noinline unsigned long
uprobe_setup_ssol_vma(unsigned long nbytes)
        unsigned long addr;
        struct mm_struct *mm;
        struct vm_area_struct *vma;
+       struct file *file;
 
        BUG_ON(nbytes & ~PAGE_MASK);
        if ((addr = find_old_ssol_vma()) != 0)
@@ -1403,8 +1404,8 @@ static noinline unsigned long
uprobe_setup_ssol_vma(unsigned long nbytes)
         */
        vma = rb_entry(rb_last(&mm->mm_rb), struct vm_area_struct, vm_rb);
        addr = vma->vm_end + PAGE_SIZE;
-       addr = do_mmap_pgoff(NULL, addr, nbytes, PROT_EXEC,
-                                       MAP_PRIVATE|MAP_ANONYMOUS, 0);
+        file = shmem_file_setup("uprobes/ssol", nbytes, VM_NORESERVE);
+       addr = do_mmap_pgoff(file, addr, nbytes, PROT_EXEC, MAP_PRIVATE, 0);
        if (addr & ~PAGE_MASK) {
                up_write(&mm->mmap_sem);
                mmput(mm);

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10595

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10595] uprobe probes causes selinux failures

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-09-04 11:09 -------
Created an attachment (id=4170)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4170&action=view)
ssol-vma-selinux patch using shmem_file_setup

This is the patch that seems to work fine for me. I added some comments and
some error messages in case something fails. This is against uprobes2, I assume
uprobes1 needs a similar fix. Is the systemtap version where these should go,
or is there another upstream for uprobes now?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10595

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10595] uprobe probes causes selinux failures

[srikar at linux dot vnet dot ibm dot com]

------- Additional Comments From srikar at linux dot vnet dot ibm dot com  2009-09-04 11:58 -------
> some error messages in case something fails. This is against uprobes2, I assume
> uprobes1 needs a similar fix. Is the systemtap version where these should go,
> or is there another upstream for uprobes now?

Yes we need a similar fix for uprobes (i.e uprobes1). The current uprobes is
maintained as a branch on fche's utrace-ext git tree.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10595

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10595] uprobe probes causes selinux failures

[jkenisto at us dot ibm dot com]

------- Additional Comments From jkenisto at us dot ibm dot com  2009-09-04 17:11 -------
(In reply to comment #5)
> Created an attachment (id=4170)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4170&action=view)
> ssol-vma-selinux patch using shmem_file_setup

At this point
       if (addr & ~PAGE_MASK) {
addr will be undefined if shmem_file_setup() returned NULL.  So...
       if (!file || (addr & ~PAGE_MASK)) {

> 
> This is the patch that seems to work fine for me. I added some comments and
> some error messages in case something fails. This is against uprobes2, I assume
> uprobes1 needs a similar fix. Is the systemtap version where these should go,
> or is there another upstream for uprobes now?

Yes, runtime/uprobes/uprobes.c and ubp_xol.c (?) in the ubp-based uprobes bits.
 Thanks, mjw.  Srikar, are you going to take it from here?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10595

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10595] uprobe probes causes selinux failures

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-09-04 17:25 -------
(In reply to comment #7)
> (In reply to comment #5)
> > Created an attachment (id=4170)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4170&action=view)
> > ssol-vma-selinux patch using shmem_file_setup
> 
> At this point
>        if (addr & ~PAGE_MASK) {
> addr will be undefined if shmem_file_setup() returned NULL.

addr would be 0 if !file, since earlier in the function we have:

        if ((addr = find_old_ssol_vma()) != 0)
                return addr;

> Yes, runtime/uprobes/uprobes.c and ubp_xol.c (?) in the ubp-based uprobes bits.
>  Thanks, mjw.  Srikar, are you going to take it from here?

I found fche's utrace-ext.git repo, is that where those are now? I can certainly
build that and supply a patch for it. Which branch should it be against?
utrace-uprobes or utrace-gdbstub-uprobes? Does that uprobes kernel module
version work against systemtap git?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10595

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10595] uprobe probes causes selinux failures

[jkenisto at us dot ibm dot com]

------- Additional Comments From jkenisto at us dot ibm dot com  2009-09-04 18:08 -------
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #5)
> > > Created an attachment (id=4170)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4170&action=view)
> > > ssol-vma-selinux patch using shmem_file_setup
> > 
> > At this point
> >        if (addr & ~PAGE_MASK) {
> > addr will be undefined if shmem_file_setup() returned NULL.
> 
> addr would be 0 if !file, since earlier in the function we have:
> 
>         if ((addr = find_old_ssol_vma()) != 0)
>                 return addr;

You're right, it'd be 0.  But with above test, addr==0 would look like success.

> 
> > Yes, runtime/uprobes/uprobes.c and ubp_xol.c (?) in the ubp-based uprobes bits.
> >  Thanks, mjw.  Srikar, are you going to take it from here?
> 
> I found fche's utrace-ext.git repo, is that where those are now? I can certainly
> build that and supply a patch for it. Which branch should it be against?
> utrace-uprobes or utrace-gdbstub-uprobes? Does that uprobes kernel module
> version work against systemtap git?

Sorry, I haven't been keeping up with that code base except via code reviews.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10595

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10595] uprobe probes causes selinux failures

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-09-07 11:38 -------
(In reply to comment #9)
> You're right, it'd be 0.  But with above test, addr==0 would look like success.

Doh! I read over that "inverse" of the test all this time... Thanks.

Porting to uprobes1 is slightly more difficult because shmem_file_setup() hasn't
been exported on older kernels. It was only exported since:

commit 395e0ddc44005ced5e4fed9bfc2e4bdf63d37627
Author: Keith Packard <keithp@keithp.com>
Date:   Fri Jun 20 00:08:06 2008 -0700

    Export shmem_file_setup for DRM-GEM

So this is only available since 2.6.28+

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10595

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10595] uprobe probes causes selinux failures

[srikar at linux dot vnet dot ibm dot com]

------- Additional Comments From srikar at linux dot vnet dot ibm dot com  2009-09-08 12:26 -------
 
> > Yes, runtime/uprobes/uprobes.c and ubp_xol.c (?) in the ubp-based uprobes bits.
> >  Thanks, mjw.  Srikar, are you going to take it from here?
> 
> I found fche's utrace-ext.git repo, is that where those are now? I can certainly
> build that and supply a patch for it. Which branch should it be against?
> utrace-uprobes or utrace-gdbstub-uprobes? Does that uprobes kernel module
> version work against systemtap git?

Yes, Its in utrace-ext.git repo. It should be against utrace-gdbstub-uprobe
branch.  Generally I send patches to utrace-devel and cc Frank and Frank picks
the patch and applies it. 

However uprobes code in the git tree is a little different. That particular
snippet of code has moved to kernel/ubp_xol.c.  Do let me know if you want me to
apply the patch and send it across. 

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10595

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10595] uprobe probes causes selinux failures

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-09-10 15:49 -------
I can't seem to reproduce this exactly on a pretty plain rawhide x86-64 box:

sudo ./stap -e 'probe process("./stap").function("*").return {}' -t -c './stap -V'
WARNING: u*probe failed stap[1567]
'process("/notnfs/BUILDg3/stap").function("~basic_stringbuf@/usr/lib/gcc/x86_64-redhat-linux/4.4.1/../../../../include/c++/4.4.1/iosfwd:63").return'
addr (null) rc -22
SystemTap translator/driver (version 0.9.9/0.142 commit release-0.9.9-278-ged4abdf)
Copyright (C) 2005-2009 Red Hat, Inc. and others
This is free software; see the source for copying conditions.
WARNING: Number of errors: 0, skipped probes: 1
WARNING: Skipped due to uprobe register failure: 1
probe process("./stap").function("*").return (<input>:1:1), hits: 40, cycles:
440min/839avg/3192max

Note that we're registering 40 hits.

Linux vm-rawhide-64 2.6.31-0.204.rc9.fc12.x86_64 #1 SMP Sat Sep 5 20:45:55 EDT
2009 x86_64 x86_64 x86_64 GNU/Linux

[11:45:19] % getenforce 
Enforcing

[11:45:26] % getsebool -a | grep exec
allow_execheap --> off
allow_execmem --> off
allow_execmod --> off
allow_execstack --> off
allow_guest_exec_content --> off
allow_java_execstack --> off
allow_mplayer_execstack --> off
allow_nsplugin_execmem --> on
allow_staff_exec_content --> on
allow_sysadm_exec_content --> on
allow_user_exec_content --> on
allow_xguest_exec_content --> off
allow_xserver_execmem --> off
httpd_execmem --> off
httpd_ssi_exec --> off


But here comes dmesg:

Sep 10 11:44:23 vm-rawhide-64 setroubleshoot: SELinux is preventing stap from
changing a writable memory segment executable. For complete SELinux messages.
run sealert -l ceedcc9e-b241-4b91-8307-bda74d8c2048



-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10595

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10595] uprobe probes causes selinux failures

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-09-14 18:51 -------
To prevent leaks, the filp created needs to be saved away, and later fput()'d
at deallocation time.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10595

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10595] uprobe probes causes selinux failures

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-09-14 19:26 -------
(In reply to comment #13)
> To prevent leaks, the filp created needs to be saved away, and later fput()'d
> at deallocation time.

when the vma gets deallocated the filp will be fput also, see mm/mmap.c
remove_vma().

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10595

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10595] uprobe probes causes selinux failures

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-09-14 19:51 -------
(In reply to comment #14)
> (In reply to comment #13)
> > To prevent leaks, the filp created needs to be saved away, and later fput()'d
> > at deallocation time.
> 
> when the vma gets deallocated the filp will be fput also, see mm/mmap.c
> remove_vma().

On irc fche pointed out that fput() just cancels the get_file() in mm/mmap.c
(mmap_region). So we probably should fput it immediately after calling
do_mmap_pgoff().

Hint: Examine the sequence and f_counts with some well placed stap
kernel.function* trace probes.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10595

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10595] uprobe probes causes selinux failures

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-09-17 10:27 -------
For now I only fixed this for uprobe2 and only for kernels 2.6.28+

commit a82ac1f413712a375d5e14ef7641ce0abf7a6543
Author: Mark Wielaard <mjw@redhat.com>
Date:   Thu Sep 17 12:20:07 2009 +0200

    PR10595 Work around uprobe2 causing selinux failures for kernel 2.6.28+.
    
    We allocate a "fake" unlinked shmem file because anonymous
    memory might not be granted execute permission when the selinux
    security hooks have their way. Only do this for 2.6.28 or higher
    since shmem_file_setup() isn't exported before that.
    
    * runtime/uprobes2/uprobes.c (uprobe_setup_ssol_vma): Use shmem_file_setup
      to setup the ssol vma area when using 2.6.28+.

This incorporates the suggestions from Jim and Frank above.

For upstream the version checks are obviously not necessary, but I ran out of
time doing those plus the testing.

I'll keep the bug open till I also submitted a version for the upstream uprobes
code. And till we decided whether it makes sense to find some other workaround
for < 2.6.28 kernels and/or uprobes1 (I don't think we should really care, such
old systems often have much more relaxed selinux policies).

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10595

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10595] uprobe probes causes selinux failures

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-09-17 13:14 -------
Testing revealed a bug:

Kernel failure message 1:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000630
IP: [<ffffffff814988d7>] _spin_lock+0x21/0x46
PGD b0e4067 PUD b0e3067 PMD 0 
Oops: 0002 [#1] SMP 
last sysfs file: /sys/module/xt_physdev/sections/__mcount_loc
CPU 7 
Modules linked in: stap_2c0d92a42696e0b495ce489ac431753a_4280 uprobes
stap_aa1e7516de55bfd642e59fea88b3a92e_724 fuse ipt_MASQUERADE iptable_nat nf_nat
nfsd lockd nfs_acl auth_rpcgss exportfs sunrpc bridge stp llc xt_physdev
ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand
acpi_cpufreq freq_table dm_multipath kvm_intel kvm uinput snd_hda_codec_realtek
snd_hda_intel snd_hda_codec snd_usb_audio snd_usb_lib snd_pcm firewire_ohci
usb_storage snd_rawmidi firewire_core snd_timer snd_seq_device snd_hwdep snd tg3
pcspkr serio_raw snd_page_alloc soundcore crc_itu_t iTCO_wdt iTCO_vendor_support
wmi raid1 raid456 raid6_pq async_xor async_memcpy async_tx xor radeon drm
i2c_algo_bit i2c_core [last unloaded: stap_b39ec4f1c801ecdf527d18df16835669_60505]
Pid: 1635, comm: stapio Not tainted 2.6.30.5-43.fc11.x86_64 #1 HP Z400 Workstation
RIP: 0010:[<ffffffff814988d7>]  [<ffffffff814988d7>] _spin_lock+0x21/0x46
RSP: 0018:ffff88001c06fd08  EFLAGS: 00010246
RAX: 0000000000000100 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff88001c06fdf8 RSI: 0000000000400830 RDI: 0000000000000630
RBP: ffff88001c06fd18 R08: ffffffffa066c040 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000400830
R13: ffff88001c06fdf8 R14: 0000000000000000 R15: 00007fff674f1a3c
FS:  00007f74a2fe16f0(0000) GS:ffff8800281c1000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000630 CR3: 000000000b0e1000 CR4: 00000000000026e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
Process stapio (pid: 1635, threadinfo ffff88001c06e000, task ffff880018d39750)
Stack:
 0000000000000246 000000008d54a699 ffff88001c06fd48 ffffffff81054206
 0000000000000001 000000008d54a699 ffff88001c06fd78 0000000000000148
 ffff88001c06fde8 ffffffffa0664cd2 00007fff674f1a44 ffff88001c11aea0
Call Trace:
 [<ffffffff81054206>] get_task_mm+0x2c/0x67
 [<ffffffffa0664cd2>] __access_process_vm.clone.0+0x38/0x197
[stap_2c0d92a42696e0b495ce489ac431753a_4280]
 [<ffffffffa06662e4>] _stp_cleanup_and_exit+0xcc/0x202
[stap_2c0d92a42696e0b495ce489ac431753a_4280]
 [<ffffffffa0667bf8>] _stp_ctl_write_cmd+0x742/0x90e
[stap_2c0d92a42696e0b495ce489ac431753a_4280]
 [<ffffffff811eae5f>] ? selinux_file_permission+0x69/0x84
 [<ffffffff81114f6e>] vfs_write+0xbd/0x12e
 [<ffffffff811150d1>] sys_write+0x59/0x91
 [<ffffffff81012082>] system_call_fastpath+0x16/0x1b
Code: 00 74 05 e8 21 e9 bb ff c9 c3 55 48 89 e5 48 83 ec 10 0f 1f 44 00 00 65 48
8b 04 25 28 00 00 00 48 89 45 f8 31 c0 b8 00 01 00 00 <f0> 66 0f c1 07 38 e0 74
06 f3 90 8a 07 eb f6 48 8b 45 f8 65 48 
RIP  [<ffffffff814988d7>] _spin_lock+0x21/0x46
 RSP <ffff88001c06fd08>
CR2: 0000000000000630
---[ end trace 0d91556aaea5efba ]---

Not clear yet, what exactly triggered this one.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10595

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10595] uprobe probes causes selinux failures

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2009-09-17 15:53 -------
Possibly related crash:  4-cpu i686 VM: 

Linux version 2.6.31-12.fc12.i686 (mockbuild@x86-4.fedora.phx.redhat.com) (gcc
version 4.4.1 20090911 (Red Hat 4.4.1-13) (GCC) ) #1 SMP Mon Sep 14 02:27:06 EDT
2009

stap_e809d5710cc468e42f174557192e2ead_4791: systemtap: 0.9.9/0.142, base:
f7ffd000, memory: 49152+24576+2464+13600 data+text+ctx+net, probes: 5
type=1400 audit(1253202047.130:18): avc:  denied  { execmem } for  pid=11876
comm="static_user_mar"
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
BUG: unable to handle kernel paging request at f80030b0
IP: [<f7fff857>] stap_uprobe_process_found+0x17a/0x270
[stap_e809d5710cc468e42f174557192e2ead_4791]
*pde = 35991067 *pte = 7effd161 
Oops: 0003 [#1] SMP 
last sysfs file: /sys/module/virtio_pci/sections/__mcount_loc
Modules linked in: stap_e809d5710cc468e42f174557192e2ead_4791 uprobes netconsole
iptable_nat nf_nat nfsd exportfs configfs nfs lockd fscache nfs_acl auth_rpcgss
sunrpc ipv6 dm_multipath uinput ppdev 8139too parport_pc i2c_piix4 parport
i2c_core 8139cp mii virtio_balloon floppy virtio_pci [last unloaded:
stap_aabe53c3fe286bb5f3adf68485fc5693_12327]

Pid: 11876, comm: static_user_mar Tainted: G        W  (2.6.31-12.fc12.i686 #1) 
EIP: 0060:[<f7fff857>] EFLAGS: 00210206 CPU: 2
EIP is at stap_uprobe_process_found+0x17a/0x270
[stap_e809d5710cc468e42f174557192e2ead_4791]
EAX: da1b8000 EBX: f800309c ECX: d9c17e0c EDX: 08048600
ESI: f8008304 EDI: da1b8000 EBP: d9c17e20 ESP: d9c17dfc
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process static_user_mar (pid: 11876, ti=d9c16000 task=da1b8000 task.ti=d9c16000)
Stack:
 00000001 00000000 da1b833c 00000000 0a640f34 0a640f34 f8007258 da1b8000
<0> f7fff6dd d9c17e48 f7fff9dd 00000001 00000001 00000001 f8007250 0a640f34
<0> da1b8000 db7fa048 da1b8440 d9c17e7c f8000a4b 00000001 00000002 00200246
Call Trace:
 [<f7fff6dd>] ? stap_uprobe_process_found+0x0/0x270
[stap_e809d5710cc468e42f174557192e2ead_4791]
 [<f7fff9dd>] ? __stp_call_callbacks+0x50/0x8f
[stap_e809d5710cc468e42f174557192e2ead_4791]
 [<f8000a4b>] ? __stp_utrace_task_finder_target_quiesce+0xf5/0x2a5
[stap_e809d5710cc468e42f174557192e2ead_4791]
 [<c048b856>] ? start_report+0x34/0x79
 [<c048baf1>] ? start_callback+0x53/0xb7
 [<c048d014>] ? utrace_resume+0xbb/0xf3
 [<c040332b>] ? do_notify_resume+0x773/0x7a7
 [<c06065d1>] ? debug_check_no_obj_freed+0x7c/0x175
 [<c04ee5e7>] ? check_valid_pointer+0x2c/0x6c
 [<c04f0530>] ? __slab_free+0x219/0x24e
 [<c046fd09>] ? trace_hardirqs_on_caller+0x26/0x155
 [<c0504348>] ? putname+0x39/0x53
 [<c046f084>] ? trace_hardirqs_off_caller+0x26/0xb7
 [<c0403b58>] ? work_notifysig+0x13/0x1b
Code: 75 00 f8 40 83 f8 64 7e 14 c7 05 38 75 00 f8 02 00 00 00 c7 05 28 75 00 f8
01 00 00 00 83 7b 10 00 74 26 8b 53 10 8d 4d ec 89 f8 <89> 7b 14 6a 00 e8 0f f5
ff ff 8d 4d ec 89 f8 ff 45 ec 8b 53 10 
EIP: [<f7fff857>] stap_uprobe_process_found+0x17a/0x270
[stap_e809d5710cc468e42f174557192e2ead_4791] SS:ESP 0068:d9c17dfc
CR2: 00000000f80030b0


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10595

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10595] uprobe probes causes selinux failures

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-09-18 15:08 -------
Neither the issue in comment #17 nor the issue in comment #18 could be reproduced.

There were two different issues though, neither apparently directly related to
this bug, but just with symptoms that looked similar.

1) The new enabled semaphores used the .probes section for holding variables.
This conflicted with the non-writable .probes section definition in sdt.h. This
was fixed by:

commit 5ee3f305e81fd2e1953d8a74530326f728a33ce8
Author: Mark Wielaard <mjw@redhat.com>
Date:   Fri Sep 18 16:13:24 2009 +0200

    Always mark .probes section as writable.
    
    Allocated section needs to be writable when creating pic shared objects
    because we store relocatable addresses in them.  We used to make this
    read only for non-pic executables, but the new semaphore support relies
    on having a writable .probes section to put the enabled variables in.
    
    * includes/sys/sdt.h (ALLOCSEC): Define unconditionally as "aw".

2) There seems to be a kernel warning (bug?) in ima_file_free() called by
selinux_file_free_security() that triggers with and without this fix.
https://bugzilla.redhat.com/show_bug.cgi?id=519737

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10595

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug uprobes/10595] uprobe probes causes selinux failures

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-12-14 14:18 -------
Both the actual fix (PR10595 Work around uprobe2 causing selinux failures for
kernel 2.6.28+) and some of the other fixes (Always mark .probes section as
writable) have been pushed everywhere.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=10595

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.