Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
# setsebool deny_execmem on
# /usr/bin/valgrind /bin/ls
==26552==
==26552== Valgrind's memory management: out of memory:
==26552== newSuperblock's request for 4194304 bytes failed.
==26552== 43847680 bytes have already been allocated.
==26552== Valgrind cannot continue. Sorry.
==26552==
==26552== There are several possible reasons for this.
==26552== - You have some kind of memory limit in place. Look at the
==26552== output of 'ulimit -a'. Is there a limit on the size of
==26552== virtual memory or address space?
==26552== - You have run out of swap space.
==26552== - Valgrind has a bug. If you think this is the case or you are
==26552== not sure, please let us know and we'll try to fix it.
==26552== Please note that programs can take substantially more memory than
==26552== normal when running under Valgrind tools, eg. up to twice or
==26552== more, depending on the tool. On a 64-bit machine, Valgrind
==26552== should be able to make use of up 32GB memory. On a 32-bit
==26552== machine, Valgrind should be able to use all the memory available
==26552== to a single process, up to 4GB if that's how you have your
==26552== kernel configured. Most 32-bit Linux setups allow a maximum of
==26552== 3GB per process.
==26552==
==26552== Whatever the reason, Valgrind cannot continue. Sorry.
# ls -lZ /usr/bin/valgrind
-rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/bin/valgrind
On rhel 6 valgrind has execmem_exec_t context, this does not work on rhel7 for some reason.
(In reply to Miroslav Grepl from comment #2)
> So you are reporting we don't have execmem_exec_t label in RHEL7. This is
> expected in RHEL7.
Does that mean that under RHEL7 there is nothing special valgrind has to do for selinux to be able to use writable executable segments (which it needs for the generated code)?