full-disclosure - Re: 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: <20050225144131.GA16068@positron.jfet.org>
From: rsw at jfet.org (Riad S. Wahby)
Subject: Re: Xfree86 video buffering?

James Tucker <jftucker@...il.com> wrote:
> Is it not possible to switch processing modes without switching video modes?
> Could a fast(er) operation, such as a blank intermediate pallete be
> loaded to 'wash out' all coloured pixels on the screen?

It seems like worrying about this at startup is the wrong approach. If
I'm looking at a root prompt in X, I'm already trusting the entire video
infrastructure (card, driver, &c) to be secure to whatever extent I
require.  If my driver/card combo has this problem with failing to
explicitly clear video memory at shutdown, and if my solution is to make
sure that the video driver clears the buffer at _startup_, then I'm also
implicitly trusting the next piece of software that's going to touch
that particular framebuffer not to read it out and send it off to
{insert favorite TLA here}.

Why extend your trust to a driver over which you perhaps have no
control?  The driver that is displaying the sensitive data should have
the responsibility of clearing same from the video card's memory.  Any
other solution is only a quick hack; it'll prevent a casual observer
from seeing anything sensitive, but not a dedicated adversary.

-- 
Riad S. Wahby
rsw@...t.org