linux-kernel - Re: broken device locking, sg vs. sg

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070330191038.067c346b@the-village.bc.nu>
Date:	Fri, 30 Mar 2007 19:10:38 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Eduard Bloch <edi@....de>
Cc:	linux-kernel@...r.kernel.org, debburn-devel@...ts.alioth.debian.org
Subject: Re: broken device locking, sg vs. sg_io on block devices

>    If there is a simple way to get the mapping between the sg and sr
>    devices that would be great and almost solve the problems, but I
>    cannot discover a such thing in the kernel.

You can go trying to match bus values but we have SG_IO on /dev/sr. This
is an old known problem with /dev/sg, and it is one reason Jens and co
fixed it with the SG_IO interface.

>  - hald is using O_EXCL already, as wodim does, and this seems to work
>    well as long as they are acting on the same virtual devices.

You might want to try hal polling the master while burning on the slave
and vice versa that also used to cause some systems problems.

>  - of course the hardware does not handle concurent requests, it is
>    designed that way. It is burden of kernel to canalize the access and
>    deal with concurrency issues. Obviously the kernel can and shall not

It's the job of the kernel to serialize requests coming in and it does
that for you both with SCSI and even old IDE. If you ask it to do
something stupid then that becomes the desktops problem.

>    do all the work but at least the basic safety mechanisms must work
>    reliably and currently they don't.

The kernel does not have sufficient information to handle /dev/sg locking
by itself. That is one reason /dev/sg is a privileged interface. It's
designed to let you do anything however crazy you like, as root. If you
do something stupid it breaks. The whole point of /dev/sg is that you can
do anything with it. You shouldn't be using /dev/sg for normal CD burning
applications on 2.6. 

For sane systems use the SG_IO interface on the proper device file. That
also fixes the need for setuid access and the like except when issuing
"dangerous" commands.

Christoph is wrong about one point, the hardware isn't broken, The IDE bus
is merely badly designed in this area. 

HAL breaks systems, it causes some laptops to burn power and on a few
boxes kills your disk performance. It'll also stop a few boxes reading
video-cd disks. Most of that appears to be HAL problems or indirectly
through problems in the locking scheme chosen (O_EXCL not fcntl locks).

The desktop user space should really know what it is doing with the CD
device if it wants to do things like CD burning. If the serial port
people could get this right in 1977 then there is no excuse fo the CD
using people not getting it right in 2007

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/