On Thu, 2005-08-04 at 00:44 +0100, Dave Airlie wrote:
> > restricted to the first process that opens the DRM device. Of couse
> > that process may not be an Xserver.
> >
> > Can people add notes about possible security problems with each of these?
> >
>
> You've missed all the driver ioctls.. plea
Hi Ian,
Your patch does fix build problems and the bug I have previously seen,
however there is a new issue where glxgears segfaults in different place:
#0 0x in ?? ()
#1 0xb7ba4947 in execute_list (ctx=0x806b290, list=145) at
main/dlist.c:6420
#2 0xb7ba5102 in _mesa_CallList (
Root IOCTLs used by my first test program.
--
Jon Smirl
[EMAIL PROTECTED]
diff --git a/linux-core/drm_drv.c b/linux-core/drm_drv.c
--- a/linux-core/drm_drv.c
+++ b/linux-core/drm_drv.c
@@ -65,36 +65,36 @@ drm_ioctl_desc_t drm_ioctls[] = {
[DRM_IOCTL_NR(DRM_IOCTL_GET_MAP)] = {drm_getmap,
On 8/3/05, Ian Romanick <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jon Smirl wrote:
> > On 8/3/05, Dave Airlie <[EMAIL PROTECTED]> wrote:
> >
> >>I'm not over-the-moon about this approach of changing the system to be
> >>default allow anything and adding root
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jon Smirl wrote:
> On 8/3/05, Dave Airlie <[EMAIL PROTECTED]> wrote:
>
>>I'm not over-the-moon about this approach of changing the system to be
>>default allow anything and adding root checks, I'd rather it was default
>>root check and overrideable to
On 8/3/05, Dave Airlie <[EMAIL PROTECTED]> wrote:
> > restricted to the first process that opens the DRM device. Of couse
> > that process may not be an Xserver.
> >
> > Can people add notes about possible security problems with each of these?
> >
>
> You've missed all the driver ioctls.. please m
I've been following the r300 driver development though I've not done
much with it lately, but while trying the latest version that was
merged into the DRI CVS tree I'm unable to successfully start X.
First, the system: it's an Athlon 64 laptop with a 128MB Mobilitiy
Radeon 9700 and 2 GB of RAM, r
> restricted to the first process that opens the DRM device. Of couse
> that process may not be an Xserver.
>
> Can people add notes about possible security problems with each of these?
>
You've missed all the driver ioctls.. please make a list of current driver
ioctls that need root as well..
I'
On Wed, 2005-08-03 at 17:10 -0400, Jon Smirl wrote:
> On 8/3/05, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> > On Wed, 2005-08-03 at 16:18 -0400, Jon Smirl wrote:
> > > On 8/3/05, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > They aren't used in the mesa tree.
> > > >
> > > > So why d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Romanick wrote:
> In addition to my recent commit to Mesa CVS, try this patch. I have
> verified that everything builds and that glxgears works on a system with
> current X.org CVS installed.
This patch *should* fix everything. :) I built it on
Hi all
Building the Mesa tree of a recent checkout, i get those two
"undefined symbols" (_Pos and _Ctx) compiling grammar.c (included in
grammar_mesa.c), lines 597 and 610.
And i found those two symbols nowhere in the whole checkout (xc + drm +
Mesa), and also nowhere in my whole machine
Here are the main IOCTLs that used to require root. Now they are
restricted to the first process that opens the DRM device. Of couse
that process may not be an Xserver.
Can people add notes about possible security problems with each of these?
DRM_IOCTL_IRQ_BUSID
DRM_IOCTL_SET_VERSION
DRM_IOCTL_SE
Alan Cox napsal(a):
drivers/char/drm/gamma_dma.c
drivers/char/drm/gamma_drv.c
Gamma is defunct certainly
Removes gamma sources, headers and pointers from Kconfig and Makefile.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
patch is here (about 70 KiB):
http://www.fi.muni.cz/~xslaby
On 8/3/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-03 at 17:10 -0400, Jon Smirl wrote:
> > On 8/3/05, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> > > On Wed, 2005-08-03 at 16:18 -0400, Jon Smirl wrote:
> > > > On 8/3/05, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > >
New version that protects r128 and radeon IOCTLs with root capablity
check. Please review this patch. We need everyone's eyes to make sure
there are no accidental security holes.
--
Jon Smirl
[EMAIL PROTECTED]
diff --git a/linux-core/drmP.h b/linux-core/drmP.h
--- a/linux-core/drmP.h
+++ b/linu
On 8/3/05, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-03 at 15:02 -0400, Jon Smirl wrote:
> > On 8/3/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> > > On Wed, 2005-08-03 at 14:39 -0400, Jon Smirl wrote:
> > > > > ioctls where removing the root check introduces privelege escalation
>
On 8/3/05, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-03 at 16:18 -0400, Jon Smirl wrote:
> > On 8/3/05, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> > > >
> > > > They aren't used in the mesa tree.
> > >
> > > So why did you change their requiring root?
> >
> > The version of Xegl I
On Wed, 2005-08-03 at 16:18 -0400, Jon Smirl wrote:
> On 8/3/05, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> > >
> > > They aren't used in the mesa tree.
> >
> > So why did you change their requiring root?
>
> The version of Xegl I am making does not run as root. [...]
I know. You missed my quest
On 8/3/05, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-03 at 15:14 -0400, Jon Smirl wrote:
> > On 8/3/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> > >
> > > These are the indirect ioctls, which allow the X Server to submit a
> > > buffer of any commands it wants. You could probably
On Wed, 2005-08-03 at 15:14 -0400, Jon Smirl wrote:
> On 8/3/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> >
> > These are the indirect ioctls, which allow the X Server to submit a
> > buffer of any commands it wants. You could probably build a (or extend
> > the current) verifier for the all the
On 8/3/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-03 at 15:02 -0400, Jon Smirl wrote:
> > On 8/3/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> > > On Wed, 2005-08-03 at 14:39 -0400, Jon Smirl wrote:
> > > > > ioctls where removing the root check introduces privelege escalation
> >
On Wed, 2005-08-03 at 15:02 -0400, Jon Smirl wrote:
> On 8/3/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> > On Wed, 2005-08-03 at 14:39 -0400, Jon Smirl wrote:
> > > > ioctls where removing the root check introduces privelege escalation for
> > > > users with read access to the DRM device (at least
On Wed, 2005-08-03 at 15:02 -0400, Jon Smirl wrote:
> On 8/3/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> > On Wed, 2005-08-03 at 14:39 -0400, Jon Smirl wrote:
> > > > ioctls where removing the root check introduces privelege escalation for
> > > > users with read access to the DRM device (at least
On 8/3/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-03 at 14:39 -0400, Jon Smirl wrote:
> > > ioctls where removing the root check introduces privelege escalation for
> > > users with read access to the DRM device (at least):
> > > - DRM_R128_INDIRECT
> > > - DRM_RADEON_INDIRECT
> >
On Wed, 2005-08-03 at 14:39 -0400, Jon Smirl wrote:
> > ioctls where removing the root check introduces privelege escalation for
> > users with read access to the DRM device (at least):
> > - DRM_R128_INDIRECT
> > - DRM_RADEON_INDIRECT
>
> How do we secure these?
By requiring root. But I didn't
I forgot to add this in the first patch, you will GPF without it. The
attachment includes it.
@@ -72,7 +80,7 @@ static int drm_setup(drm_device_t * dev)
INIT_LIST_HEAD(&dev->ctxlist->head);
dev->vmalist = NULL;
- dev->sigdata.lock = dev->lock.hw_lock = NULL;
+ dev->si
On 8/3/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> > @@ -163,6 +164,19 @@ int drm_addmap(drm_device_t * dev, unsig
> > map->handle = drm_ioremap(map->offset, map->size,
> > dev);
> > break;
> > case _DRM_SHM:
> > + found_map = drm_find_matchin
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=3972
--- Additional Comments From [EMAIL PROTECTED] 2005-08-04 04:34 ---
Creat
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=3972
Summary: [r200 / radeon / r300] segfault in r200DestroyContext
On Wed, 2005-08-03 at 12:58 -0400, Jon Smirl wrote:
> This patch removes the need for root to run DRM. It is attached too in
> case gmail destroys the formatting.
>
> Major highlights:
> 1) removal of the general root check on the IOCTLs, added root check in AddMap
> 1) permanent SAREA map
I like
This patch removes the need for root to run DRM. It is attached too in
case gmail destroys the formatting.
Major highlights:
1) removal of the general root check on the IOCTLs, added root check in AddMap
1) permanent SAREA map
2) user space can AddMap AGP maps, AGP maps are restricted to creation
Ian Romanick wrote (in the GL_ARB_texture_env_crossbar on r200 thread):
> Other optimizations are possible, but I never explored them. Most of
> the ones that I could think of are probably unlikely in practice.
> Doing things like replacing {T1 + T2}, {P + P}, {P + T3} with {T1 +
> T2}*2, {P + T
32 matches
Mail list logo
