Re: CVS Update: drm (branch: trunk)
On Sat, 2005-06-18 at 21:15 -0700, Jon Smirl wrote: > CVSROOT: /cvs/dri > Module name: drm > Repository: drm/shared-core/ > Changes by: [EMAIL PROTECTED] 05/06/18 21:15:58 > > Log message: > Remove I2C support from radeon driver. > Same support is available from radeonfb. > > Modified files: > drm/linux-core/: > Makefile.kernel > drm/shared-core/: > radeon_cp.c radeon_drv.h > Removed files: > drm/linux-core/: > radeon_i2c.c radeon_i2c.h Thank you! -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: snapshot 20050610 [i810]
Hmmm [...huge problems with an i915GM in an Samsung X20 under Xorg 6.8.2 from Mandriva/Mandrake ...] On 6/16/05, Alan Hourihane <[EMAIL PROTECTED]> wrote: > You've picked the wrong snapshot for the i915GM chip. > > You need i915-20050610 instead of i810-20050610. after spending way too much time to get this working under Mandrake / Mandriva LE 2005, I eventually got myself a Suse 9.3. That one supported the (non-accelerated) i915GM out of the box, and after installing the last snapshot of the i915 driver acceleartion seems to work very well. So I guess the problem is with Mandriva's X11 distribution. Apologies for making too much of a fuzz, Christian. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing the root priv requirement from DRM
On Saturday 18 June 2005 15:22, Jon Smirl wrote: > On 6/18/05, Adam Jackson <[EMAIL PROTECTED]> wrote: > > The point to notice here is that these registers generally segmented > > apart in the card's memory map. If all those trigger regs are within a > > single 4k range, then that's the only range you need to hide from > > userspace. > > Then this is a card by card problem. If user space needs to get to the > registers, and we can't split the safe registers from the unsafe > (security issues) ones, then the user space drivers also needs to run > as root. You sound really confused here. Obviously determining which sets of registers can be mapped through the drm is a card-by-card problem. Different cards have different register maps, by definition. But the DRI drivers work as a normal user _right_ _now_, and (modulo mach64 and possibly r300) they seem to be secure. The issue is that drmAddMap, the function that sets up these maps, is currently run from the server during DDX bringup. These maps can just as easily be created during DRM init - and as a design issue, probably _should_ be created there. And if we do that, nothing else in the server-side libdrm API needs to be run as root (that I can see). The client-side API doesn't need root anyway. But please don't add any calls into the server-side API to the loadable driver. I know miniglx did it, but that doesn't mean it's not a bad idea. The server-side API belongs _exclusively_ in the server. > > That's the whole point of the authmagic mechanism. The client gets a > > magic number from the kernel via drmGetMagic, and passes that up to the > > server in the XF86DRIAuthConnection call. The server checks that the > > client is properly authenticated, and tells the DRM to allow that magic > > number full authenticated (but not root-level) DRM access. > > The auth mechanism has an implicit root capability check in it. I want > to remove the need for the server to be root to authorize other users > so I need to remove that check. I also want to assign ownership of the > dri/cardX device to the logged in user. And I'm saying that removing that check looks to be safe to do as long as you're okay with racing to be the first DRI server. > If this check is removed then we have to make sure all of the driver > IOCTLs are safe. Without this check I can just write a normal app that > opens DRM and authenticates itself since the first opener of the DRI > device becomes master. > > This is different than what you are talking about, I don't think you > caught the part about removing the root check on the magic > transaction. No, I got it. My point was that, excluding drmAddMap, the libdrm API that is currently root-only can (AFAICT) be safely run as a user (ie, have the root check removed) without reducing overall system security, as long as you restrict it to the DRI server that currently owns the card. Or, more strongly, to the first DRI server that registers itself, since we currently don't have any logic for supporting multiple DRI servers. - ajax pgpKZMy0ai1W4.pgp Description: PGP signature
Re: root priv and DRM
DRM has the concepts of master and authenticated. In the current code
master is also equated with needing root priv. The patch splits these
two concepts into three (auth, master, root) and makes them separately
controllable.
For example:
[DRM_IOCTL_NR(DRM_IOCTL_ADD_BUFS)] = {drm_addbufs, 1, 1, 1},
needs auth, master, root.
Right now master and root requirements are always set the same. This
new framework lets us check out each call and start removing the root
requirements. The master requirement will always stay as it currently
is.
I always mark the first opener as being master. Just being marked
master doesn't get you the ability to call root priv IOCTLs.
The current DRM code automatically marks all root openers as being
authenticated. I left that in but I am not sure that it should be
there since it will automatically authorize all root users without the
server knowing to track them. I think the intention was just authorize
the first root user.
--
Jon Smirl
[EMAIL PROTECTED]
diff --git a/linux-core/drmP.h b/linux-core/drmP.h
--- a/linux-core/drmP.h
+++ b/linux-core/drmP.h
@@ -278,6 +278,7 @@ typedef int drm_ioctl_t(struct inode *in
typedef struct drm_ioctl_desc {
drm_ioctl_t *func;
int auth_needed;
+ int master_needed;
int root_only;
} drm_ioctl_desc_t;
@@ -373,6 +374,7 @@ typedef struct drm_buf_entry {
/** File private data */
typedef struct drm_file {
int authenticated;
+ int master;
int minor;
pid_t pid;
uid_t uid;
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
@@ -58,67 +58,67 @@ static int drm_version(struct inode *ino
/** Ioctl table */
drm_ioctl_desc_t drm_ioctls[] = {
- [DRM_IOCTL_NR(DRM_IOCTL_VERSION)] = {drm_version, 0, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_GET_UNIQUE)] = {drm_getunique, 0, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_GET_MAGIC)] = {drm_getmagic, 0, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_IRQ_BUSID)] = {drm_irq_by_busid, 0, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_GET_MAP)] = {drm_getmap, 0, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_GET_CLIENT)] = {drm_getclient, 0, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_GET_STATS)] = {drm_getstats, 0, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_SET_VERSION)] = {drm_setversion, 0, 1},
-
- [DRM_IOCTL_NR(DRM_IOCTL_SET_UNIQUE)] = {drm_setunique, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_BLOCK)] = {drm_noop, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_UNBLOCK)] = {drm_noop, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_AUTH_MAGIC)] = {drm_authmagic, 1, 1},
-
- [DRM_IOCTL_NR(DRM_IOCTL_ADD_MAP)] = {drm_addmap_ioctl, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_RM_MAP)] = {drm_rmmap_ioctl, 1, 0},
-
- [DRM_IOCTL_NR(DRM_IOCTL_SET_SAREA_CTX)] = {drm_setsareactx, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_GET_SAREA_CTX)] = {drm_getsareactx, 1, 0},
-
- [DRM_IOCTL_NR(DRM_IOCTL_ADD_CTX)] = {drm_addctx, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_RM_CTX)] = {drm_rmctx, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_MOD_CTX)] = {drm_modctx, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_GET_CTX)] = {drm_getctx, 1, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_SWITCH_CTX)] = {drm_switchctx, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_NEW_CTX)] = {drm_newctx, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_RES_CTX)] = {drm_resctx, 1, 0},
-
- [DRM_IOCTL_NR(DRM_IOCTL_ADD_DRAW)] = {drm_adddraw, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_RM_DRAW)] = {drm_rmdraw, 1, 1},
-
- [DRM_IOCTL_NR(DRM_IOCTL_LOCK)] = {drm_lock, 1, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_UNLOCK)] = {drm_unlock, 1, 0},
-
- [DRM_IOCTL_NR(DRM_IOCTL_FINISH)] = {drm_noop, 1, 0},
-
- [DRM_IOCTL_NR(DRM_IOCTL_ADD_BUFS)] = {drm_addbufs, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_MARK_BUFS)] = {drm_markbufs, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_INFO_BUFS)] = {drm_infobufs, 1, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_MAP_BUFS)] = {drm_mapbufs, 1, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_FREE_BUFS)] = {drm_freebufs, 1, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_VERSION)] = {drm_version, 0, 0, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_GET_UNIQUE)] = {drm_getunique, 0, 0, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_GET_MAGIC)] = {drm_getmagic, 0, 0, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_IRQ_BUSID)] = {drm_irq_by_busid, 0, 1, 1},
+ [DRM_IOCTL_NR(DRM_IOCTL_GET_MAP)] = {drm_getmap, 0, 0, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_GET_CLIENT)] = {drm_getclient, 0, 0, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_GET_STATS)] = {drm_getstats, 0, 0, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_SET_VERSION)] = {drm_setversion, 0, 1, 1},
+
+ [DRM_IOCTL_NR(DRM_IOCTL_SET_UNIQUE)] = {drm_setunique, 1, 1, 1},
+ [DRM_IOCTL_NR(DRM_IOCTL_BLOCK)] = {drm_noop, 1, 1, 1},
+ [DRM_IOCTL_NR(DRM_IOCTL_UNBLOCK)] = {drm_noop, 1, 1, 1},
+ [DRM_IOCTL_NR(DRM_IOCTL_AUTH_MAGIC)] = {drm_authmagic, 1, 1, 1},
+
+ [DRM_IOCTL_NR(DRM_IOCTL_ADD_MAP)] = {drm_addmap_ioctl, 1, 1, 1},
+ [DRM_IOCTL_NR(DRM_IOCTL_RM_MAP)] = {drm_rmmap_ioctl, 1, 0, 0},
+
+ [DRM_IOCTL_NR(DRM
Re: radeon DST_LINE
On 6/18/05, Adam Jackson <[EMAIL PROTECTED]> wrote: > On Saturday 18 June 2005 13:38, Jerome Glisse wrote: > > On 6/18/05, Vladimir Dergachev <[EMAIL PROTECTED]> wrote: > > > On Sat, 18 Jun 2005, Jerome Glisse wrote: > > > > DST_LINE_START 0x1600 > > > > DST_LINE_END 0x1604 > > > > (from radeon fb) > > > > > > From the name, I guess that they initiate line drawing in 2d engine. > > > > I think it's more than that...but i maybe wrong, depending on value i put > > in it the lockup on 9800 can take a bit much time to appear...i haven't > > done statistic on that an thus i could be a feel more than a true a > > reality... > > The DDX uses them for the start and end coordinates of Bresenham lines. I > have trouble believing they could be anything else. Yes it's unrevelent reg for the lockup it was just changing value of a related reg 0x16a0, after hours of writting random things in random place my judgement on the importance of reg is severely impaired... Wonder if the difference we saw after fglrx run isn't due to a packet send to the engine and not to a memory mapped reg... Jerome Glisse --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon DST_LINE
On Sat, 18 Jun 2005, Jerome Glisse wrote: On 6/18/05, Vladimir Dergachev <[EMAIL PROTECTED]> wrote: On Sat, 18 Jun 2005, Jerome Glisse wrote: Hi, Can anyone provide me some informations on : DST_LINE_START 0x1600 DST_LINE_END 0x1604 (from radeon fb) What they are said to do ? End how to setup them. From the name, I guess that they initiate line drawing in 2d engine. I think it's more than that...but i maybe wrong, depending on value i put in it the lockup on 9800 can take a bit much time to appear...i haven't done statistic on that an thus i could be a feel more than a true a reality... AFAIK initiating a 2d command while 3d engine is active should lead to lockup on Radeons. best Vladimir Dergachev Jerome Glisse --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing the root priv requirement from DRM
On Saturday 18 June 2005 21:03, Adam Jackson wrote: > On Saturday 18 June 2005 11:20, Jon Smirl wrote: > > Access to the registers is something that should require root priv > > right? Once I can get to the registers I can program them to contol > > the DMA hardware and then muck with the kernel's memory and escalate > > my priveldge level. EGL avoids this possible hole by not using the > > registers from user space. > > Not all register access should require root. In fact you want to do as much > as possible directly from userspace because shuffling large amounts of data > into the kernel is painful. So what you need to restrict are those registers > which can trigger reads and writes from arbitrary system memory bypassing the > MMU, which basically means anything that can trigger bus-master writes or > DMA. > > The point to notice here is that these registers generally segmented apart in > the card's memory map. If all those trigger regs are within a single 4k > range, then that's the only range you need to hide from userspace. I don't see any reason for mapping registers into userspace in the first place. Except for mode setting and related setup tasks (which aren't exactly performance critical), you'll never want to write to registers directly but go through a DMA'd command stream. Okay, there may be ancient hardware that doesn't support that mode of operation. But why not get rid of register maps completely for everything else? cu, Nicolai pgphGMxZv7NKH.pgp Description: PGP signature
Re: Removing the root priv requirement from DRM
On 6/18/05, Adam Jackson <[EMAIL PROTECTED]> wrote: > On Saturday 18 June 2005 11:20, Jon Smirl wrote: > > Access to the registers is something that should require root priv > > right? Once I can get to the registers I can program them to contol > > the DMA hardware and then muck with the kernel's memory and escalate > > my priveldge level. EGL avoids this possible hole by not using the > > registers from user space. > > Not all register access should require root. In fact you want to do as much > as possible directly from userspace because shuffling large amounts of data > into the kernel is painful. So what you need to restrict are those registers > which can trigger reads and writes from arbitrary system memory bypassing the > MMU, which basically means anything that can trigger bus-master writes or > DMA. > > The point to notice here is that these registers generally segmented apart in > the card's memory map. If all those trigger regs are within a single 4k > range, then that's the only range you need to hide from userspace. Then this is a card by card problem. If user space needs to get to the registers, and we can't split the safe registers from the unsafe (security issues) ones, then the user space drivers also needs to run as root. > EGL really has nothing to do with this, it's entirely a driver issue. I meant my radeon EGL driver. I am modifying it to run without root priv. > > My solution would be to leave the permament maps visible and then add > > a root capability check when someone attempts to drmMap the registers. > > It would more complex to try and hide the map from GetMap. > > That's the whole point of the authmagic mechanism. The client gets a magic > number from the kernel via drmGetMagic, and passes that up to the server in > the XF86DRIAuthConnection call. The server checks that the client is > properly authenticated, and tells the DRM to allow that magic number full > authenticated (but not root-level) DRM access. The auth mechanism has an implicit root capability check in it. I want to remove the need for the server to be root to authorize other users so I need to remove that check. I also want to assign ownership of the dri/cardX device to the logged in user. If this check is removed then we have to make sure all of the driver IOCTLs are safe. Without this check I can just write a normal app that opens DRM and authenticates itself since the first opener of the DRI device becomes master. This is different than what you are talking about, I don't think you caught the part about removing the root check on the magic transaction. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon DST_LINE
On Saturday 18 June 2005 13:38, Jerome Glisse wrote: > On 6/18/05, Vladimir Dergachev <[EMAIL PROTECTED]> wrote: > > On Sat, 18 Jun 2005, Jerome Glisse wrote: > > > DST_LINE_START 0x1600 > > > DST_LINE_END 0x1604 > > > (from radeon fb) > > > > From the name, I guess that they initiate line drawing in 2d engine. > > I think it's more than that...but i maybe wrong, depending on value i put > in it the lockup on 9800 can take a bit much time to appear...i haven't > done statistic on that an thus i could be a feel more than a true a > reality... The DDX uses them for the start and end coordinates of Bresenham lines. I have trouble believing they could be anything else. - ajax pgpLLab0LyiHl.pgp Description: PGP signature
Re: Removing the root priv requirement from DRM
On Saturday 18 June 2005 11:20, Jon Smirl wrote: > Access to the registers is something that should require root priv > right? Once I can get to the registers I can program them to contol > the DMA hardware and then muck with the kernel's memory and escalate > my priveldge level. EGL avoids this possible hole by not using the > registers from user space. Not all register access should require root. In fact you want to do as much as possible directly from userspace because shuffling large amounts of data into the kernel is painful. So what you need to restrict are those registers which can trigger reads and writes from arbitrary system memory bypassing the MMU, which basically means anything that can trigger bus-master writes or DMA. The point to notice here is that these registers generally segmented apart in the card's memory map. If all those trigger regs are within a single 4k range, then that's the only range you need to hide from userspace. EGL really has nothing to do with this, it's entirely a driver issue. > My solution would be to leave the permament maps visible and then add > a root capability check when someone attempts to drmMap the registers. > It would more complex to try and hide the map from GetMap. That's the whole point of the authmagic mechanism. The client gets a magic number from the kernel via drmGetMagic, and passes that up to the server in the XF86DRIAuthConnection call. The server checks that the client is properly authenticated, and tells the DRM to allow that magic number full authenticated (but not root-level) DRM access. The drm API really has three parts: base, authenticated, and master. drmMap is part of the authenticated API, so there's no need to add any additional hiding. Any sensitive register ranges would just be unavailable through drmMap and accessible only from the kernel side, and the safe ranges would only be available after a GetMagic/AuthConnection cycle. > I haven't gotten to where I need to AddMap sarea. Can we prebuild a > permanent map for it too? You could; I'm not sure you want to. In principle it should get charged to the DRM master process. But it's like two pages, not a huge deal either way. > Right now I'm blocked on the AuthMagic call needing root. Of the master-level API, I think only drmAddMap really needs to be restricted to root (to the extent it should exist at all). The rest can be made available to only the first DRM client to start (the server, presumably). I'm not entirely comfortable with that, but I can't completely articulate why yet... - ajax pgpuTXxvkbd7N.pgp Description: PGP signature
[r300/ppc] lockups
Hi, I just tried the latest r300 cvs code (with current mesa cvs, latest Xorg snapshot) but all I get is a lockup as soon as the X server starts. If I have debugging enabled, I get a loop of radeon_do_cp_idle calls. Hardware is: :00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Any idea where I should start looking for the source of the lockups or what else to do? Thanks, johannes signature.asc Description: This is a digitally signed message part
Re: radeon DST_LINE
On 6/18/05, Vladimir Dergachev <[EMAIL PROTECTED]> wrote: > > > On Sat, 18 Jun 2005, Jerome Glisse wrote: > > > Hi, > > > > Can anyone provide me some informations > > on : > > DST_LINE_START 0x1600 > > DST_LINE_END 0x1604 > > (from radeon fb) > > > > What they are said to do ? End how to setup > > them. > > From the name, I guess that they initiate line drawing in 2d engine. I think it's more than that...but i maybe wrong, depending on value i put in it the lockup on 9800 can take a bit much time to appear...i haven't done statistic on that an thus i could be a feel more than a true a reality... Jerome Glisse --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon DST_LINE
On Sat, 18 Jun 2005, Jerome Glisse wrote: Hi, Can anyone provide me some informations on : DST_LINE_START 0x1600 DST_LINE_END 0x1604 (from radeon fb) What they are said to do ? End how to setup them. From the name, I guess that they initiate line drawing in 2d engine. best Vladimir Dergachev Thx a lot. Jerome Glisse --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
radeon DST_LINE
Hi, Can anyone provide me some informations on : DST_LINE_START 0x1600 DST_LINE_END 0x1604 (from radeon fb) What they are said to do ? End how to setup them. Thx a lot. Jerome Glisse --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: root priv and DRM
On 6/17/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
> These are the ones marked root.
>
> [DRM_IOCTL_NR(DRM_IOCTL_IRQ_BUSID)] = {drm_irq_by_busid, 0, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_SET_VERSION)] = {drm_setversion, 0, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_SET_UNIQUE)] = {drm_setunique, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_BLOCK)] = {drm_noop, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_UNBLOCK)] = {drm_noop, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_AUTH_MAGIC)] = {drm_authmagic, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_ADD_MAP)] = {drm_addmap_ioctl, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_SET_SAREA_CTX)] = {drm_setsareactx, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_ADD_CTX)] = {drm_addctx, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_RM_CTX)] = {drm_rmctx, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_MOD_CTX)] = {drm_modctx, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_SWITCH_CTX)] = {drm_switchctx, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_NEW_CTX)] = {drm_newctx, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_ADD_DRAW)] = {drm_adddraw, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_RM_DRAW)] = {drm_rmdraw, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_ADD_BUFS)] = {drm_addbufs, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_MARK_BUFS)] = {drm_markbufs, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_CONTROL)] = {drm_control, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_AGP_ACQUIRE)] = {drm_agp_acquire_ioctl, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_AGP_RELEASE)] = {drm_agp_release_ioctl, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_AGP_ENABLE)] = {drm_agp_enable_ioctl, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_AGP_ALLOC)] = {drm_agp_alloc, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_AGP_FREE)] = {drm_agp_free, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_AGP_BIND)] = {drm_agp_bind, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_AGP_UNBIND)] = {drm_agp_unbind, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_SG_ALLOC)] = {drm_sg_alloc, 1, 1},
> [DRM_IOCTL_NR(DRM_IOCTL_SG_FREE)] = {drm_sg_free, 1, 1},
How about this as a safe first step:
1) Remove the general root capability check
2) Change the semantics of the root_only field on these calls to mean
master only.
3) Push the root capability check into each of these IOCTL individually.
4) Leave a root capability check on the general switch code to per
device IOCTLs if they are marked master only.
The net effect of this should be no change to the security model.
Next we review each IOCTL one at a time and start removing their
individual root capability checks when we decide it is safe. Doing
this may require adjustments to the code to make it work. The root
check stays in until there is agreement on dri-devel that it is ok to
remove.
After the general DRM driver is good repeat the process for the chip
specific ones.
This process is going to cause some churn in the DRM code as the root
capability checks are pushed into the lower levels and then removed.
Is that ok with everyone? I think removing security checks like these
needs to be done as publically as possible.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Removing the root priv requirement from DRM
I moved this to a new thread. I'd also like to ask everyone to help with this. I don't want to accidentally introduce a security hole; the more eyes looking at the code the less likely that will be. On 6/17/05, Adam Jackson <[EMAIL PROTECTED]> wrote: > drmAddMap has to be root-only because it's mapping device memory into > userspace (can trigger bus-master writes, blah blah, root escalation). I > think that's the only one that _really_ needs it, and to be honest those > mappings should get set up from the DRM side anyway and AddMap should just > die. I put code into radeon CVS for something I was calling permanent maps. When the driver loads it uses an internal call, initmap() to preload the maps for framebuffer and the registers. That allows you to avoid the AddMap calls for those two. I believe the via driver has picked up initmap too. Dave says initmap is already in the queue for kernel and should be landing shortly. Access to the registers is something that should require root priv right? Once I can get to the registers I can program them to contol the DMA hardware and then muck with the kernel's memory and escalate my priveldge level. EGL avoids this possible hole by not using the registers from user space. My solution would be to leave the permament maps visible and then add a root capability check when someone attempts to drmMap the registers. It would more complex to try and hide the map from GetMap. I haven't gotten to where I need to AddMap sarea. Can we prebuild a permanent map for it too? Right now I'm blocked on the AuthMagic call needing root. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] suspend/resume and mesa
On 6/18/05, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > > Everyone except for you that I have heard so far has been assuming the > > kernel has some very limited capability to change modes in case things > > go horribly wrong, which OOM killing this hypothetical small daemon > > certainly should qualify as. > > I think all the kernel needs is the capability to restore the card state > to some 'initial' state, either text mode or basic graphic mode as > obtained from the firmware. That is enough for an emergency console. > > I was initially more in favor of an fbdev-type approach, but that was > before I though seriously about all the issues involved, like > arbitration, the gazillion of undocumented tmds/lvds transmitter, DACs, > etc... the mess of getting things like TV out right and more ... > The fbdev interface is just not there and I don't really see ever > getting there. Where are you now on mode list generation and DDC probing? Last year you we in-kernel and I was user space. You wanted in-kernel to get the DDC list to set the initial mode during boot. I wanted user space because there is no way to adjust the DDC via a file in /etc from in-kernel. The DDC code is about 25K. Right now fbdev generates the list in-kernel at boot. I have code that generates an event on monitor change that triggers a user space app. The app reads DDC, merges with the /etc file, and use /sys/class/graphics/fb0/modes to set the new mode list. Changing the mode list generates an fbdev event. fbconsole picks up this event and will search for the nearest mode to what it had and swap to it. Another part of mode setting is restricting the set of modes a normal user can set. This prevents a virus from setting modes that will burn up the monitor. In my scheme (already in the kernel tree) you can cat /sys/class/graphics/fb0/modes to see the mode list. Then echo "mode name from list" >/sys/class/graphics/fb0/mode to set it. fbconsole will pick up the mode change. This model does not prevent user space mode setting code. After the new mode name is in the kernel and checked against the valid mode list, just send it out to call_userhelper(). My code was originally written that way until various people beat it up for out of memory issues, then I reverted to in-kernel. As for arbitrating things, the current X server disables all video cards (expect the ones it is using) on VT swap. That behavior is completely incompatible with mutltiuser use of the other cards. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On 6/18/05, Lorenzo Colitti <[EMAIL PROTECTED]> wrote: > Jon Smirl wrote: > >>When I first boot it's fine, but when the laptop comes back from S3, > >>even if everything else works, the serial console just prints a couple > >>of characters of garbage and then dies. :( > > > > The serial line is probably coming back at the default baud rate and > > you were setting it higher when you were testing it. > > That might be, but this happened both when booting with > "console=ttyS0,115200n8" and with "console=ttyS0", which I assumed > should set it to the default rate. > > I altro tried to see if writing to the port would get it working again, > e.g. as reported here: > > http://www.ussg.iu.edu/hypermail/linux/kernel/0502.0/1030.html > > but that didn't work either. You do get the nice serial console printout at boot right, it's only not working on resume? Ben said he would be back this week. He is the expert on this code. > > > Cheers, > Lorenzo > -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
hu
Hi folks, I installed the r300 driver with X.org and Mesa CVS and it works without problems until now. However, one app called mythtv tries use OpenGL and brought this error: libGL: XF86DRIGetClientDriverName: 4.0.1 r300 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r300_dri.so libGL error: __driCreateScreen() not defined in r300_dri.so! libGL error: unable to find driver: r300_dri.so Any chance to get this fixed? Regards, Tino P.S.: Thanks for the r300 driver, it's great! --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] radeon 9800 lockup : guilty reg list
On 6/18/05, Nicolai Haehnle <[EMAIL PROTECTED]> wrote: > On Saturday 18 June 2005 08:20, Benjamin Herrenschmidt wrote: > > On Fri, 2005-06-17 at 18:37 +0200, Jerome Glisse wrote: > > > Correct value (previous were ones of a dumb test :)): > > > > > > 0x01480xf7fff000 RADEON_MC_FB_LOCATION > > > 0x014c0xfdfffc00 RADEON_MC_AGP_LOCATION > > > > Those look much better. If changing those help for us, then I was right > > saying that our hacks are no good :) More specifically, for r300, for > > some reason, we still put the FB at 0 in card space, which isn't a > > terrific idea, and for both r200 and r300, we incorrectly use > > CONFIG_APER_SIZE for sizing the memory controller apertures instead of > > the actual memory size. > > Consider the following steps: > 1. Load fglrx > 2. Unload fglrx > 3. Load r300 (without reboot) > 4. r300 runs just fine without lockups > > However, r300 obviously overwrites the RADEON_MC_FB/AGP_LOCATION registers. > So while it is obviously a good idea to fix our behaviour here, I'm afraid > it would be highly surprising if those registers were the cause of lockups. Yes if they are in my list this is because the dump i diffed were before the r300 restart anyway after the r300 restart other reg of my list keep their value. Right now i am writting random stuff in random place near unknow reg hopping to see their value change, i only succeed in lockup the computer :( Hope the reg related to the one in my list aren't too far in address space... Jerome Glisse --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
Jon Smirl wrote: When I first boot it's fine, but when the laptop comes back from S3, even if everything else works, the serial console just prints a couple of characters of garbage and then dies. :( The serial line is probably coming back at the default baud rate and you were setting it higher when you were testing it. That might be, but this happened both when booting with "console=ttyS0,115200n8" and with "console=ttyS0", which I assumed should set it to the default rate. I altro tried to see if writing to the port would get it working again, e.g. as reported here: http://www.ussg.iu.edu/hypermail/linux/kernel/0502.0/1030.html but that didn't work either. Cheers, Lorenzo --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
ioctl32 support
Hello, I extracted this patch by Egbert Eich from SuSe's kernel source package: http://www.develer.com/drm-ioctl32.patch It allows running 32bit DRI clients on 64bit systems, which is a very common situation due to proprietary games. Is there a reason why this code is not appropriate for merging into the official DRM? If nobody else is interested, I'd like to try rebasing the patch with the current CVS code. I have near-zero previous experience with it, so I'll probably need help. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] radeon 9800 lockup : guilty reg list
On Saturday 18 June 2005 08:20, Benjamin Herrenschmidt wrote: > On Fri, 2005-06-17 at 18:37 +0200, Jerome Glisse wrote: > > Correct value (previous were ones of a dumb test :)): > > > > 0x01480xf7fff000 RADEON_MC_FB_LOCATION > > 0x014c0xfdfffc00 RADEON_MC_AGP_LOCATION > > Those look much better. If changing those help for us, then I was right > saying that our hacks are no good :) More specifically, for r300, for > some reason, we still put the FB at 0 in card space, which isn't a > terrific idea, and for both r200 and r300, we incorrectly use > CONFIG_APER_SIZE for sizing the memory controller apertures instead of > the actual memory size. Consider the following steps: 1. Load fglrx 2. Unload fglrx 3. Load r300 (without reboot) 4. r300 runs just fine without lockups However, r300 obviously overwrites the RADEON_MC_FB/AGP_LOCATION registers. So while it is obviously a good idea to fix our behaviour here, I'm afraid it would be highly surprising if those registers were the cause of lockups. cu, Nicolai pgp3KX8WbCIEg.pgp Description: PGP signature
