# neuer kernel -> kein brenn devices mehr

## Stone

hallo.

hab jetzt endlich den 2.6.8-r1 fast so laufen wie es ich will  :Wink: 

mein problem ist jetzt das ich jetzt im k3b keinen brenner mehr habe sondern nur mehr lese laufwerke..

woran könnte das liegen?

danke euch

----------

## ralph

cdrecord will nicht mit dem 2.6.8er wie ich heute zu meinem Leidwesen feststellen musste. Im ebuild steht, dass dieses Problem bald behoben sein wird, aber bis dahin heißt es wohl entweder nicht brennen, oder wieder auf einen 2.6.7er kernel umsteigen.

Edit: Genauer gesagt funktioniert es glaube ich nur nicht als normaler user, als root geht es wohl. Versuch doch mal k3b als root zu starten um zu sehen, ob es dann geht.

----------

## Stone

hm dann werd ich wieder meinen alten 2.6.5er booten und warten bis das behoben wurde.

wird das glaubst du beim r2 schon gelöst sein?

----------

## ralph

Hm, wann das gelöst wird kann ich natürlich nicht sagen, aber wenn die Jungs schon ankündigen, dass sie cdrecord bald patchen werden so das es wieder funktioniert, dann sollte das nicht mehr lange dauern. Du kannst ja mal die releases der cdrtools ein bischen im Auge behalten um zu sehen, wann es soweit ist.

----------

## psyqil

Als root kann man brennen, aber nur Daten-Cds, Audio- und VideoCDs fressen sich sofort in den swap wegen anderer blocksize und 'nem mem leak...ich hab ganz schön blöd geguckt  :Very Happy: 

----------

## leuenberger

Nur nebenbei:

gentoo-dev-sources-2.6.8-r2 ist da. Bin gerade am mergen...

Gruss Reto

----------

## Stone

he super werd ich auch gleich machen.

hätt aber noch eine kleine frage..

wenn ich den 2.6.8ter boote dann wird mir immer gesagt

```
You Passed an undefined mode number
```

das war bei meinen anderen kerneln noch nie. wie genau kann ich das beheben? brauch da ich einen kernel parameter?

----------

## ian!

Dir -r2 behebt das Problem. Siehe auch ChangeLog.

----------

## psyqil

 *Stone wrote:*   

> wenn ich den 2.6.8ter boote dann wird mir immer gesagt
> 
> ```
> You Passed an undefined mode number
> ```
> ...

 Liegt wohl an vesafb-tng, statt vga=741 kannst Du jetzt  video=vesafb:ypan,1280x1024-32@85 angeben...

----------

## ruth

hi,

ja, sowas ist ärgerlich mit dem brennen...

aber da gibt's tatsächlich wohl ein problem:

das da ist der patch:

```

--- linux-2.6.8.1-ck.orig/drivers/block/scsi_ioctl.c   2004-08-19 19:58:28.041430003 +1000

+++ linux-2.6.8.1-ck/drivers/block/scsi_ioctl.c   2004-08-19 19:59:01.705207615 +1000

@@ -193,8 +193,6 @@ static int sg_io(struct file *file, requ

       return -EINVAL;

    if (copy_from_user(cmd, hdr->cmdp, hdr->cmd_len))

       return -EFAULT;

-   if (verify_command(file, cmd))

-      return -EPERM;

 

    /*

     * we'll do that later

```

das ist's eigentlich schon...

nun, auf der lkml liest sich das so (ungefähr):

ist kein kernelbug, sondern ein fix, der folgendes problem behebt:

```

On Llu, 2004-08-16 at 13:38, Marc Ballarin wrote:

> Due to the newly added command filtering, you now need to run cdrecord as

> root. Since cdrecord will drop root privileges before accessing the drive,

> setuid root won't help

cdrecord should be fine. k3b is issuing something not on the filter

list.

> This patch restores the behaviour of previous kernels, security issues included:

Like allowing any user to erase your drive firmware. What you could do

which is much more useful is printk the command byte that gets refused

and see if you can pin down what commands are being blocked that

are needed by K3B 

Alan

```

jaja, man kann also mit dem patch

zitat alan cox (s.o.):

allowing any user to erase your drive firmware

geil oda? *gg*

der fehler liegt _eindeutig_ bei cdrecord...

musste mal gesagt werden... interessant, gell??? *gg*

wie schon von cox erwähnt, sollte man eher schauen, welche syscalls cdrecord / k3 so abfeuern und danach deren bugs beheben...

gruss

rootshell

p.s:

so wie's aussieht könnt ihr auch gleich den nächsten patch vormerken:

```

Hi Andrew,

When using bounce buffers for SG IO commands with unaligned 

buffers in blk rq map user(), we should free the pages from

blk rq unmap user() which calls bio uncopy user() for the 

non-BIO USER MAPPED case. That function failed to free the

pages for write requests.

So we leaked pages and you machine would go OOM. Rebooting 

helped ;-)

This bug was triggered by writing audio CDs (but not on data 

CDs), as the audio frames are not aligned well (2352 bytes),

so the user pages don't just get mapped.

Bug was reported by Mathias Homan and debugged by Chris Mason + me.

(Jens is away.)

Signed-off-by: Kurt Garloff <garloff@suse.de>

 bio.c |   21 +++++++++------------

 1 files changed, 9 insertions(+), 12 deletions(-)

--- linux-2.6.8.x86/fs/bio.c.orig 2004-08-14 07:37:15.000000000 +0200

+++ linux-2.6.8.x86/fs/bio.c 2004-08-17 17:41:52.022012902 +0200

@@ -388,20 +388,17 @@ int bio uncopy user(struct bio *bio)

  struct bio vec *bvec;

  int i, ret = 0;

 

- if (bio data dir(bio) == READ) {

-  char *uaddr = bio->bi private;

-

-    bio for each segment(bvec, bio, i, 0) {

-   char *addr = page address(bvec->bv page);

-

-   if (!ret && copy to user(uaddr, addr, bvec->bv len))

-    ret = -EFAULT;

+ char *uaddr = bio->bi private;

+ 

+   bio for each segment(bvec, bio, i, 0) {

+  char *addr = page address(bvec->bv page);

+  if (bio data dir(bio) == READ && !ret && 

+      copy to user(uaddr, addr, bvec->bv len))

+   ret = -EFAULT;

 

-     free page(bvec->bv page);

-   uaddr += bvec->bv len;

-  }

+    free page(bvec->bv page);

+  uaddr += bvec->bv len;

  }

-

  bio put(bio);

  return ret;

 }

-- 

Kurt Garloff, Director SUSE Labs, Novell

```

speicherleck in 2.6.8.1

wird wahrscheinlich zu 2.6.8.2 führen (!!!)

auf bugs.gentoo.org kann ich jetz leider ned...

```

 Sorry, but bugzilla is currently offline now as we upgrade its hardware. Thanks for using Gentoo!

```

zumindest im Changelog hab ich den aber noch nicht gefunden...

----------

## PrakashP

Neee, der Fehler liegt nicht an cdrecord, sondern an der Offenheit des kernels. Mit dem 2.8.6.1 hat man den zugemacht, darum ging auch nichts mehr. Man kann nun einzelne "sichere Befehle" wiede rfreischalten oder einfach es so machen, wie die kernels vorher.

Man ist erst vor kurzem auf die Idee gekommen, daß man einfach mal die fw überschrieben kann ohne root Rechte, weil der kernel das nciht verhindert.

Jetzt wird überlegt, ob man nicht sowas wie cdrecord in den kernel integrieren soll und nur noch high level Befehle zuläßt...

----------

## ruth

hi,

ja, so kann man das auch sehen... *gg*

das würde aber dann wohl in einem kompletten re-write von cdrecord hinauslaufen, denk ich...

(hab mir die sources noch nicht gegeben... *gg*)

gruss

flo

----------

## hoschi

Eigentlich sollte man CD-Record aus Prinzip nicht mehr benützen, der Entwickler hat definitv den Arsch auf!

Seit der Geschichte auf heise.de mag ich Suse wieder richtig  :Very Happy: 

----------

## AbsturZ

 *hoschi wrote:*   

> Eigentlich sollte man CD-Record aus Prinzip nicht mehr benützen, der Entwickler hat definitv den Arsch auf!
> 
> Seit der Geschichte auf heise.de mag ich Suse wieder richtig 

 

seh ich auch so, aber leider sind die anderen tools imho ein wenig unkomfortabel und cdrecord ist so zur gewohnheit geworden bei mir. ich möchte einfach nicht mehr umsteigen, aber wenn er sich noch mehr so sachen ausdenkt werde ich es wohl doch machen.

btw r2 löst das problem wirklich   :Smile: 

----------

## BlackEye

hm... ich bin irgendwie aus dem Tritt gekommen. Hab mir gerade den mm-sources-2.6.8.1-r4 installiert und hab das gleiche Problem. Also mit dem user kann ich nicht brennen. Liegt das nun am Kernel oder am cdrecord?

app-cdr/cdrtools = 2.01_alpha33

k3b = 0.11.13

Gruß,

Martin

----------

## ruth

hi nochmal,

das problem mit dem kernel 2.6.8.x ist folgendes:

es wurde kürzlich im kernel ein command filter hinzugefügt:

```

static int verify_command(struct file *file, unsigned char *cmd)

```

so in zeile 113 ff.

diese fkt. wird in zeile 196 aufgerufen:

```

   if (copy_from_user(cmd, hdr->cmdp, hdr->cmd_len))

      return -EFAULT;

   if (verify_command(file, cmd))

      return -EPERM;

```

und genau hier liegt der hase im pfeffer:

cdrecord benutzt commands, die eben in verify_command() _nicht_

vorgesehen sind...

der grund für die fkt war, dass zitat alan cox:

```

Like allowing any user to erase your drive firmware. What you could do

which is much more useful is printk the command byte that gets refused

and see if you can pin down what commands are being blocked that

are needed by K3B 

```

ein beliebiger benutzer die firmware deines brenner löschen kann...

das funktionierte eben bis zu dieser version.

danach filtert der kern potentiell gefährliche aufrufe...

die jetztige abhilfe ist eben diese veränderung vorzunehmen:

```

--- linux-2.6.8/drivers/block/scsi_ioctl.c~   2004-08-16 14:16:57.000000000 +0200

+++ linux-2.6.8/drivers/block/scsi_ioctl.c   2004-08-16 14:36:22.562908552 +0200

@@ -196 +196 @@

-   if (verify_command(file, cmd))

+/*   if (verify_command(file, cmd))

@@ -198 +198 @@

-

+*/

```

also einfach verify_command auskommentieren.

danach funktioniert zwar cdrecord wieder, dafür kann man die firmware deines brenners löschen...

für weitere details siehe lkml...

desweiteren ist es anzuraten, mit jetztigen 2.6.8.x kernen _keine_

audio cd's zu brennen.

>>> u.u. reboot erforderlich wegen speicherleck...

für details und patches siehe z.b. hier:

http://kerneltrap.org/node/view/3659

da wird auf das problem eingegangen und ein patch bereitgestellt...

das sollte uns wohl in der vanilla serie bald einen 2.6.8.2 bescheren...

(ziemlich einmalige sache, finde ich...)

so, allle klarheiten beseitigt??? *gg*

gruss

florian

----------

## BlackEye

dank Dir, das war eine klare Aussage die mich wieder auf den Pfad brachte  :Smile: 

Hab die Stelle mal auskommentiert und nun funktioniert es auch schon wieder fast...  :Smile: 

Dann werde ich also mal auf den vanilla umspringen, wenn der 2.6.9 raus ist. Danke!

Gruß,

Martin

----------

