archive mirror
 help / color / mirror / Atom feed
From: James Simmons <>
To: Petr Vandrovec <>
Cc:, <>
Subject: Re: How is info->cmap supposed to work?
Date: Fri, 25 Jul 2003 01:04:48 +0100 (BST)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> Hi James,
>   I have few problems with understanding how
> info->cmap is supposed to work:

> (1) FBIOGETCMAP calls fb_copy_cmap(&info->cmap, &cmap, 0);
>     Should not it use last argument of '2', as &cmap points
>     to the userspace? It looks to me like that anybody can
>     overwrite kernel currently... Only positive side is that
>     there is no way to control info->cmap contents (see (2)),
>     so you can only crash kernel with random code, you cannot 
>     stuff some malicious code there.

I think I posted something about that some time ago and I didn't here 
anything. Looking at the code I realized that yeap its broke. Its strange
that both fb_set_cmap and fb_copy_cmap can get data from userland. I would
think that we either have fb_set_cmap just set the video hardware or 
have fb_set_cmap be able to grab data from userland and fb_copy_cmap send 
data to userland. 

> (2) FBIOPUTCMAP calls fb_set_cmap, which in turn calls
>     fb_setcolreg. 


>     FBIOGETCMAP copies cmap entries from
>     info->cmap (after fixing (1)). Does it mean that
>     fb_setcolreg has to fill info->cmap itself? 

No. At present all the drivers initialize a default cmap. Then it
doesn't matter which function gets called first. 

> Is not it
>     a bit ugly? And fb_set_cmap documentation is incorrect:
>     kspc == 0 means copy from userspace, while
>     kspc != 0 means copy "local", inside kernel-space. Documentation
>     says that 0 is local, while 1 is get_user.

:-( I have to look to see if that has been around for a while. I have a 
feeling it has been.

> (3) And who is supposed to initialize info->cmap, and to
>     what value? It looks to me like that fbdev driver is
>     supposed to do:
>       memset(&info->cmap, 0, sizeof(info->cmap));
>       fb_alloc_cmap(&info->cmap, 256, 1);
>     Is it right? What about fb_init_cmap() then? And why
>     fbdev has to play with info->cmap, cannot generic
>     layer take a care of this, if all info->cmap accesses
>     go through generic layer, and fbdev driver itself has
>     no need for this field?

The reason for the driver initalizing the default cmap is because 
we don't know how big the actual colormap will be. I don't know if 
the generic method of setting to color map to 2^bpp until above 8 bpp 
mode in which case we only set 16 colors will always work. Perhaps we 
could just set the cmap.len field and have the upper layer just generate 
from that.

  reply	other threads:[~2003-07-24 23:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-21 15:26 Petr Vandrovec
2003-07-25  0:04 ` James Simmons [this message]
2003-07-25  0:09 Petr Vandrovec
2003-07-25  0:36 ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='Re: How is info->cmap supposed to work?' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).