From derek@spider.com Thu, 28 Oct 1999 00:38:33 +0100
Date: Thu, 28 Oct 1999 00:38:33 +0100
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] Updated code available
I've updated the code on www.eyrie.demon.co.uk/derek/dvd/css to include
my current version of the css-auth package. Also in there is the css-cat
program I've been playing with. This should be endian safe. I've done
some optimisations and restructuring of the code, but this is still in
progress.
The css-cat program should have the ability to demux only the stream
that one is interested in (i.e. video/ac3/etc). Unfortunatly at the moment
there is a bug in extracting the ac3 data (however video demux works).
This problem causes the AC3 data to eventually be messed up. So there
are two version of the uncss function in the file - the one that is enabled
simply decrypts every sector without trying to demux various streams.
I've also included a patched version of Aaron's extract_ac3 which can
read from stdin.
My eventual intention is to change the above couple of programs into
a single daemon which one can connect to for decrypted data.
Usage is a follows (read code for more options):
tstdvd /dev/dvd Authorise to disk and
writes "disk-key"
tstdvd /dev/dvd /dvd/video_ts/vts_01_1.vob writes "title-key"
mv title-key title1-key
css-cat /dvd/video_ts/vts_01_1.vob|mpeg2player -vob -na -ns -f -
DF
--
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034
PGP/GnuPG Keys available
From andreas@andreas.org 28 Oct 1999 02:18:15 +0200
Date: 28 Oct 1999 02:18:15 +0200
From: Andreas Bogk andreas@andreas.org
Subject: [Livid-dev] Updated code available
Derek Fawcus < derek@spider.com> writes:
> css-cat /dvd/video_ts/vts_01_1.vob|mpeg2player -vob -na -ns -f -
I thought that you need the logical block numbers in order to do the
CSS decryption. Where do you get it from?
> My eventual intention is to change the above couple of programs into
> a single daemon which one can connect to for decrypted data.
I'm still thinking that all the encryption stuff should be handled in
the DVD driver in the kernel. That would make all of the CSS handling
totally transparent to the user.
Andreas
--
"We should be willing to look at the source code we produce not as the
end product of a more interesting process, but as an artifact in its
own right. It should look good stuck up on the wall."
-- http://www.ftech.net/~honeyg/progstone/progstone.html
From derek@spider.com Thu, 28 Oct 1999 01:21:05 +0100
Date: Thu, 28 Oct 1999 01:21:05 +0100
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] Updated code available
On Wed, Oct 27, 1999 at 07:17:38PM -0500, Ted Milker wrote:
> On Thu, Oct 28, 1999 at 12:38:33AM +0100, Derek Fawcus wrote:
> > tstdvd /dev/dvd Authorise to disk and
> > writes "disk-key"
> > tstdvd /dev/dvd /dvd/video_ts/vts_01_1.vob writes "title-key"
>
> May want to make a note that you have to run this as root. I get an
> ioctl command failed if I try to run it as a normal user.
True - that was a change introduced in Linux 2.2. You need a capability
to do the ioctl(FIBMAP), whereas you don't need it on 2.0. I've been told
(by Alan Cox) that this was added because not all filesystems implement that
ioctl safely. I was intending to make a suid helper which would simply make
the FIBMAP call.
DF
--
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034
PGP/GnuPG Keys available
From derek@spider.com Thu, 28 Oct 1999 01:23:29 +0100
Date: Thu, 28 Oct 1999 01:23:29 +0100
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] Updated code available
On Thu, Oct 28, 1999 at 02:18:15AM +0200, Andreas Bogk wrote:
> Derek Fawcus < derek@spider.com> writes:
>
> > css-cat /dvd/video_ts/vts_01_1.vob|mpeg2player -vob -na -ns -f -
>
> I thought that you need the logical block numbers in order to do the
> CSS decryption. Where do you get it from?
I use ioctl(FIBMAP) to get the LBA for the start of the file. However,
as Ted reminded me, under 2.2.x you need to have a capability (or be root)
to do this.
> > My eventual intention is to change the above couple of programs into
> > a single daemon which one can connect to for decrypted data.
>
> I'm still thinking that all the encryption stuff should be handled in
> the DVD driver in the kernel. That would make all of the CSS handling
> totally transparent to the user.
Fair enougth - we can disagree there. I will make the daemon. I wish
you luck in trying to convince Linus to accept that sort of stuff in the
kernel!
DF
--
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034
PGP/GnuPG Keys available
From derek@spider.com Thu, 28 Oct 1999 01:47:58 +0100
Date: Thu, 28 Oct 1999 01:47:58 +0100
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] Updated code available
On Wed, Oct 27, 1999 at 07:28:47PM -0500, Ted Milker wrote:
> > True - that was a change introduced in Linux 2.2. You need a capability
> > to do the ioctl(FIBMAP), whereas you don't need it on 2.0. I've been told
> > (by Alan Cox) that this was added because not all filesystems implement that
> > ioctl safely. I was intending to make a suid helper which would simply make
> > the FIBMAP call.
>
> Odd thing was that I never had to run 0.1 as root to run tstdvd(on
> 2.2.12).
0.1 didn't include the call to ioctl(FIBMAP). anyway 0.4 only does
it when you include a VOB file name,
> if (!css_decrypttitlekey(title_key, disk_key, &playkeys)) {
>
> to:
>
> if (!css_decrypttitlekey(title_key, disk_key, playkeys)) {
Ta. It was getting late and I couldn't be bothered to look for that.
> How are things going on fixing the sound?
I'm hoping that Aaron can spot that. It's probably just something stupid
I've done.
> It'd be great if I could test this thing out fully.
even now it'll do sound as:
css-cat vobfile|my-extract-ac3 -|ac3dec
it's just that it should be able to do:
css-cat -0 vobfile|ac3dec
but the bug prevents it.
I just did the following before to listen to the whole soundtrack
of a film.
cat /dvd/video_ts/vts_01_[1234].vob|css-cat -v -|mpeg2player -vob -na -ns -f -
> Though I don't get that great a rate, 12 or so fps without DGA and 21 or
> so with.
I currently get 5ish on my winchip3d-200, and 11ish on my k6-2(300). Both
of these are normal 3.3.3 X servers without DGA. I should upgrade to a later
version of the decoder - is 0.6 any faster than the previous version?
One thing I did find was that demuxing the video in css-cat then playing
it with mpeg2player was faster than shoving the whole decrypted vob to the
,peg player. This however may be helped by the fact that I shoved the DVD
drive in my file server and do this from my worstation:
rsh server css-cat -v vobfile|mpeg2player -vob -na -ns -f -
To try this simply swap the names of uncss and Xuncss and rebuild. Note
that when using the proper (buggy) uncss function you have to give command
line switches.
DF
--
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034
PGP/GnuPG Keys available
From axboe@image.dk Thu, 28 Oct 1999 02:56:45 +0200
Date: Thu, 28 Oct 1999 02:56:45 +0200
From: Jens Axboe axboe@image.dk
Subject: [Livid-dev] Updated code available
On Thu, Oct 28 1999, Andreas Bogk wrote:
> I'm still thinking that all the encryption stuff should be handled in
> the DVD driver in the kernel. That would make all of the CSS handling
> totally transparent to the user.
No way that is _ever_ going to happen.
--
* Jens Axboe < axboe@image.dk>
* Linux CD-ROM Maintainer
* http://www.kernel.dk
From derek@spider.com Thu, 28 Oct 1999 02:04:42 +0100
Date: Thu, 28 Oct 1999 02:04:42 +0100
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] Updated code available
On Wed, Oct 27, 1999 at 07:56:53PM -0500, Ted Milker wrote:
>
> Well, I don't know if you should upgrade just yet. that -f - doesn't
> work anymore, so I couldn't get it to take input directly from the
> standard input.
:-) it never did - I added that functionality to my version! I guess
I must have forgotten to send a patch.
> > To try this simply swap the names of uncss and Xuncss and rebuild. Note
> > that when using the proper (buggy) uncss function you have to give command
> > line switches.
>
> I guess I'm not sure what this "uncss and Xuncss" you're talking about
> is.
I mean edit the file css-cat.c, the function that decides when to
decrypt a sector is called un_css(), there is another version immediatly
after it called Xun_css (the buggy version). Simply add an X to the first
function name, remove it from the second and recompile.
DF
--
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034
PGP/GnuPG Keys available
From pvolcko@concentric.net Wed, 27 Oct 1999 22:04:12 -0400 (EDT)
Date: Wed, 27 Oct 1999 22:04:12 -0400 (EDT)
From: pvolcko@concentric.net pvolcko@concentric.net
Subject: [Livid-dev] Updated code available
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> > My eventual intention is to change the above couple of programs into
> > a single daemon which one can connect to for decrypted data.
>
> I'm still thinking that all the encryption stuff should be handled in
> the DVD driver in the kernel. That would make all of the CSS handling
> totally transparent to the user.
>
Nah. that goes beyond the scope of kernel functionality. All that really
belongs in the kernel are the authentication related ioctls, which are going
to be in the next stable version. CSS decryption is a user space problem,
just as IFO parsing, VOB stream handling, decoding, and all the other fun
stuff is. Now, if you want to go any make a kernel module that somehow does
this, so be it, but it really shouldn't be done there (unless you're
interfacing with hardware decoder cards, of course).
For a more practicle reason why this belowngs in user space... Why should a
dvd driver have to look at the data it is reading off the drive and sending
to an application? In order to implement CSS decryption in the kernel the
driver would need to actively look at the data it is shoveling around. This
introduces a few things:
1) More likelihood of bugs and thus system crashes.
2) Decreased performance of the driver in general.
3) For performance enhancement, sections of processor dependent code in an
otherwise platform portable kernel.
A dvd driver is supposed to shovel data from hardware to software without care
for the contents of the data beyond physical parameters such as block size and
sector locations and such.
Also, wouldn't inclusion of CSS decryption in the driver make it increadibly
difficult for a "by the books" licensed player to be okayed for linux?
Putting CSS routines like that at such a low level will make it very easy to
send unencrypted data to unlicensed products (putting the freely available css
code and any personal distaste for licensing, copyright, or patents for the
moment). This would seem to be a direct violation of the CSS NDA terms
(speculation on my part, but a safe speculation).
Paul Volcko
LSDVD
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: PGPEnvelope - http://www.bigfoot.com/~ftobin/resources.html
iD8DBQE4F68fOzc/wrhmP6URAnpMAJ4kcFIBOG5Rl4aQTEHtdWLQNcXPXwCcDr8N
CzVDogEVCQquvkhfmzTlKUM=
=sKYQ
-----END PGP SIGNATURE-----
From scarabaeus@convergence.de Thu, 28 Oct 1999 14:40:23 +0200
Date: Thu, 28 Oct 1999 14:40:23 +0200
From: Christian Wolff scarabaeus@convergence.de
Subject: [Livid-dev] Logical Block access
Derek Fawcus wrote:
> > May want to make a note that you have to run this as root. I get an
> > ioctl command failed if I try to run it as a normal user.
> True - that was a change introduced in Linux 2.2. You need a capabil=
ity
> to do the ioctl(FIBMAP), whereas you don't need it on 2.0. I've been =
told
> (by Alan Cox) that this was added because not all filesystems implement=
that
> ioctl safely. I was intending to make a suid helper which would simply=
make
> the FIBMAP call.
I was stumbling over that one as well. The recommended way to go for
DVD-Video player is to access the disc raw by logical blocks. This way
you also wouldn't need to mount the disc, but you would have to give
'a+r' access to your dvd/cdrom device. Is that disregarded?
Question to the file system experts: What would be the best way to do
so? Access the block device with file-I/O and long seek pointers, or use
ioctls of cdrom.h to read logical blocks (LB's)?
Anyhow, all you have to do is find the LB number of the first LB of
VIDEO_TS/VIDEO_TS.IFO, everything else is indexed as relative LB numbers
from there. Unfortunately, i'm not allowed to tell where in the IFO file
the indices are... Read the UDF specs for more info.
Great work, everyone!
Christian.
-- =
Christian Wolff *196807101035 53=B08'2" N 8=B013'20" E
http://www.scarabaeus.org/ mailto:scarabaeus@scarabaeus.org
check out http://betalounge.com/ http://www.convergence.de
+49-30-4473 6926, Norwegerstr. 5.1, D-10439 Berlin, Germany
PGP Fingerprint:B871 358C 3F10 A5ED C41C B1DB B9F9 3C44/2048
From derek@spider.com Thu, 28 Oct 1999 13:48:23 +0100
Date: Thu, 28 Oct 1999 13:48:23 +0100
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] Re: css-cat question
On Thu, Oct 28, 1999 at 07:24:56AM -0500, Ted Milker wrote:
> >On Thu, Oct 28, 1999 at 07:17:40AM -0500, Ted Milker wrote:
> > > What's it mean when it says, "Shit need key 2" and quits?
> > You're watching a DVD that requires a different player key. This is
> > determined by checking the key against data held on the disk.
> >
> > This DVD is almost certainly one from Warner Brothers.
>
> But I thought one of the big brags of the DeCSS author was that it COULD
> decrypt The Matrix? (that's the movie I got the error from, obviously :)
Yes it does. But as I said when I mentioned that the decss source looked
good, it is source for an old version. i.e. source that only includes one
key, and thus cannot play those W.B. titles.
DF
--
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034
PGP/GnuPG Keys available
From andreas@andreas.org 28 Oct 1999 20:33:54 +0200
Date: 28 Oct 1999 20:33:54 +0200
From: Andreas Bogk andreas@andreas.org
Subject: [Livid-dev] Updated code available
<pvolcko@concentric.net> writes:
> > I'm still thinking that all the encryption stuff should be handled in
> > the DVD driver in the kernel. That would make all of the CSS handling
> > totally transparent to the user.
> Nah. that goes beyond the scope of kernel functionality. All that really
Ok, maybe I should elaborate on why I believe CSS should be in the
kernel. For me, it's mainly an issue of keeping interfaces as simple
and universal as possible. If CSS would happen in the kernel, I could
do stuff like
$ dd if=/dev/dvd of=someimage
or
$ hexedit /mnt/dvd/video_ts/vts_01_1.vob
as I used to do, and that's my main point, with CDs. The fact that you
need the logical block number for CSS is proof enough for me that
we're handling that on the wrong level, this all should happen below
the file system driver.
So CSS is for me part of the "read a block from this device"
functionality, and this happens to reside in the kernel, so from a
software design point of view, it belongs there.
Of course there are valid arguments against putting all kind of stuff
into the kernel just because one could. But I think that this is
clearly a case where we're winning in terms of simplicity and
orthogonality of the kernel interface, and the price is only a few
hundred lines of code.
> to be in the next stable version. CSS decryption is a user space problem,
> just as IFO parsing, VOB stream handling, decoding, and all the other fun
> stuff is. Now, if you want to go any make a kernel module that somehow does
I see big differences between CSS and all the other DVD stuff. CSS is
just about getting at the raw data, not about interpretation of that
data. Imagine for a second a device which stores it's data using
forward error correction, and which leaves decoding of that FEC to
software. Would you place that into the kernel or in userland? Clearly
a kernel issue, no?
> For a more practicle reason why this belowngs in user space... Why should a
> dvd driver have to look at the data it is reading off the drive and sending
> to an application? In order to implement CSS decryption in the kernel the
Because it's encrypted. Same as for IPsec, encrypting filesystems,
etc.
> 1) More likelihood of bugs and thus system crashes.
The code is pretty straightforward. A small risk, I would think.
> 2) Decreased performance of the driver in general.
You're spending more time in the kernel instead of userland, and that
is a valid argument. How valid it is depends on a few measurements to
be made. But you'd have to waste the time for decoding anyways.
> 3) For performance enhancement, sections of processor dependent code in an
> otherwise platform portable kernel.
So? Otherwise you would have a processor dependent userland code on
top of an otherwise portable OS. Not exactly a big win.
> A dvd driver is supposed to shovel data from hardware to software without care
> for the contents of the data beyond physical parameters such as block size and
> sector locations and such.
And open() is supposed to give me the contents of the file without
care for physical parameters such as sector locations, block size and
encryption. A DVD driver is supposed to give me the raw data.
> Also, wouldn't inclusion of CSS decryption in the driver make it increadibly
> difficult for a "by the books" licensed player to be okayed for linux?
That's the only point I'm really worrying about. But Windows allows
access to the unencrypted decoded video streams as well, and this is
using well-documented APIs.
> Putting CSS routines like that at such a low level will make it very easy to
> send unencrypted data to unlicensed products (putting the freely available css
> code and any personal distaste for licensing, copyright, or patents for the
> moment). This would seem to be a direct violation of the CSS NDA terms
> (speculation on my part, but a safe speculation).
Anybody here who has signed the CSS NDA? They wouldn't even send me
the paperwork.
Andreas
P.S.: Sorry for insisting on the topic, but I would *really* like to
be able to use all the existing userland tools on a DVD without having
to patch every single one of them to support CSS. Let me know if I'm
making sense at all, otherwise I'll shut up.
Andreas
--
"We should be willing to look at the source code we produce not as the
end product of a more interesting process, but as an artifact in its
own right. It should look good stuck up on the wall."
-- http://www.ftech.net/~honeyg/progstone/progstone.html
From derek@spider.com Thu, 28 Oct 1999 19:50:28 +0100
Date: Thu, 28 Oct 1999 19:50:28 +0100
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] Updated code available
On Thu, Oct 28, 1999 at 08:33:54PM +0200, Andreas Bogk wrote:
> P.S.: Sorry for insisting on the topic, but I would *really* like to
> be able to use all the existing userland tools on a DVD without having
> to patch every single one of them to support CSS. Let me know if I'm
> making sense at all, otherwise I'll shut up.
As I've said before, if you want that sort of thing then do a loopback
mount from a user mode NFS server. This will do the DVD Video CSS decryption
for you when required. The code you need is in the normal user mode NFS
server and css-cat. Happy hacking.
Note this capability in the kernel (will never happen) only applies when
the DVD oontains a Film.
As things stand I can use all my normal tools (except an editor) on DVD
VOB files now with css-cat as an input filter.
DF
--
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034
PGP/GnuPG Keys available
From andreas@andreas.org 28 Oct 1999 21:30:28 +0200
Date: 28 Oct 1999 21:30:28 +0200
From: Andreas Bogk andreas@andreas.org
Subject: [Livid-dev] Updated code available
Derek Fawcus < derek@spider.com> writes:
> > P.S.: Sorry for insisting on the topic, but I would *really* like to
> > be able to use all the existing userland tools on a DVD without having
> As I've said before, if you want that sort of thing then do a loopback
> mount from a user mode NFS server. This will do the DVD Video CSS decryption
This doesn't solve the problem of accessing the block device directly as in
$ dd if=/dev/dvd of=myimage.udf
But your solution got me thinking. What I really want is not "CSS in
the kernel", but a block device which doesn't bother me with doing the
CSS myself. I was under the impression that putting CSS in the kernel
is the only way of getting the desired effect, but after thinking
about it, that assumption is faulty. From Configure.help:
Network block devices also allows you to run a block-device in
userland (making server and client physically the same computer,
communicating using the loopback network device).
Of course this means additional communication overhead, because the
DVD blocks have to cross the kernel-userland barrier three times
instead of once, but that's the price you pay for non-monolitic
kernels.
This solution also neatly circumvents the licensing problems, since
the program is standalone.
> for you when required. The code you need is in the normal user mode NFS
> server and css-cat. Happy hacking.
I'll try nbd and css-cat. Thanks!
Andreas
--
"We should be willing to look at the source code we produce not as the
end product of a more interesting process, but as an artifact in its
own right. It should look good stuck up on the wall."
-- http://www.ftech.net/~honeyg/progstone/progstone.html
From axboe@image.dk Thu, 28 Oct 1999 22:16:35 +0200
Date: Thu, 28 Oct 1999 22:16:35 +0200
From: Jens Axboe axboe@image.dk
Subject: [Livid-dev] Updated code available
On Thu, Oct 28 1999, Andreas Bogk wrote:
> Of course this means additional communication overhead, because the
> DVD blocks have to cross the kernel-userland barrier three times
> instead of once, but that's the price you pay for non-monolitic
> kernels.
Hack the loop back driver to do the work for you, if you want.
Then you won't have to copy the data back and forth between
user and kernel space several times.
--
* Jens Axboe <axboe@image.dk>
* Linux CD-ROM Maintainer
* http://www.kernel.dk
From pvolcko@concentric.net Thu, 28 Oct 1999 16:58:15 -0400 (EDT)
Date: Thu, 28 Oct 1999 16:58:15 -0400 (EDT)
From: pvolcko@concentric.net pvolcko@concentric.net
Subject: [Livid-dev] Updated code available
> I see big differences between CSS and all the other DVD stuff. CSS is
> just about getting at the raw data, not about interpretation of that
> data. Imagine for a second a device which stores it's data using
> forward error correction, and which leaves decoding of that FEC to
> software. Would you place that into the kernel or in userland? Clearly
> a kernel issue, no?
Sure, but the device was storing the data like that, it is a specification of
the device. CSS is not a spec of the device. CSS is an add on only
applicable to DVD-Video discs. Yes you could put CSS into the kernel and have
it work. But to me it seems that since CSS is only applicable to a special
case of the media content it seems inappropriate to put it in the kernel.
Perhaps we should clarify something here... are you talking about putting this
into the official kernel code base or are you talking about a kernel module
that is not part of the code base? If the later I can see the argument for
it more clearly, but putting it in the kernel source tree just doesn't make
much sense. This is no an encrypted filesystem nor and encrypted medium in
and of itself. The necessary hooks to handle it are provided by the kernel
code, but actual decryption stays in user space land. Now, if DVD were
designed to be encrypted and the filesystem on it was an encrypted filesystem
things would be different I'd think. Then it becomes clear that the
encryption and decryption should be implemented in the device or filesystem
driver.
The thing for me is that you can not seperate DVD-Video filesystem from a
standard data DVD file system. They are one and the same. The files are
encrypted and not be the file system. I liken this whole situation more to
the use of PGP or perhaps a userspace disc encryption tool. Since the
filesystem is not the encrypting agent with DVD it follows that handling of
that encryption and decryption should be handled not in the filesystem driver
or the device driver, but in user space.
The interfaces can be very well defined for user space libraries or codecs. I
see no inherent gain in interface definition by putting this into the kernel.
> > For a more practicle reason why this belowngs in user space... Why should a
> > dvd driver have to look at the data it is reading off the drive and sending
> > to an application? In order to implement CSS decryption in the kernel the
>
> Because it's encrypted. Same as for IPsec, encrypting filesystems,
> etc.
My point exactly, this is not an encrypting file system. This is iso9660, UDF,
or MicroUDF-Bridge filesystem... none of which are encrypted. This brings up
another very good point, even if one were tyo put the decryption into the
kernel source, it would more likely go into the filesystem code, not the
device/dvd driver code.
> > 1) More likelihood of bugs and thus system crashes.
>
> The code is pretty straightforward. A small risk, I would think.
It was a weak point, I grant you that. But think of it this way... it does
add complexity to the OS code base. Maybe only a little, but it is some none
the less. That is reason enough to question putting it into the kernel. If
we didn't question it, we would end up with a bloated, highly complex,
unmaintainable attraocity of an OS (perhaps you know of one already?)
> > 2) Decreased performance of the driver in general.
>
> You're spending more time in the kernel instead of userland, and that
> is a valid argument. How valid it is depends on a few measurements to
> be made. But you'd have to waste the time for decoding anyways.
Yes, you have to waste the cycles somewhere, but that isn't a reason to
validate putting it into the kernel. Coupled with the reasons above regarding
non-encrypted data dvds, it seems that putting this into the kernel for either
the device driver or the filesystem would create at least some overhead for
reading data that was not encrypted. The overhead might be small, but it is
there. That to me is enough reason for keeping it out of the drivers or
filesystem code.
> > 3) For performance enhancement, sections of processor dependent code in an
> > otherwise platform portable kernel.
>
> So? Otherwise you would have a processor dependent userland code on
> top of an otherwise portable OS. Not exactly a big win.
Not a big win for those using the features provided, could be less accepted
among those who actually maintain it across all the platforms that linux runs
on now and in the future, though. Again we see the added complexity in the
kernel issue pop up, too. putting it in the kernel simply because it "has to
go somewhere, why not there" is not good enough.
Let em re-emphasize: This is all arguments for keeping it out of the official
kernel source tree. Putting it into a vendor supplied kernel module which is
not part of the offical code base is much more palatable that putting it into
the source tree.
> > A dvd driver is supposed to shovel data from hardware to software without care
> > for the contents of the data beyond physical parameters such as block size and
> > sector locations and such.
>
> And open() is supposed to give me the contents of the file without
> care for physical parameters such as sector locations, block size and
> encryption. A DVD driver is supposed to give me the raw data.
The raw data in this case happens to be encrypted... Just as my financial
spreadsheets on my hard drive are. You wouldn't want me to add
encryption/decryption for my favorite encryption algorithm (which happens to
be seriously flawed and relativley easy to crack, btw) into the kernel code
for the ext2 filesystem or the ATAPI/SCSI hard drive drivers.. would you?
> > Also, wouldn't inclusion of CSS decryption in the driver make it increadibly
> > difficult for a "by the books" licensed player to be okayed for linux?
>
> That's the only point I'm really worrying about. But Windows allows
> access to the unencrypted decoded video streams as well, and this is
> using well-documented APIs.
Well, it wasn't easy? I've only heard of one ripper that does this, all the
others (before DeCSS) accomplished this through grabbing the output frames and
putting them in a different file format (.avi usually). Just because it is
possibel in windows doesn't mean that the dvd industry allowed it to happen or
is really all that pleased with it. Going to them and saying, "We want to
make unencrypted dvd data accessable to everyone on the linux platform" and
citing windows and the ability of a few programs to rip the data somehow as an
argument for it will not fly.
> > Putting CSS routines like that at such a low level will make it very easy to
> > send unencrypted data to unlicensed products (putting the freely available css
> > code and any personal distaste for licensing, copyright, or patents for the
> > moment). This would seem to be a direct violation of the CSS NDA terms
> > (speculation on my part, but a safe speculation).
>
> Anybody here who has signed the CSS NDA? They wouldn't even send me
> the paperwork.
>
> Andreas
>
> P.S.: Sorry for insisting on the topic, but I would *really* like to
> be able to use all the existing userland tools on a DVD without having
> to patch every single one of them to support CSS. Let me know if I'm
> making sense at all, otherwise I'll shut up.
It's an important point and one worth discussing. The only way I can justify
this happening in "kernel space" is to create a kernel module (not part of the
offical kernel source) that piggy backs on the UDF filesystem and is used by a
program to access data specifically on a dvd-video disc ina transparent
manner. Perhaps the module could intercept data in and out of the UDF
filesystem and do on the fly decryption if the media in the drive is
recognized as a DVD-Video disc. Better though, is a module that implements a
stripped down version of UDF and incorporates CSS decryption. This special
module would provide a dvd-video specific filesystem which the dvd-video media
could be mounted with (instead of standard UDF). Or perhaps mounting isn't
necessary and direct block access ioctl calls are made. Again, not
incorportated or part of the kernel source tree, a third party kernel module
only.
Paul Volcko
LSDVD