full-disclosure - Xfree86 video buffering?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <200502250805.j1P85Vrs028858@lists.netsys.com>
From: fulldisclosure at wateraxe.demon.nl (Allan)
Subject: Xfree86 video buffering? 

So the RAM should be flushed during shutdown ..
(as early in the shutdown procedure as possible, I'd say).
Trying to do this during the boot sequence is useless. You could make a
special 'bootdisk' that would show you the contents of the videoram. This
would also make it available for longer then the current 1 or 5 second
'flash' ...

Just my 2c

Allan

[quote]

I don't think this is at all easily solvable - when the X server starts up,
the card is probably in console mode using the VGA emulation, which is
pretty brain-dead and doesn't touch much of the card memory (when you have
32M or 64M on-card, that 640x480 gets lonely sitting in the corner).  The X
server first has to pop it into the native NVidia/ATI/whatever graphics mode
(remember, it has to do that *before* it can access the video memory - you
can't get there while still in VGA emulation).  Then it can proceed to clear
out the on-card memory.  Unfortunately, if the X server pauses in between
setting the mode and clearing  the memory, you get to see the uninitialized
(and therefor left-over) buffers.  About the best you can do here is fix the
server to try to not do any time-intensive operations between the mode set
and the clear.

There's multiple reasons why it can even survive a power cycle.  In my case,
I've only been powering off for a few seconds (stupid laptop doesn't have a
MNI Reset button, which would be quite helpful when doing kernel-level
hacking), and the voltage levels in the RAM hadn't decayed all the way to
bit lossage.
It's also quite possible that some video cards are made with static ram
rather than dynamic ram, which greatly increases the chances that the bits
will survive even an extended power-off, and/or the power "off" isn't really
all the way "off" - if the machine supports "suspend to RAM", it may be
keeping a very low trickle of power going to keep the memory from going
poof....

[/quote]