RE: [Linux-fbdev-devel] Current discussion about the future of free software graphics

RE: [Linux-fbdev-devel] Current discussion about the future of free software graphics

[Sottek, Matthew J]

>It does, or the ioctl must verify the register data, which could require
>about the same amount of code as computing it in the kernel in the first
>place (possibly even more; the problem changes from computing a valid
>combination of register values for a specific requested mode to limiting
>the huge number of register value combinations to those that don't lock
>up the chip or worse). I've pointed this out several times before, but
>nobody has presented a solution yet. Will the userspace code live in a
>daemon that runs as root? Or will only privileged processes be allowed
>to change display properties?

I am in agreement with Michel on this point.
There is a privilege problem.
Either you trust the data coming from user-space to kernel-space
implicitly which means the user-space process now must be privileged,
or you don't trust user-space and you have to re-validate the data coming
into the kernel.
The former doesn't buy you much. Now you have another root running deamon
floating around to be a security problem.
The latter's protocol and re-validation is difficult to the point of being
a complete waste of effort.

I have conceded that I am fine with a user-space mode setting API
as long as there is no imposed user/kernel split. For those who's chips
would require too much code to revalidate, they can just put the whole
mode setting in the kernel. I think we will discover that many of the
more advanced drivers will end up taking this route.

In the end I think this design is more complicated than is necessary. The
end goal should be to minimize privileged code, not just kernel code. When
you go with a split design you are forcing more privileged code than if
all the code lived in the same place.



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: RE: [Linux-fbdev-devel] Current discussion about the future of free software graphics

[Adam Jackson]

On Monday 10 May 2004 19:11, Sottek, Matthew J wrote:
> >It does, or the ioctl must verify the register data, which could require
> >about the same amount of code as computing it in the kernel in the first
> >place (possibly even more; the problem changes from computing a valid
> >combination of register values for a specific requested mode to limiting
> >the huge number of register value combinations to those that don't lock
> >up the chip or worse). I've pointed this out several times before, but
> >nobody has presented a solution yet. Will the userspace code live in a
> >daemon that runs as root? Or will only privileged processes be allowed
> >to change display properties?
>
> I am in agreement with Michel on this point.
> There is a privilege problem.
> Either you trust the data coming from user-space to kernel-space
> implicitly which means the user-space process now must be privileged,
> or you don't trust user-space and you have to re-validate the data coming
> into the kernel.

Close.  You only need to trust the user if the operation could have security 
implications.  If your graphics card can use DMA to write to any point in 
memory, then you need to restrict that operation to root, otherwise a user 
can change the euid of a running process to 0.  Or, the other way around, DMA 
reads could be used to read the shadow password file out of login(8)'s 
memory.

Framebuffer and texture memory don't count as sensitive areas because the user 
can already write whatever he likes to them (perhaps through whatever 
authentication method your graphics system uses).  Likewise mode setting 
isn't sensitive because changing the display mode isn't going to stomp on 
kernel data structures or on the address space of other running processes.

Note that this is security from the kernel's point of view.  How you limit 
access to your display is an orthogonal issue.  X has no concept of 
segmentation, only authorization (modulo the Security extension, which by all 
accounts doesn't work very well anymore...).  Presumably any future system 
will have/want to do authorization at some level, and will face the same 
issues X has now.

> I have conceded that I am fine with a user-space mode setting API
> as long as there is no imposed user/kernel split. For those who's chips
> would require too much code to revalidate, they can just put the whole
> mode setting in the kernel. I think we will discover that many of the
> more advanced drivers will end up taking this route.

Again, mode setting is a usability issue, not a security one.  You can't 
violate the pagetable access control by changing timing settings on the video 
card.  (With the possible exception of IGP-style chips where the framebuffer 
resizes to match the resolution; does this case even happen?  Even in this 
case we could get away with the kernel knowing not to expand the resolution 
beyond a certain number of megapixels, or (speculation) running the 
framebuffer through the AGP aperture instead of directly on core.)

That said, obviously the API is all that matters, and the user-kernel split is 
only mandatory to the extent that the hardware is able to circumvent the MMU 
to violate process separation and kernel protection.  The mechanism _should_ 
be masked behind a library that abstracts away the device and implementation 
details as much as possible so the user (where here "user" equals X11 
Classic, Y-Windows, Mesa Solo, whatever) doesn't have to care, and also so 
each new user doesn't have to write the same code again.

Or am I missing something?

> In the end I think this design is more complicated than is necessary. The
> end goal should be to minimize privileged code, not just kernel code. When
> you go with a split design you are forcing more privileged code than if
> all the code lived in the same place.

I agree with the second sentence, but not the rest.  Consider OpenSSH's 
privsep implementation.  Before, the entire daemon ran as root; now only a 
fraction.  The number of lines of code running in as root (and thus needing 
auditing) was cut by a factor of ten, IIRC.

If anything, proper separation _reduces_ the amount of code that runs in a 
privileged context.  If the hardware details create security-sensitive code 
that has to live in the kernel, then it has to live in the kernel; so be it 
[1].  Putting code where it belongs cannot possibly count as bloat.

- ajax

[1] - For those unfortunate users who can't easily add kernel modules, 
something like the current X mechanism - exclusive mmap() of the hardware by 
a trusted userspace process - will have to suffice.  They might sacrifice 
nice things like safe VT switching etc., but those are not bugs that free 
software developers can fix.  Again, the API is all that matters, if a vendor 
has that they can fill in the implementation.


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Current discussion about the future of free software graphics

[Michel Dänzer]

[ Please remove any subject tags when following up ]

On Tue, 2004-05-11 at 04:20, Adam Jackson wrote:
> 
> You only need to trust the user if the operation could have security 
> implications.

[...]

> mode setting isn't sensitive because changing the display mode isn't going 
> to stomp on kernel data structures or on the address space of other running 
> processes.

You're assuming that the user programs a valid mode, but the proposed
interface allows to program any combination of mode register values, of
which valid modes are probably just a small subset, depending on the
hardware. Combinations outside that set might cause unwanted effects
such as lockups or even hardware damage, which is bad enough IMHO.
System RAM access via DMA probably isn't an issue here with the hardware
I'm familiar with, but it might be with others.


> The mechanism _should_ be masked behind a library that abstracts away 
> the device and implementation details as much as possible so the user 
> (where here "user" equals X11 Classic, Y-Windows, Mesa Solo, whatever) 
> doesn't have to care, and also so each new user doesn't have to write 
> the same code again.

Yes, an ALSA-style model is probably the way to go. I'm just pointing
out that the interface between the library and the kernel probably can't
be simply an unrestricted ioctl to dump a bunch of register values.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer

Re: Re: Current discussion about the future of free software graphics

[Jon Smirl]

If everyone will please read Benh's original post describing this... Ben and I
had been emailing on this topic before he wrote this.

--- Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> I agree with the idea of moving the EDID decoding & mode selection to
> userland. In this regard, though, I beleive we should aim toward some
> simple library that sits with the kernel, eventually distributed with
> the kernel tree, to live in initramfs optionally since it may be
> required to even get a console at boot (which is fine, initramfs is
> available early). The video cards themselves have PCI drivers that can
> "trigger" detection by the library via hotplug, the library could manage
> things like persistent configuration, either separate desktops or
> geometry of a complex desktop, etc... and eventually notification of
> userland clients of mode changes.
> 
> One reason for that is lots of monitors lie about their capabilities in
> their EDID block, so we want "override" files.
> 
> The kernel driver in this case doesn't need to be that much different
> than the current fbdev's though, except that we want to move the HW
> access for graphics commands to the kernel too, which basically turns
> into merging the DRI driver and the fbdev. There is no need, I think, to
> re-invent the wheel from scratch here, it would be a lot more realistic
> to build on top of those existing pieces.

What this is saying is that very early in the boot process the graphics driver
will be initialized. At this point it will generate a hotplug event. This event
will be handled by an app and lib that live in initramfs.  This is not saying
that mode-setting will be delayed until normal user space starts. The initial
hotplug event occurs very early in the boot process, almost as early as the
current device driver based code runs. 

This is very similar to the way udev works. Udev is a user space replacement for
devfs. Instead of having a /dev with 40,000 devices in it, udev builds one on
the fly at each boot with exactly your devices in it. Now that I have used udev
instead of devfs I have to agree that it is a much better solution. In fact the
udev app will run before the mode-setting app since it's the udev app that
creates the devices in /dev now by detecting additions to sysfs. udev FAQ:
http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ
We all know Linux is non-functional without a /dev directory, and now /dev is
being build in user space.

Andrew, akpm, has also explained to me that even the current fbdev is not really
active at boot. Instead those initial printk's are queued until the fbdev driver
initialized and prints them.

So moving mode setting to user space is not the end of the world. Everything
will still work. This is more like a monolithic vs microkernel type of decision.
All of the existing code is going to be reused (if we can figure out the
licenses). I've already built a very messy prototype by moving the existing
fbdev code to user space and it works just fine. I also called another little
app which executed the VBIOS and reset secondary cards at boot via hotplug.

I've convinced myself of the advantages of moving mode setting to user space,
but maybe I've missed something that someone else will point out. But let's look
at this as an engineering problem and try to come up with a robust, efficient solution.

=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2'
http://movies.yahoo.com/showtimes/movie?mid=1808405861 


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Current discussion about the future of free software graphics

[Michel Dänzer]

On Wed, 2004-05-12 at 05:30, Jon Smirl wrote:
> If everyone will please read Benh's original post describing this... Ben and I
> had been emailing on this topic before he wrote this.
> 
> --- Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > I agree with the idea of moving the EDID decoding & mode selection to
> > userland. In this regard, though, I beleive we should aim toward some
> > simple library that sits with the kernel, eventually distributed with
> > the kernel tree, to live in initramfs optionally since it may be
> > required to even get a console at boot (which is fine, initramfs is
> > available early). The video cards themselves have PCI drivers that can
> > "trigger" detection by the library via hotplug, the library could manage
> > things like persistent configuration, either separate desktops or
> > geometry of a complex desktop, etc... and eventually notification of
> > userland clients of mode changes.
> > 
> > One reason for that is lots of monitors lie about their capabilities in
> > their EDID block, so we want "override" files.
> > 
> > The kernel driver in this case doesn't need to be that much different
> > than the current fbdev's though, except that we want to move the HW
> > access for graphics commands to the kernel too, which basically turns
> > into merging the DRI driver and the fbdev. There is no need, I think, to
> > re-invent the wheel from scratch here, it would be a lot more realistic
> > to build on top of those existing pieces.
> 
> What this is saying is that very early in the boot process the graphics driver
> will be initialized. At this point it will generate a hotplug event. This event
> will be handled by an app and lib that live in initramfs.  This is not saying
> that mode-setting will be delayed until normal user space starts.

Sure, because Ben doesn't talk about moving mode-setting to userland at
all AFAICT. :)


> I've already built a very messy prototype by moving the existing fbdev 
> code to user space and it works just fine. 

Maybe if others could play with this prototype...


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
--

Current discussion about the future of free software graphics

[sottek]

Can we wrap this up the discussion and try to get to a consensus on
design requirements? I think most of the opinions are starting to
solidify enough to start hashing out the requirements and actual
design.

Also, we probably want to drop the communication down to just one
list? I think dri-devel seems to have the widest group of subscribers.

To start the ball rolling here is a few requirements that I have. We
can build up the list and veto as needed to try and get to a working 
set.

1: Design must provide a mechanism for basic mode setting in a
device independent manner from an application with user level
permissions. ("Basic" to be defined)
2: Design must provide a mechanism for any number of driver dependent
extensions.
3: Design must provide a mechanism to allow the kernel to draw oops
or console messages to the screen in any mode.
4: Design must insure that user applications may not set the hardware
into an unstable state that could lead to lockup or damage display
devices.
5: Design must incorporate a bi-direction API versioning system. The
application must indicate the API version it is expecting first,
followed by the driver's reply.

And some that may require some discussion:
6: Design must provide a mechnism by which the driver can inform a
user application of acceptable modes that may later be applied to
hardware.
7: Design must provide a mechnism for user level applications to
use rendering features of hardware in a secure manner.
8: Design must provide a mechanism for multi-framebuffer and
multi-display per framebuffer devices to be controlled.



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Current discussion about the future of free software graphics

[James Simmons]

> 1: Design must provide a mechanism for basic mode setting in a
> device independent manner from an application with user level
> permissions. ("Basic" to be defined)

Ug. I see I'm fighting a losing battle but it doesn't matter. I couldn't 
never win this fight. There is MONEY involved here. This is a sure way
to make sure Tungstengraphics has a income coming in. They want a monoply 
on the linux graphics arena then fine they can have it. 




-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Current discussion about the future of free software graphics

[Alan Cox]

On Maw, 2004-05-11 at 20:55, James Simmons wrote:
> Ug. I see I'm fighting a losing battle but it doesn't matter. I couldn't 
> never win this fight. There is MONEY involved here. This is a sure way
> to make sure Tungstengraphics has a income coming in. They want a monoply 
> on the linux graphics arena then fine they can have it. 

Current DRI is certainly a PITA unless you know it well but the kernel
side is quite trivial underneath the macrotrastrophe and preprocessor
abuse. 

Its mappable buffers, queue, interrupt handler, X<->kernel auth mapping,
and thats it

Also I'd note several folks are doing DRI nowday without Tungsten - VIA
did the Savage and VIA drivers, sis6326 is a WIP but its also not
tungsten stuff.




-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--

Re: Current discussion about the future of free software graphics

[Geert Uytterhoeven]

On Tue, 11 May 2004, sottek wrote:
> Also, we probably want to drop the communication down to just one
> list? I think dri-devel seems to have the widest group of subscribers.

I don't think that's a good idea: dri-devel is limited to the platforms that
have a working DRI implementation, while linux-fbdev-devel is also frequented
by people from platforms without DRI.

And there we see a communication problem again: the DRI was started without
talking to fbdev people, IIRC...

Please unite our forces!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Current discussion about the future of free software graphics

[James Simmons]

> I don't think that's a good idea: dri-devel is limited to the platforms that
> have a working DRI implementation, while linux-fbdev-devel is also frequented
> by people from platforms without DRI.
> 
> And there we see a communication problem again: the DRI was started without
> talking to fbdev people, IIRC...
> 
> Please unite our forces!

I agree here. I apologize for my behavior. 



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Current discussion about the future of free software graphics

[Nicolas Souchu]

On Tue, May 11, 2004 at 01:09:48PM -0500, sottek wrote:

[...]

Well said! We are all behind you.

-- 
Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org
http://www.freebsd.org/~nsouch/kgi4BSD


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Current discussion about the future of free software graphics

[Michel Dänzer]

On Tue, 2004-05-11 at 20:09, sottek wrote: 
> Can we wrap this up the discussion and try to get to a consensus on
> design requirements? I think most of the opinions are starting to
> solidify enough to start hashing out the requirements and actual
> design.

I agree, and I like your initial list of requirements.

> Also, we probably want to drop the communication down to just one
> list? I think dri-devel seems to have the widest group of subscribers.

I agree with Geert, that probably doesn't cut it. Maybe start a new list
and widely send out invitations to discuss the design there?


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Current discussion about the future of free software graphics

[Egbert Eich]

sottek writes:
 > Can we wrap this up the discussion and try to get to a consensus on
 > design requirements? I think most of the opinions are starting to
 > solidify enough to start hashing out the requirements and actual
 > design.
 > 
 > Also, we probably want to drop the communication down to just one
 > list? I think dri-devel seems to have the widest group of subscribers.

Well, I would think there are a lot more people who are interested
in this subject than are subscribed on dri-devel. dri-devel really
has a different scope.

 > 4: Design must insure that user applications may not set the hardware
 > into an unstable state that could lead to lockup or damage display
 > devices.

The 'driver' must do mode validation using data supplied by either the 
display itself or the application (you need the second as some display 
devices may  not support sending this data or the data sent is bogus).

Broken video modes usually result from:
1. broken drivers
2. bogus user level configuration/override


Egbert.


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Current discussion about the future of free software graphics

[James Simmons]

> single kernel driver should muck with the hardware directly. However,
> I'd like to point out again that it doesn't follow that the DRM and the
> framebuffer device must merge to a single entity (which 'has to be' the
> DRM if you ask some people, the framebuffer device if you ask
> others...). E.g., they could both use the same mini-driver which deals
> with the hardware. Let's try and keep our minds open to all possible
> solutions.

I agree. The disagreement is about where to put mode setting.
 
> > register values. Finally the plug-in lib would use a private IOCTL to set the
> > state into the video hardware. 
> > 
> > There are numerous pros and cons for both a both schemes. The user space code is
> > swappable, easier to debug, and does not need to be run as root.
> 
> It does, or the ioctl must verify the register data, which could require
> about the same amount of code as computing it in the kernel in the first
> place (possibly even more; the problem changes from computing a valid
> combination of register values for a specific requested mode to limiting
> the huge number of register value combinations to those that don't lock
> up the chip or worse). I've pointed this out several times before, but
> nobody has presented a solution yet. Will the userspace code live in a
> daemon that runs as root? Or will only privileged processes be allowed
> to change display properties?

So in reality having mode switching would be just as expensive in 
userspace as having it in the kernel? 




-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Current discussion about the future of free software graphics

[Michel Dänzer]

[ Apologies for the broad cross-post; I'd like to reach anyone
potentially interested ]


First of all, it should be fairly obvious to anyone that ideally only a
single kernel driver should muck with the hardware directly. However,
I'd like to point out again that it doesn't follow that the DRM and the
framebuffer device must merge to a single entity (which 'has to be' the
DRM if you ask some people, the framebuffer device if you ask
others...). E.g., they could both use the same mini-driver which deals
with the hardware. Let's try and keep our minds open to all possible
solutions.


I'd also like to comment on some points I noticed in the
ksummit-2004-discuss archives:

In http://thunk.org/pipermail/ksummit-2004-discuss/2004-May/000388.html,
Jim Gettys wrote:

> In short, the X server would put a sequence of commands into a piece
> of memory also visible by the graphics card, set up the DMA
> transfer, tell it to go, and then continue setting up a second buffer,
> and call into the UNIX kernel with the transfer address of the
> second buffer, that transfer to be initiated at interrupt time
> when the first buffer's commands had been processed; this then blocked
> the X server, so it had good "interactive" behavior under many
> circumstances.
> 
> It may be that system calls are now cheap enough to do this rather than
> having to do it in user space [...]

Yes, that's basically what the r128 and radeon X drivers do when the DRI
is enabled, and it's considerably faster than direct register banging.


In http://thunk.org/pipermail/ksummit-2004-discuss/2004-May/000391.html,
Jon Smirl wrote:

> The modelines would be passed into the plug-in libs which would turn them into
> register values. Finally the plug-in lib would use a private IOCTL to set the
> state into the video hardware. 
> 
> There are numerous pros and cons for both a both schemes. The user space code is
> swappable, easier to debug, and does not need to be run as root.

It does, or the ioctl must verify the register data, which could require
about the same amount of code as computing it in the kernel in the first
place (possibly even more; the problem changes from computing a valid
combination of register values for a specific requested mode to limiting
the huge number of register value combinations to those that don't lock
up the chip or worse). I've pointed this out several times before, but
nobody has presented a solution yet. Will the userspace code live in a
daemon that runs as root? Or will only privileged processes be allowed
to change display properties?


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3