Created attachment 1397381 [details] regression test log Description of problem: Failed regression test during paxtest on a Lenovo model H50-55 with AMD A10-7800 processor. Version-Release number of selected component (if applicable): 4.15.3-300 How reproducible: Run the base regression test {./runtests.sh} Steps to Reproduce: 1.From command line do the following: 2.CD kernel-tests 3.sudo ./runtests.sh Actual results: "Starting test ./default/paxtest Main executable randomisation (PIE) randomness is less than 28 bits (26)" "Failed Tests: ./default/paxtest" Expected results: Pass Additional info: reference bug:1308538
As I recall I think I found a request to reference bug:1308538 in the Linux 4.15.3 Test Day pages. Now as I look at this bug, it is not clear how it applies.
As I reviewed the Fedora QA group Test Day results for Linux 4.15 I see that several of the entries showing AMD processors show this failure.
Sorry, I just read that I should not set the Severity. I apologise for any problem I may have caused. I have set it back to unspecified.
This bug is still present in 4.15.6-300.fc27.x86_64 x86_64
*** Bug 1536864 has been marked as a duplicate of this bug. ***
This bug is still present in 4.15.7-300.fc27.x86_64 x86_64
This bug is still present in 4.15.8-300.fc27.x86_64 x86_64
This bug is still present in 4.15.9-300.fc27.x86_64 x86_64
This bug is still present in 4.15.10-300.fc27.x86_64 x86_64
This bug is still present in 4.15.12-301.fc27.x86_64 x86_64
This bug is still present in 4.15.13-300.fc27.x86_64 x86_64 Starting test ./default/paxtest Main executable randomisation (PIE) randomness is less than 28 bits (25)
This bug is still present in 4.15.14-300.fc27.x86_64 x86_64 Starting test ./default/paxtest Main executable randomisation (PIE) randomness is less than 28 bits (25)
This bug is still present in 4.15.15-300.fc27.x86_64 x86_64 Starting test ./default/paxtest Main executable randomisation (PIE) randomness is less than 28 bits (26)
This bug is still present in 4.15.16-300.fc27.x86_64 x86_64 Starting test ./default/paxtest Main executable randomisation (PIE) randomness is less than 28 bits (25)
This bug is still present in 4.15.17-300.fc27.x86_64 x86_64 Starting test ./default/paxtest Main executable randomisation (PIE) randomness is less than 28 bits (26)
This bug is still present in 4.16.3-200.fc27.x86_64 x86_64 Starting test ./default/paxtest Main executable randomisation (PIE) randomness is less than 28 bits (25)
This bug is still present in 4.16.4-200.fc27.x86_64 x86_64 Starting test ./default/paxtest Main executable randomisation (PIE) randomness is less than 28 bits (26)
This bug is still present in 4.16.5-200.fc27.x86_64 x86_64 Starting test ./default/paxtest Main executable randomisation (PIE) randomness is less than 28 bits (25)
paxtest failed on kernel-4.16.6-302.fc28 and kernel-4.16.7-300.fc28 (Lenovo Thinkpads x220 and x240).
This bug is still present in 4.16.6-200.fc27.x86_64 x86_64 Starting test ./default/paxtest Main executable randomisation (PIE) randomness is less than 28 bits (26)
This bug is still present in 4.16.7-200.fc27.x86_64 x86_64 Starting test ./default/paxtest Main executable randomisation (PIE) randomness is less than 28 bits (25)
This bug is still present in 4.16.9-200.fc27.x86_64 x86_64 Starting test ./default/paxtest Main executable randomisation (PIE) randomness is less than 28 bits (25)
@pmkellly, Can you please try the following command and run the kernel regression test to confirm if paxtest passes: sudo setsebool -P selinuxuser_execheap 0 It appears this is an issue with SELinux and not the kernel. I can confirm this was the solution for me. The following is the SELinux alert message: ---- SELinux is preventing mprotheap from using the execheap access on a process. ***** Plugin allow_execheap (53.1 confidence) suggests ******************** If you do not think mprotheap should need to map heap memory that is both writable and executable. Then you need to report a bug. This is a potentially dangerous access. Do contact your security administrator and report this issue. ***** Plugin catchall_boolean (42.6 confidence) suggests ****************** If you want to allow selinuxuser to execheap Then you must tell SELinux about this by enabling the 'selinuxuser_execheap' boolean. Do setsebool -P selinuxuser_execheap 1 ***** Plugin catchall (5.76 confidence) suggests ************************** If you believe that mprotheap should be allowed execheap access on processes labeled unconfined_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'mprotheap' --raw | audit2allow -M my-mprotheap # semodule -X 300 -i my-mprotheap.pp 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 Unknown [ process ] Source mprotheap Source Path mprotheap Port <Unknown> Host orion Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-283.34.fc27.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name orion Platform Linux orion 4.16.11-200.fc27.x86_64 #1 SMP Tue May 22 18:36:25 UTC 2018 x86_64 x86_64 Alert Count 4 First Seen 2018-05-24 10:13:36 EDT Last Seen 2018-05-25 16:07:50 EDT Local ID 7b010961-5955-4153-b408-c85ffa87daf4 Raw Audit Messages type=AVC msg=audit(1527278870.584:443): avc: denied { execheap } for pid=7083 comm="mprotheap" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 Hash: mprotheap,unconfined_t,unconfined_t,process,execheap ----
In this PC, that boolean was not set to true, but I did the command as suggested and it made no difference in the paxtest result. Here is the text from the terminal screen: [table1pc2@localhost ~]$ getsebool selinuxuser_execheap selinuxuser_execheap --> off [table1pc2@localhost ~]$ sudo setsebool -P selinuxuser_execheap 0 [table1pc2@localhost ~]$ getsebool selinuxuser_execheap selinuxuser_execheap --> off [table1pc2@localhost ~]$ cd kernel-tests [table1pc2@localhost kernel-tests]$ sudo ./runtests.sh Test suite called with default ./default/sysfs-perms PASS ./default/cachedrop PASS ./default/selinux-dac-controls PASS ./default/mq-memory-corruption PASS ./default/timer-overhead PASS ./default/modsign SKIP ./default/insert_leap_second PASS ./default/paxtest FAIL ./default/posix_timers PASS ./default/libhugetlbfs SKIP ./default/stack-randomness PASS ./default/memfd PASS Test suite complete FAIL Your log file is being submitted FAS password: Upload successful!
This bug is still present in 4.16.11-200.fc27.x86_64 x86_64 Starting test ./default/paxtest Main executable randomisation (PIE) randomness is less than 28 bits (26)
This bug is still present in 4.16.12-200.fc27.x86_64 x86_64 Starting test ./default/paxtest Main executable randomisation (PIE) randomness is less than 28 bits (26)
This bug is still present in 4.16.13-200.fc27.x86_64 x86_64 Starting test ./default/paxtest Main executable randomisation (PIE) randomness is less than 28 bits (25)
This bug is still present in 4.16.14-200.fc27.x86_64 x86_64 Starting test ./default/paxtest Main executable randomisation (PIE) randomness is less than 28 bits (25)
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs. Fedora 27 has now been rebased to 4.17.7-100.fc27. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 28, and are still experiencing this issue, please change the version to Fedora 28. If you experience different issues, please open a new bug report for those.
In regard to request for info. I no longer have any machines running F27. They are all on F28 now. This bug continues to exist in F28. I didn't know the protocol, but it seemed best to file a new bug report for that. Please see Bug 1591967. Okay I see now that I should have changed the version in the bug to F28. Sorry for the inconvenience.
*** This bug has been marked as a duplicate of bug 1591967 ***