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: <9e4733910705220727t605f2522tc4eb97257735c0fb@mail.gmail.com>
Date:	Tue, 22 May 2007 10:27:51 -0400
From:	"Jon Smirl" <jonsmirl@...il.com>
To:	"Jesse Barnes" <jbarnes@...tuousgeek.org>
Cc:	"Jeff Garzik" <jeff@...zik.org>,
	"Jesse Barnes" <jesse.barnes@...el.com>,
	linux-kernel@...r.kernel.org,
	"Antonino A. Daplas" <adaplas@...il.com>
Subject: Re: [RFC] enhancing the kernel's graphics subsystem

On 5/21/07, Jesse Barnes <jbarnes@...tuousgeek.org> wrote:
> Jon, that's why I'm posting this stuff in the first place! :)  Again, if
> you have specific problems with the proposed interfaces (problems that
> would preclude your wishlist from being fully implementable), please let
> me know (preferably with specifics).

A simple place to start is OOPS display while in graphics mode. If we
going to tear up the kernel graphics system this is something that
needs to be fixed.

I don't think it is safe for the OOPS code to attempt a mode change to
text mode when the OOPS happens. The OOPS could have happened in a 3D
driver and left the GPU messed up. The safest thing to do is to
display the OOPS using the mode that is already set.

This implies that the kernel driver needs to track the dimensions and
location of the framebuffer and whether it is in text/graphics mode
(this hasn't been possible before because X never tells the kernel
what mode it is setting). You also need to bring in the bitmap copy
code and fonts over from fbdev. When the OOPS happens you use this
info to paint the OOPS onto the screen. The code from fbdev will let
you display text in graphics mode entirely in kernel context. The
driver should also attempt to stop the GPU to try and make sure it
doesn't erase the OOPS display.

Another simple thing that needs to be built is a mechanism to run the
VBIOS in x86 mode when the driver is first loaded. This can be
achieved by using call_usermode helper to trigger an external app. You
also need to get the x86 emulator working so that this will work on
non-x86 platforms (benh has already done this). I've aput the hooks
into place to give you access to the VBIOS from sysfs. This app is a
prime candidate for klibc. This app is strongly coupled to the problem
of VGA arbitration.

Could we try and work out a solution to these two problems? If we can
solve these they will provide a foundation for fixing the harder ones.

-- 
Jon Smirl
jonsmirl@...il.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ