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: <421F48EE.9060608@sdf.lonestar.org>
From: bkfsec at sdf.lonestar.org (bkfsec)
Subject: Xfree86 video buffering?

Valdis.Kletnieks@...edu wrote:

>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.
>
>  
>
Just a thought here... don't know if there are any complications with my 
suggestion here, but -- why not go the other route and clear the video 
memory as X is shutting down, such that there's no stale data left in 
the buffers?

          -Barry