From Warren Lewis: Reading from /proc/acpi/video/GFX0/DD01/state crashes system. Permissions allow this to be done by a non root user. I have set severity High as this at least allows a DOS attack. System is a HP DV9334us with NVIDIA G70 [GeForce Go 7600] video. Version-Release number of selected component (if applicable): kernel-2.6.26.3-29.fc9.x86_64 How reproducible: Always Steps to Reproduce: 1. cat /proc/acpi/video/GFX0/DD01/state Actual results: System crashes (no panic) with screen display distorted. Expected results: No crash. Additional info: This also happens under Knoppix so it's not a Fedora specific problem. I'm reporting it here as I'm running a Fedora kernel and not a vanilla kernel.org one.
Proposed patch: https://bugzilla.redhat.com/show_bug.cgi?id=467952#c4
Please post your updates to this top-level bug instead of bug #467952. Thanks.
To root cause this we'll need the output of the acpidump application from the pmtools package on the affected machine.
(In reply to comment #5) > To root cause this we'll need the output of the acpidump application from the > pmtools package on the affected machine. Warren, please provide us with the output as advised in comment #5. Thanks.
The patch did remove read from other, however it also removed read from user (root). I added S_IRUSR to the modes to correct this. /* 'state' [R/W] */ acpi_video_device_state_fops.write = acpi_video_device_write_state; - entry = proc_create_data("state", S_IFREG | S_IRUGO | S_IWUSR, + entry = proc_create_data("state", S_IFREG | S_IRGRP | S_IRUSR | S_IWUSR, device_dir, &acpi_video_device_state_fops, acpi_driver_data(device)); This seems to work ok.
Created attachment 321185 [details] acpidump output from affected machine.
I made an error on the kernel version I am running, it's 2.6.26.5-45.fc9.x86_64
Right. Reading from state on this machine executes the following code: Method (_DCS, 0, NotSerialized) { TRAP (0x01) If (And (CSTE, 0x01)) { Return (0x1F) } Return (0x1D) } with TRAP being: Method (TRAP, 1, Serialized) { Store (Arg0, SMIF) Store (0x00, TRP0) Return (SMIF) } SMIF is the system management interrupt function, and the write to TRP0 presumably initiates system management mode. At this point the system is now executing BIOS code that's entirely out of our control. On this specific machine, it results in the machine hanging. This is pretty clearly a BIOS bug. I'm not convinced we need to change the default behaviour of the kernel for anyone else.
Flashed latest BIOS from HP (F.2C) problem still happens.
(In reply to comment #10) > Right. Reading from state on this machine executes the following code: > > Method (_DCS, 0, NotSerialized) > { > TRAP (0x01) > If (And (CSTE, 0x01)) > { > Return (0x1F) > } > > Return (0x1D) > } > > with TRAP being: > > Method (TRAP, 1, Serialized) > { > Store (Arg0, SMIF) > Store (0x00, TRP0) > Return (SMIF) > } > > SMIF is the system management interrupt function, and the write to TRP0 > presumably initiates system management mode. At this point the system is now > executing BIOS code that's entirely out of our control. On this specific > machine, it results in the machine hanging. > > This is pretty clearly a BIOS bug. I'm not convinced we need to change the > default behaviour of the kernel for anyone else. Ok, so I guess in this case, restricting the state file from local unprivileged users is the way to go. Are you going to submit the patch upstream? If so, please CC me. Thanks, Eugene
(In reply to comment #12) > (In reply to comment #10) [...] > > SMIF is the system management interrupt function, and the write to TRP0 > > presumably initiates system management mode. At this point the system is now > > executing BIOS code that's entirely out of our control. On this specific > > machine, it results in the machine hanging. > > > > This is pretty clearly a BIOS bug. I'm not convinced we need to change the > > default behaviour of the kernel for anyone else. > > Ok, so I guess in this case, restricting the state file from local unprivileged > users is the way to go. Are you going to submit the patch upstream? If so, > please CC me. Are there other ways to trigger the ACPI methods? I guess changing the permissions for these files would probably break userspace as well? Eugene
Well, it works fine on most systems - it's simply pathologically broken on this one. If we knew what the SMI call actually did then it's possible that we could ensure that it didn't trash the system in the process. I don't think we can risk breaking userspace for the sake of one system with an awkward firmware.
Since it only affects this one system, I'd lean towards not applying this patch and instead trying to find out from HP what this SMI call actually does. There may be some aspect of system state that differs between us and Windows here, and if the firmware assumes that then there's the potential for things to go wrong.
(In reply to comment #15) > Since it only affects this one system, I'd lean towards not applying this patch > and instead trying to find out from HP what this SMI call actually does. There > may be some aspect of system state that differs between us and Windows here, > and if the firmware assumes that then there's the potential for things to go > wrong. Thanks Matthew. As spoken, I'm taking this off-line with Linda.
My machine is a laptop with no untrusted users so it's not a big deal for me however I wonder if this BIOS is modified and used on other HP systems such as desktops or servers as those would be more apt to have more then one user and be at risk from a local user.
(In reply to comment #17) > My machine is a laptop with no untrusted users so it's not a big deal for me > however I wonder if this BIOS is modified and used on other HP systems such as > desktops or servers as those would be more apt to have more then one user and > be at risk from a local user. I have been trying to reach for someone from HP, via HP SSRT and HP Support, for the past few weeks, but no one there seems to want to investigate this. I was told by HP that this laptop is not supported in Linux, but they will look to see if this problem affects other HP hardware that they do support in Linux. Unfortunately, I am unable to determine when HP will get back to me wrt issue, but I will keep you posted as soon as I have an update. Thanks Warren.
Warren, just to keep you updated, we have contacted HP. Matthew will be working with them to resolve this after the season holidays. Thanks, Eugene
(In reply to comment #24) > Warren, just to keep you updated, we have contacted HP. Matthew will be working > with them to resolve this after the season holidays. Thanks, Eugene Thanks Eugene.
At this point I would recommend closure of this bug as it is quite old and stale now. It is unlikely that HP will be looking at this BIOS at this point.