Bug 710711 - vbetool fails to map executable memory
Summary: vbetool fails to map executable memory
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: rawhide
Hardware: i386
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: dracut-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-04 08:07 UTC by mystilleef
Modified: 2012-01-23 09:20 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-23 09:20:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description mystilleef 2011-06-04 08:07:21 UTC
Description of problem:

vbetool fails with the following error:

mmap /dev/zero: Operation not permitted
Failed to initialise LRMI (Linux Real-Mode Interface).

Possibly because systemd or udev mounts /dev with the "noexec" flag option 


Version-Release number of selected component (if applicable):

Installed Packages
Name        : vbetool
Arch        : i686
Version     : 1.2.2
Release     : 1.fc12
Size        : 33 k
Repo        : installed
From repo   : fedora
Summary     : Run real-mode video BIOS code to alter hardware state
URL         : http://www.codon.org.uk/~mjg59/vbetool/
License     : GPLv2
Description : vbetool uses lrmi in order to run code from the video BIOS. Currently, it is
            : able to alter DPMS states, save/restore video card state and attempt to
            : initialize the video card from scratch.

How reproducible:

vbetool dpms off

Steps to Reproduce:
1. install vbetool
2. type vbetool dpms off in a shell terminal
  
Actual results:

mmap /dev/zero: Operation not permitted
Failed to initialise LRMI (Linux Real-Mode Interface).

Expected results:

My monitors turn off.

Comment 1 Bill Nottingham 2011-06-06 18:47:30 UTC
/dev is not noexec for me, FWIW.

udev /dev devtmpfs rw,seclabel,nosuid,relatime,size=3989520k,nr_inodes=997380,mode=755 0 0

Comment 2 Bill Nottingham 2011-06-06 18:48:30 UTC
(Note that my test was on F-15, not rawhide.)

Comment 3 mystilleef 2011-06-06 23:29:59 UTC
Yeah, I didn't have this problem on F-15. Here's my  /etc/mtab on Fedora "rawhide".

rootfs / rootfs rw 0 0
/proc /proc proc rw,relatime 0 0
/sys /sys sysfs rw,relatime 0 0
udev /dev devtmpfs rw,nosuid,noexec,relatime,size=444112k,nr_inodes=111028,mode=755 0 0
devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0
tmpfs /run tmpfs rw,nosuid,nodev,relatime,mode=755 0 0
/dev/sda3 / ext4 rw,noatime,nodiratime,barrier=1,data=ordered 0 0
tmpfs /run tmpfs rw,nosuid,nodev,relatime,mode=755 0 0
tmpfs /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,relatime,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/ns cgroup rw,nosuid,nodev,noexec,relatime,ns 0 0
cgroup /sys/fs/cgroup/cpu cgroup rw,nosuid,nodev,noexec,relatime,cpu 0 0
cgroup /sys/fs/cgroup/cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/bfqio cgroup rw,nosuid,nodev,noexec,relatime,bfqio 0 0
systemd-1 /sys/kernel/debug autofs rw,relatime,fd=29,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
systemd-1 /dev/hugepages autofs rw,relatime,fd=30,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=31,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
systemd-1 /dev/mqueue autofs rw,relatime,fd=32,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
systemd-1 /sys/kernel/security autofs rw,relatime,fd=33,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
tmpfs /media tmpfs rw,nosuid,nodev,noexec,relatime,mode=755 0 0
/dev/sda1 /boot ext4 rw,noatime,nodiratime,barrier=1,data=ordered 0 0
/dev/sda2 /home ext4 rw,noatime,nodiratime,barrier=1,data=ordered 0 0
/dev/sda3 /tmp ext4 rw,noatime,nodiratime,barrier=1,data=ordered 0 0
/dev/sda3 /var/tmp ext4 rw,noatime,nodiratime,barrier=1,data=ordered 0 0
/dev/sda2 /home ext4 rw,noatime,nodiratime,barrier=1,data=ordered 0 0
gvfs-fuse-daemon /home/lateef/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,relatime,user_id=500,group_id=500 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0

Comment 4 Lennart Poettering 2011-06-14 19:38:38 UTC
systemd does not use noexec on /dev.

This sounds more like an SELinux issue to me. Reassigning.

Comment 5 Dominick Grift 2011-06-14 19:53:51 UTC
If this is a selinux issue then: setsebool -P mmap_low_allowed on
should allow it

Comment 6 Daniel Walsh 2011-06-14 20:49:36 UTC
But before you do this, are you sure you need vbetool, most people do not need it and setting mmap_low_allowed is not something we recomment,

yum remove vbetool

If you do not need it.

Comment 7 mystilleef 2011-06-14 22:09:19 UTC
@Dominick Griff: I don't have selinux enabled.

Comment 8 mystilleef 2011-06-14 22:11:34 UTC
@Daniel Walsh: I need vbetool. My graphics card shows a multicolored stripped screen everytime on boot. The only way to get rid of it is to refresh the card using vbetool.

Comment 9 Daniel Walsh 2011-06-15 13:01:00 UTC
Well then not my problem. since SELinux is not enabled.

Comment 10 mystilleef 2011-06-15 13:10:37 UTC
What service on Fedora is responsible for mounting the file system??

Comment 11 Michal Schmidt 2011-06-15 14:38:38 UTC
The initramfs (generated by dracut).

'noexec' on /dev was added by:
http://git.kernel.org/?p=boot/dracut/dracut.git;a=commitdiff;h=dbad9f466157b66762931e0803960140e9e47c3d

Comment 12 Fedora Admin XMLRPC Client 2011-10-20 16:19:01 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.


Note You need to log in before you can comment on or make changes to this bug.