The BTTV driver 0.7.48 doesn't detect my old Hauppauge card anymore.
The problem seems to be that my card sets PCI_SUBSYSTEM_ID and
PCI_SUBSYSTEM_VENDOR_ID to zero (lspci output below).
In 2.4.0-test10-pre5, the card was correctly detected as a
"Hauppauge old". If I set btv->type to 2 in 2.4.0-test11-pre5, the
card is properly initialized and works.
Not sure what the correct fix is. Maybe to fall back to vendor/device
ID if there's no subsystem information ?
- Werner
---------------------------------- cut here -----------------------------------
# lspci -v -s 00:0f.0
00:0f.0 Multimedia video controller: Brooktree Corporation Bt848 TV with DMA push (rev 12)
Flags: bus master, medium devsel, latency 64, IRQ 9
Memory at eddfe000 (32-bit, prefetchable) [size=4K]
# lspci -x -s 00:0f.0 -n
00:0f.0 Class 0400: 109e:0350 (rev 12)
00: 9e 10 50 03 06 00 80 02 12 00 00 04 00 40 00 00
10: 08 e0 df ed 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 09 01 10 28
--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH [email protected] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
Werner Almesberger wrote:
> The BTTV driver 0.7.48 doesn't detect my old Hauppauge card anymore.
Yes. I've taken out the detection heuristics for bt848 cards. The code
is very old, from the days where only 2-3 different bt848 cards where
available. It simply did'nt work correctly and often used to misdetect
random bt848 cards as either MIRO or Hauppauge (which where the first
available cards).
> The problem seems to be that my card sets PCI_SUBSYSTEM_ID and
> PCI_SUBSYSTEM_VENDOR_ID to zero (lspci output below).
Only bt878 chips have a subsystem ID. The bt848 has not. That's why
there is simply no _reliable_ way to detect bt848 based cards.
Gerd
--
Wirtschaftsinformatiker == Leute, die zwar die aktuellen Aktienkurse
jedes Softwareherstellers kennen, aber keines der Produkte auch nur
ansatzweise bedienen k?nnen. -- Benedict Mangelsdorff
Gerd Knorr wrote:
> It simply did'nt work correctly and often used to misdetect
> random bt848 cards as either MIRO or Hauppauge (which where the first
> available cards).
Well, this means there's yet another mandatory __setup parameter :-(
Should it be called bttv_card or bt484_card (i.e. are there cases
where a user would want to override the card detection for non-848
bttv cards ?)
Likewise, in my radio patch, I called the parameter bt848_radio,
following the naming convention chosen for the config option. If
there are other chips, this may not be a good idea. Should I rename
this one to bttv_radio or are there no radios on non-848 chips ?
(I'll make a patch with both setup functions, since the
documentation changes overlap anyway.)
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH [email protected] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
Werner Almesberger wrote:
> Gerd Knorr wrote:
> > It simply did'nt work correctly and often used to misdetect
> > random bt848 cards as either MIRO or Hauppauge (which where the first
> > available cards).
>
> Well, this means there's yet another mandatory __setup parameter :-(
Why? What is the point in compiling bttv statically into the kernel?
Unlike filesystems/ide/scsi/... you don't need it to get the box up.
No problem to compile the driver as module and configure it with
/etc/modules.conf ...
> Should it be called bttv_card or bt484_card (i.e. are there cases
> where a user would want to override the card detection for non-848
> bttv cards ?)
Yes. Some bt878 cards don't have a ID, and there are a few cases
where different cards have the same subsystem ID.
Gerd
--
Wirtschaftsinformatiker == Leute, die zwar die aktuellen Aktienkurse
jedes Softwareherstellers kennen, aber keines der Produkte auch nur
ansatzweise bedienen k?nnen. -- Benedict Mangelsdorff
Gerd Knorr wrote:
> Why? What is the point in compiling bttv statically into the kernel?
> Unlike filesystems/ide/scsi/... you don't need it to get the box up.
> No problem to compile the driver as module and configure it with
> /etc/modules.conf ...
Huh?
Some systems are built without module support for numerous reasons. I don't
need 50% of the entire kernel to get the box up, but I surely use it and I
don't want 100 modules loaded. There is an introduced security weakness by
using kernels. There are module races. There are ...
So..what is the point in making it modular? ..if it's in use the entire time
the machine is booted?
-d
> > Why? What is the point in compiling bttv statically into the kernel?
> > Unlike filesystems/ide/scsi/... you don't need it to get the box up.
> > No problem to compile the driver as module and configure it with
> > /etc/modules.conf ...
>
> Huh?
>
> Some systems are built without module support for numerous reasons. I don't
> need 50% of the entire kernel to get the box up, but I surely use it and I
> don't want 100 modules loaded.
Why not? /me has nearly everything compiled as modules.
> There is an introduced security weakness by using kernels.
??? Guess you mean "by using modules"? Which weakness? Other than
bugs? I don't see bugs like the recent modprobe oops as major problem.
They happen (everythere), they get fixed.
> So..what is the point in making it modular?
It's much more flexible.
You can reconfigure/update the driver without recompiling the kernel
and without rebooting. If the driver needs some tweaks to make it
work with your hardware you can update /etc/modules.conf and reload
the modules with the new options. If you have found a working
configuration, you can simply leave it as is.
Distributions ship with modularized kernels. Most external drivers
can't be compiled into the kernel (alsa, lirc, vmware, ...). Sometimes
I find it very useful to be able to switch drivers on the fly:
* rmmod ide-cd; modprobe ide-scsi; modprobe sr_mod (for burning CD's)
* /etc/rc.d/init.d/network stop; rmmod de4x5; modprobe tulip;
/etc/rc.d/init.d/network start (tulip manages it to drive the card
full-duplex, de4x5 doesn't).
And I don't like fact that I have to add one more function for every
cmd line option (looks like this from Werner's patch, hav'nt checked).
Some generic way to make module args available as kernel args too
would be nice. Or at least some simple one-liner I could put next to
the MODULE_PARM() macro...
> --------------E48A413646B728A179A7D2FC
> Content-Type: text/x-vcard; charset=us-ascii;
> name="david.vcf"
Please turn this off.
Gerd
On 19 Nov 2000 12:56:17 GMT,
[email protected] (Gerd Knorr) wrote:
>Some generic way to make module args available as kernel args too
>would be nice. Or at least some simple one-liner I could put next to
>the MODULE_PARM() macro...
On my list for 2.5. If foo is declared as MODULE_PARM in object bar
then you will be able to boot with bar.foo=27 or even foo=27 as long as
variable foo is unique amongst all objects in the kernel.
-----BEGIN PGP SIGNED MESSAGE-----
there is a rootkit kernel module out there that, if loaded onto your
system, can make it almost impossible to detect that your system has been
compramised. with module support disabled this isn't possible.
if you have dynamic hardware, then yes it's nice to be able to update
modules and change them on the fly. However for firewalls and routers they
have static configuration and no need to have modules on them (not that
the bttv driver that started this is needed on a router :-)
I frequently build kernels on systems other then the one that will
eventually run it. I like to enable only the fetures needed on the
destination machine. I find it easier to compile a monlithic kernel and
move the one file around then to compile a kernel and modules and move
that set of files around from machine to machine. And no, I can't get the
same result from useing the same kernel loading different modules on each
machine, different CPUs require different optmisations.
the point is that while modules are nice at times and every distribution
ships with modules installed, there are very legitimate reasons why some
people may choose not to use them. The fact that third party binary-only
modules require something doesn't have any weight on any other kernel
decisions, so the fact that they need modules to be enabled shouldn't be
used as a precident to say that other kernel features can be made
module-only.
David Lang
On 19 Nov 2000 [email protected] wrote:
> Date: 19 Nov 2000 12:56:17 GMT
> From: [email protected]
> To: [email protected]
> Newsgroups: lists.linux.kernel
> Subject: Re: BTTV detection broken in 2.4.0-test11-pre5
>
> > > Why? What is the point in compiling bttv statically into the kernel?
> > > Unlike filesystems/ide/scsi/... you don't need it to get the box up.
> > > No problem to compile the driver as module and configure it with
> > > /etc/modules.conf ...
> >
> > Huh?
> >
> > Some systems are built without module support for numerous reasons. I don't
> > need 50% of the entire kernel to get the box up, but I surely use it and I
> > don't want 100 modules loaded.
>
> Why not? /me has nearly everything compiled as modules.
>
> > There is an introduced security weakness by using kernels.
>
> ??? Guess you mean "by using modules"? Which weakness? Other than
> bugs? I don't see bugs like the recent modprobe oops as major problem.
> They happen (everythere), they get fixed.
>
> > So..what is the point in making it modular?
>
> It's much more flexible.
>
> You can reconfigure/update the driver without recompiling the kernel
> and without rebooting. If the driver needs some tweaks to make it
> work with your hardware you can update /etc/modules.conf and reload
> the modules with the new options. If you have found a working
> configuration, you can simply leave it as is.
>
>
> Distributions ship with modularized kernels. Most external drivers
> can't be compiled into the kernel (alsa, lirc, vmware, ...). Sometimes
> I find it very useful to be able to switch drivers on the fly:
>
> * rmmod ide-cd; modprobe ide-scsi; modprobe sr_mod (for burning CD's)
> * /etc/rc.d/init.d/network stop; rmmod de4x5; modprobe tulip;
> /etc/rc.d/init.d/network start (tulip manages it to drive the card
> full-duplex, de4x5 doesn't).
>
>
> And I don't like fact that I have to add one more function for every
> cmd line option (looks like this from Werner's patch, hav'nt checked).
>
> Some generic way to make module args available as kernel args too
> would be nice. Or at least some simple one-liner I could put next to
> the MODULE_PARM() macro...
>
> > --------------E48A413646B728A179A7D2FC
> > Content-Type: text/x-vcard; charset=us-ascii;
> > name="david.vcf"
>
> Please turn this off.
>
> Gerd
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
>
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.2
iQEVAwUBOhfu6z7msCGEppcbAQEDOgf+ICEoB72rzVp0z/9gzalz0ukl+M99BGdD
Q/ssFXB7+OHE+kg7U301gQOxWrcK7gi4wcOT5LYj1iW1c6MNpnA0fB+VZtWGgQ8a
l6/oZf+KXyZcp+8lrKgQVU3FYM8X0o1jhjwANSfveY0Ldy+3sFpH+QKW3p6lCNrv
ayd/GtE6EG9bhEFnLvC7FekWlJuIOmK6T5Sup5T8Z7u8mR0JEU6UjjW89nsYeCAo
l+B5fCPtXM3RPyxqJKgMW9ygMFldb0a6AijmohdFid3QTWpCedxciYzO3cZKP+oU
Cd0uq9dDoMTxA4y3B1oofMjb1VGh0jXDR0F/5ny9GX29JE/96zYWtg==
=65wf
-----END PGP SIGNATURE-----
On Sun, 19 Nov 2000, David Lang wrote:
> there is a rootkit kernel module out there that, if loaded onto your
> system, can make it almost impossible to detect that your system has been
> compramised. with module support disabled this isn't possible.
Yes, it is. Easily. If you've got root you can modify the kernel image and
reboot the bloody thing. And no, marking it immutable will not help. Open
the raw device and modify relevant blocks.
On Sun, 19 Nov 2000 07:16:52 -0800 (PST),
David Lang <[email protected]> wrote:
>there is a rootkit kernel module out there that, if loaded onto your
>system, can make it almost impossible to detect that your system has been
>compramised. with module support disabled this isn't possible.
Wrong. There are ways of attacking the kernel even if you have module
support disabled in the kernel. Disabling modules only makes it a
little harder, do not think for one minute that because you have
disabled modules that you are safe against these root kits, you are
not.
On Sun, 19 Nov 2000, Alexander Viro wrote:
> On Sun, 19 Nov 2000, David Lang wrote:
> > there is a rootkit kernel module out there that, if loaded onto your
> > system, can make it almost impossible to detect that your system has been
> > compramised. with module support disabled this isn't possible.
> Yes, it is. Easily. If you've got root you can modify the kernel image and
> reboot the bloody thing. And no, marking it immutable will not help. Open
> the raw device and modify relevant blocks.
Kernel on writeprotected floppy disk...
-Dan
In article <[email protected]> you write:
>On Sun, 19 Nov 2000, Alexander Viro wrote:
>> On Sun, 19 Nov 2000, David Lang wrote:
>> > there is a rootkit kernel module out there that, if loaded onto your
>> > system, can make it almost impossible to detect that your system has been
>> > compramised. with module support disabled this isn't possible.
>> Yes, it is. Easily. If you've got root you can modify the kernel image and
>> reboot the bloody thing. And no, marking it immutable will not help. Open
>> the raw device and modify relevant blocks.
>
>Kernel on writeprotected floppy disk...
So change the CMOS-settings so that the BIOS changes the boot order
from A, C, CD-ROM to C first instead. *grin* How long do you want
to keep playing Tic-Tac-Toe?
Of course, using capabilities and totally disabling access to the raw
disk devices and to any I/O ports might be the solution, provided that
there are no bugs or thinkos in the capabilities code.
/Christer
--
"Just how much can I get away with and still go to heaven?"
On Sun, 19 Nov 2000, Christer Weinigel wrote:
> In article <[email protected]> you write:
> >On Sun, 19 Nov 2000, Alexander Viro wrote:
> >> On Sun, 19 Nov 2000, David Lang wrote:
> >> > there is a rootkit kernel module out there that, if loaded onto your
> >> > system, can make it almost impossible to detect that your system has been
> >> > compramised. with module support disabled this isn't possible.
> >> Yes, it is. Easily. If you've got root you can modify the kernel image and
> >> reboot the bloody thing. And no, marking it immutable will not help. Open
> >> the raw device and modify relevant blocks.
> >
> >Kernel on writeprotected floppy disk...
Cute. And when (not if) we get hit by new bug in the net/*/* you will drive
to the location of said router to upgrade the thing.
> So change the CMOS-settings so that the BIOS changes the boot order
> from A, C, CD-ROM to C first instead. *grin* How long do you want
> to keep playing Tic-Tac-Toe?
Now, _that_ can be taken care of (custom boot code burnt into the thing)
> Of course, using capabilities and totally disabling access to the raw
> disk devices and to any I/O ports might be the solution, provided that
> there are no bugs or thinkos in the capabilities code.
On Sun, 19 Nov 2000, Christer Weinigel wrote:
> In article <[email protected]> you write:
> >On Sun, 19 Nov 2000, Alexander Viro wrote:
> >> On Sun, 19 Nov 2000, David Lang wrote:
> >> > there is a rootkit kernel module out there that, if loaded onto your
> >> > system, can make it almost impossible to detect that your system has been
> >> > compramised. with module support disabled this isn't possible.
> >> Yes, it is. Easily. If you've got root you can modify the kernel image and
> >> reboot the bloody thing. And no, marking it immutable will not help. Open
> >> the raw device and modify relevant blocks.
> >Kernel on writeprotected floppy disk...
> So change the CMOS-settings so that the BIOS changes the boot order
> from A, C, CD-ROM to C first instead. *grin* How long do you want
> to keep playing Tic-Tac-Toe?
Writeprotect the flashbios with the motherboard jumper, and remove the
cmos battery.
Checkmate. :-)
-Dan
On Sun, 19 Nov 2000, Alexander Viro wrote:
> > >Kernel on writeprotected floppy disk...
> Cute. And when (not if) we get hit by new bug in the net/*/* you will drive
> to the location of said router to upgrade the thing.
No, post/email a floppy to tech who swaps the floppy and reboots router.
-Dan
> Why not? /me has nearly everything compiled as modules.
Some people have extensive sh, awk and sed scripts to manage their systems, some
have compiled programs.
> > There is an introduced security weakness by using kernels.
>
> ??? Guess you mean "by using modules"? Which weakness? Other than
> bugs? I don't see bugs like the recent modprobe oops as major problem.
> They happen (everythere), they get fixed.
If your server has a kernel that doesn't support modules, then a trojan hiding
module can't be used. Modules are easily tampered with and you no more the wise.
> > So..what is the point in making it modular?
>
> It's much more flexible.
>
> You can reconfigure/update the driver without recompiling the kernel
> and without rebooting. If the driver needs some tweaks to make it
> work with your hardware you can update /etc/modules.conf and reload
> the modules with the new options. If you have found a working
> configuration, you can simply leave it as is.
Modules are fantastic for workstations, testbeds, machines that change a lot.
Servers are normally a static configuration. I won't ship a blackbox device to a
customer that allows them to twiddle with things, their curiosity becomes a
maintenance hassle. I have a product in the lab that uses bttv and I'd really
love to be able to compile it into the kernel.
> * rmmod ide-cd; modprobe ide-scsi; modprobe sr_mod (for burning CD's)
> * /etc/rc.d/init.d/network stop; rmmod de4x5; modprobe tulip;
> /etc/rc.d/init.d/network start (tulip manages it to drive the card
> full-duplex, de4x5 doesn't).
Tulip works dandy for me, I have no need of changing it and on a remote server
it's not intelligent to remove your networking support and reload it. The
process may fail and that leaves you dead.
> Please turn this off.
My vcard size is the same or smaller than the average signature. Using mime, you
have the option of easily filtering vcards. Signatures aren't as easily
identified for filtering.
-d
Christer Weinigel wrote:
> >Kernel on writeprotected floppy disk...
>
> So change the CMOS-settings so that the BIOS changes the boot order
> from A, C, CD-ROM to C first instead. *grin* How long do you want
> to keep playing Tic-Tac-Toe?
>
> Of course, using capabilities and totally disabling access to the raw
> disk devices and to any I/O ports might be the solution, provided that
> there are no bugs or thinkos in the capabilities code.
How much time do you want to spend hardening your system? A few simple steps can
make things very hard for a remote attacker.
Everyone wants to decry every tiny little step saying there are a dozen ways to
get around it. But take 12 simple steps to take care of those dozen ways, and
you've upped the bar sufficiently. It will take a much more skilled person to
get past your defenses.
Most exploits depend on a common system layout. I.e. a redhat script issue.
Immediately you have hundreds of thousands of systems around the world which are
probably vulnerable. If however you've only installed 10 megs worth of total
system programs and kernel etc that you've carefully decided are necessary, you
probably don't have those scripts. With this attention to detail, you probably
shut off all those extraneous services like rpc.statd. Chances are you have a
chrooted BIND and on top of that you're running 9.0.1rc2. With all that covered
I'd hazard a guess that your nicely tidied up iptables are preventing access to
anything you're not paying attention to.
Every item you add to this hardening checklist makes your system much less of a
target. First it has less of a signature on a perp's someisp.addresses.com
sweep, and second, once it's found there are less and less available options for
intrusion.
So instead of doing nothing because someone can always infiltrate your system, do
a few somethings so it raises the bar against whomever tries.
Those dozen doors are great for a shopping mall, but bad for a classified room.
-d
> > So change the CMOS-settings so that the BIOS changes the boot order
> > from A, C, CD-ROM to C first instead. *grin* How long do you want
> > to keep playing Tic-Tac-Toe?
>
> Writeprotect the flashbios with the motherboard jumper, and remove the
> cmos battery.
>
> Checkmate. :-)
You can do a live Linux kernel swap without a bios level reboot.
Alan
On Sun, 19 Nov 2000, David Lang wrote:
> there is a rootkit kernel module out there that, if loaded onto your
> system, can make it almost impossible to detect that your system has been
> compramised. with module support disabled this isn't possible.
Wrong. I've seen messages on bugtraq saying it is possible to "load"
modules into the kernel by patching /dev/kmem. Even for loading modules
custom modules the normal way the attacker needs root priviliges (unless
you have a world-writeable /lib/modules...). If this is the case it is
too late anyway...
Gerd
On Mon, 20 Nov 2000, Keith Owens wrote:
> On 19 Nov 2000 12:56:17 GMT,
> [email protected] (Gerd Knorr) wrote:
> >Some generic way to make module args available as kernel args too
> >would be nice. Or at least some simple one-liner I could put next to
> >the MODULE_PARM() macro...
>
> On my list for 2.5. If foo is declared as MODULE_PARM in object bar
> then you will be able to boot with bar.foo=27 or even foo=27 as long as
> variable foo is unique amongst all objects in the kernel.
Cool. Any plans how to handle drivers which are build from multiple
object files like bttv? Think "bar" needs to be configurable handle this
nicely. bttv should have bttv.card=xxx because the module is called
"bttv", but the source file where the card insmod option is declared is
bttv-cards.c ...
Gerd
--
Wirtschaftsinformatiker == Leute, die zwar die aktuellen Aktienkurse
jedes Softwareherstellers kennen, aber keines der Produkte auch nur
ansatzweise bedienen k?nnen. -- Benedict Mangelsdorff
Someone wrote:
> > > So change the CMOS-settings so that the BIOS changes the boot order
> > > from A, C, CD-ROM to C first instead. *grin* How long do you want
> > > to keep playing Tic-Tac-Toe?
> >
> > Writeprotect the flashbios with the motherboard jumper, and remove the
> > cmos battery.
The "writeprotect flashbios" usually only protects the bottom 8k of
the CMOS. That's the part that you still need to boot the system to
reflash it should somehow your flash be nuked.
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
Christer Weinigel wrote:
> In article <[email protected]> you write:
> >On Sun, 19 Nov 2000, Alexander Viro wrote:
> >> On Sun, 19 Nov 2000, David Lang wrote:
> >> > there is a rootkit kernel module out there that, if loaded onto your
> >> > system, can make it almost impossible to detect that your system has been
> >> > compramised. with module support disabled this isn't possible.
> >> Yes, it is. Easily. If you've got root you can modify the kernel image and
> >> reboot the bloody thing. And no, marking it immutable will not help. Open
> >> the raw device and modify relevant blocks.
> >
> >Kernel on writeprotected floppy disk...
>
> So change the CMOS-settings so that the BIOS changes the boot order
> from A, C, CD-ROM to C first instead. *grin* How long do you want
> to keep playing Tic-Tac-Toe?
>
The way we do it is to boot from a CDROM with no onboard hard drive. (logging is
provided by an external server) Beat that.
-b
>
> Of course, using capabilities and totally disabling access to the raw
> disk devices and to any I/O ports might be the solution, provided that
> there are no bugs or thinkos in the capabilities code.
>
> /Christer
> --
> "Just how much can I get away with and still go to heaven?"
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
Alexander Viro wrote:
> On Sun, 19 Nov 2000, Christer Weinigel wrote:
>
> > In article <[email protected]> you write:
> > >On Sun, 19 Nov 2000, Alexander Viro wrote:
> > >> On Sun, 19 Nov 2000, David Lang wrote:
> > >> > there is a rootkit kernel module out there that, if loaded onto your
> > >> > system, can make it almost impossible to detect that your system has been
> > >> > compramised. with module support disabled this isn't possible.
> > >> Yes, it is. Easily. If you've got root you can modify the kernel image and
> > >> reboot the bloody thing. And no, marking it immutable will not help. Open
> > >> the raw device and modify relevant blocks.
> > >
> > >Kernel on writeprotected floppy disk...
>
> Cute. And when (not if) we get hit by new bug in the net/*/* you will drive
> to the location of said router to upgrade the thing.
>
No, I mail the customer a new operating CD.
-b
>
> > So change the CMOS-settings so that the BIOS changes the boot order
> > from A, C, CD-ROM to C first instead. *grin* How long do you want
> > to keep playing Tic-Tac-Toe?
>
> Now, _that_ can be taken care of (custom boot code burnt into the thing)
>
> > Of course, using capabilities and totally disabling access to the raw
> > disk devices and to any I/O ports might be the solution, provided that
> > there are no bugs or thinkos in the capabilities code.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
On Sun, 19 Nov 2000 20:03:52 +0100 (CET),
Gerd Knorr <[email protected]> wrote:
>On Mon, 20 Nov 2000, Keith Owens wrote:
>> On my list for 2.5. If foo is declared as MODULE_PARM in object bar
>> then you will be able to boot with bar.foo=27 or even foo=27 as long as
>> variable foo is unique amongst all objects in the kernel.
>
>Cool. Any plans how to handle drivers which are build from multiple
>object files like bttv? Think "bar" needs to be configurable handle this
>nicely. bttv should have bttv.card=xxx because the module is called
>"bttv", but the source file where the card insmod option is declared is
>bttv-cards.c ...
The prefix will come from the module name, not the source name, even
when the code is built into the kernel. So in the case of bttv it will
be bttv.foo, not bttv-cards.foo. That needs information from the
Makefile which is currently discarded, the Makefile processing for
multi object modules needs to be changed, which is why it is a 2.5
change.
On Sun, 19 Nov 2000, Dan Hollis wrote:
> Writeprotect the flashbios with the motherboard jumper, and remove the
> cmos battery.
>
> Checkmate. :-)
Only if you run your kernel XIP from the flash. If you load it into RAM,
it's still possible for an attacker to modify it. You can load new code
into the kernel even if the kernel doesn't make it easy for you by having
CONFIG_MODULES defined.
--
dwmw2
Gerd Knorr wrote:
> Why? What is the point in compiling bttv statically into the kernel?
Well, I see the modules vs. static flame war is already in progress ;-)
My reason for wanting static kernels is that I usually build many, very
different versions of the same kernel, among which I frequently switch
back and forth, and which I copy to different machines. Modules just get
in the way here.
I'm not at all against modules in general, quite to the contrary, but
there are cases where a static kernel is preferrable, and since it's
easy to keep the driver usable also without modules, I think it's worth
the effort.
Since we don't have Keith Owens' wonderful extension yet, I've made a
patch for 2.4.0-test11-pre7 that adds the new option bttv_card, and
renames bt848_radio to bttv_radio, replacing my previous patch. It also
fixes a rather embarrassing mistake I made in the bt848_radio patch ...
- Werner
---------------------------------- cut here -----------------------------------
--- linux.orig/Documentation/kernel-parameters.txt Tue Sep 5 22:51:14 2000
+++ linux/Documentation/kernel-parameters.txt Mon Nov 20 02:15:59 2000
@@ -43,6 +43,7 @@
SERIAL Serial support is enabled.
SMP The kernel is an SMP kernel.
SOUND Appropriate sound system support is enabled.
+ V4L Video For Linux support is enabled.
VGA The VGA console has been enabled.
VT Virtual terminal support is enabled.
XT IBM PC/XT MFM hard disk support is enabled.
@@ -115,6 +116,20 @@
Duplex Mode.
bmouse= [HW,MOUSE,PS2] Bus mouse.
+
+ bttv_card= [HW,V4L] Specify the model of the BT848/878 card(s),
+ superseding any auto-detection. The values are
+ described in Documentation/video4linux/bttv/CARDLIST.
+ E.g. bttv_card=2 specifies "Hauppauge old" for the
+ first card, bttv_card=3,3 specifies "STB" for the
+ first two cards.
+
+ bttv_radio= [HW,V4L] Enables the FM radio tuners of BT848/878
+ cards. This parameter corresponds to the radio= module
+ parameter if the driver is compiled as such, e.g.
+ bttv_radio=1 enables the radio of the first card,
+ bttv_radio=0,1 enables the radio of the second card,
+ etc.
BusLogic= [HW,SCSI]
--- linux.orig/drivers/media/video/bttv-cards.c Mon Nov 20 02:07:47 2000
+++ linux/drivers/media/video/bttv-cards.c Mon Nov 20 03:07:22 2000
@@ -1319,6 +1319,24 @@
}
}
+#ifndef MODULE
+
+static int __init bttv_card_setup(char *str)
+{
+ int i,number,res = 2;
+
+ for (i = 0; res == 2 && i < BTTV_MAX; i++) {
+ res = get_option(&str,&number);
+ if (res)
+ card[i] = number;
+ }
+ return 1;
+}
+
+__setup("bttv_card=", bttv_card_setup);
+
+#endif /* not MODULE */
+
/*
* Local variables:
* c-basic-offset: 8
--- linux.orig/drivers/media/video/bttv-driver.c Mon Nov 20 02:07:47 2000
+++ linux/drivers/media/video/bttv-driver.c Mon Nov 20 02:59:10 2000
@@ -3100,6 +3100,24 @@
module_init(bttv_init_module);
module_exit(bttv_cleanup_module);
+#ifndef MODULE
+
+static int __init bttv_radio_setup(char *str)
+{
+ int i,number,res = 2;
+
+ for (i = 0; res == 2 && i < BTTV_MAX; i++) {
+ res = get_option(&str,&number);
+ if (res)
+ radio[i] = number;
+ }
+ return 1;
+}
+
+__setup("bttv_radio=", bttv_radio_setup);
+
+#endif /* not MODULE */
+
/*
* Local variables:
* c-basic-offset: 8
--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH [email protected] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
On Mon, 20 Nov 2000, David Woodhouse wrote:
> On Sun, 19 Nov 2000, Dan Hollis wrote:
> > Writeprotect the flashbios with the motherboard jumper, and remove the
> > cmos battery.
> > Checkmate. :-)
> Only if you run your kernel XIP from the flash. If you load it into RAM,
> it's still possible for an attacker to modify it. You can load new code
> into the kernel even if the kernel doesn't make it easy for you by having
> CONFIG_MODULES defined.
The original assertion made was that a script kiddie could modify the
kernel so you wouldnt be able to detect a rooted box even after a reboot.
What I posted would stop that cold, 100%. Boot from writeprotected floppy,
writeprotect the flashbios, and remove the cmos battery.
-Dan
On Sun, 19 Nov 2000, Rogier Wolff wrote:
> Someone wrote:
> > > > So change the CMOS-settings so that the BIOS changes the boot order
> > > > from A, C, CD-ROM to C first instead. *grin* How long do you want
> > > > to keep playing Tic-Tac-Toe?
> > > Writeprotect the flashbios with the motherboard jumper, and remove the
> > > cmos battery.
> The "writeprotect flashbios" usually only protects the bottom 8k of
> the CMOS. That's the part that you still need to boot the system to
> reflash it should somehow your flash be nuked.
The writeprotect jumper on all motherboards ive seen physically prevent
erase/program voltages from reaching the flash chip (usually pin 1, Vpp).
This is why enabling writeprotect jumper on motherboards also prevents
the ECSD area from being updated (which is outside the bottom 8k
bootblock).
-Dan
David Ford <[email protected]> wrote:
>> Please turn this off.
>>
>My vcard size is the same or smaller than the average signature. Using mime,
you
>have the option of easily filtering vcards. Signatures aren't as easily
>identified for filtering.
I think the complaint was due not to the size but to the fact that vcards come
through as attachments, whereas signatures are usually plain text. Some of us
think attachments of any kind (or anything other than plain text) on mailing
lists are Bad Things.
On 19 Nov 2000, Gerd Knorr wrote:
> Some generic way to make module args available as kernel args too
> would be nice. Or at least some simple one-liner I could put next to
> the MODULE_PARM() macro...
Well, I did a patch that does automagically convert MODULE_PARAM
stuff to __setup() functions - it even was in some 2.3.XX-acXX
but appearantly never got into Linus tree.
You may want to look at the "[PATCH] final support for MODULE_PARAM as
kernel commandline" thread, as well as "Re: Linux 2.3.18ac5". To look
at the newest version of the patch just grap the newest 2.3.18acXX,
I tried to rip it out and attached it (but I'm sure it does not
apply cleanly, but you get the idea).
It would be nice to hear from Linus if it was him, who rejected the
change or it was Alan who did not bother to send it.
Richard.
--
Richard Guenther <[email protected]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/
diff -u --new-file --recursive --exclude-from ../exclude linux.vanilla/include/linux/module.h linux.ac/include/linux/module.h
--- linux.vanilla/include/linux/module.h Tue Aug 17 17:27:42 1999
+++ linux.ac/include/linux/module.h Wed Sep 22 17:00:20 1999
@@ -8,6 +8,7 @@
#define _LINUX_MODULE_H
#include <linux/config.h>
+#include <linux/init.h>
#ifdef __GENKSYMS__
# define _set_ver(sym) sym
@@ -207,11 +208,17 @@
#endif
#else /* MODULE */
-
+extern int parse_parameters(void *var, char *type, char *str);
#define MODULE_AUTHOR(name)
#define MODULE_DESCRIPTION(desc)
#define MODULE_SUPPORTED_DEVICE(name)
-#define MODULE_PARM(var,type)
+#define MODULE_PARM(var,type) \
+static char *modparm##var##_setup_type __initdata = type;\
+static int __init modparm##var##_setup(char *str)\
+{\
+ return parse_parameters((void *)&var, modparm##var##_setup_type, str);\
+}\
+__setup(MODULE_NAME #var "=", modparm##var##_setup);
#define MODULE_PARM_DESC(var,desc)
#ifndef __GENKSYMS__
diff -u --new-file --recursive --exclude-from ../exclude linux.vanilla/lib/Makefile linux.ac/lib/Makefile
--- linux.vanilla/lib/Makefile Mon Nov 27 13:54:00 1995
+++ linux.ac/lib/Makefile Mon Sep 13 00:04:31 1999
@@ -7,6 +7,6 @@
#
L_TARGET := lib.a
-L_OBJS := errno.o ctype.o string.o vsprintf.o
+L_OBJS := errno.o ctype.o string.o vsprintf.o parse.o
include $(TOPDIR)/Rules.make
diff -u --new-file --recursive --exclude-from ../exclude linux.vanilla/lib/parse.c linux.ac/lib/parse.c
--- linux.vanilla/lib/parse.c Thu Jan 1 01:00:00 1970
+++ linux.ac/lib/parse.c Mon Sep 13 01:57:36 1999
@@ -0,0 +1,119 @@
+/*
+ * linux/lib/parse.c
+ *
+ * (C) Richard Guenther <[email protected]>
+ *
+ * Heavily based on parts of modutil's insmod.c which is
+ *
+ * Copyright 1996, 1997 Linux International.
+ *
+ * New implementation contributed by Richard Henderson <[email protected]>
+ * Based on original work by Bjorn Eckwall <[email protected]>
+ *
+ * This file is part of the Linux modutils.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Fixes:
+ * Alan Cox Make it get non arrays right.
+ */
+
+#include <linux/kernel.h>
+#include <linux/ctype.h>
+#include <linux/string.h>
+
+/* parse module parameters like insmod */
+int parse_parameters(void *var, char *type, char *str)
+{
+ char *p, t;
+ long min, max, val, cnt;
+ int array = 0;
+
+ p = type;
+ if (isdigit(*p)) {
+ min = simple_strtoul(p, &p, 0);
+ if (*p == '-')
+ {
+ max = simple_strtoul(p+1, &p, 0);
+ array=1;
+ }
+ else
+ max = min;
+ } else
+ min = max = 1;
+ t = *p;
+
+ /*
+ * We are passed a pointer to the object. Now the object
+ * could be an array, in which case we have a pointer to
+ * a pointer. It might be a direct value in which case
+ * we have a pointer the value to write.
+ *
+ * For an array we want to the array base, for a non array
+ * pass, we want the value
+ *
+ * Alan.
+ */
+
+ if(array)
+ var=*(void **)var;
+
+ p = str;
+ cnt = 0;
+ do {
+ if (*p == ',') {
+ p++;
+ cnt++;
+ continue;
+ }
+ switch (t) {
+ case 'b':
+ val = simple_strtol(p, &p, 0);
+ ((char *)var)[cnt] = (char)val;
+ break;
+ case 'h':
+ val = simple_strtol(p, &p, 0);
+ ((short *)var)[cnt] = (short)val;
+ break;
+ case 'i':
+ val = simple_strtol(p, &p, 0);
+ ((int *)var)[cnt] = (int)val;
+ break;
+ case 'l':
+ val = simple_strtol(p, &p, 0);
+ ((long *)var)[cnt] = (long)val;
+ break;
+ case 's':
+ /* complex quoting is not possible, as parse_options()
+ * just searches for ' ', so we can safely just leech
+ * the whole string (multiple strings are impossible, too)
+ * - where do we check for overflows?? */
+ strcpy((char *)(var), p);
+ break;
+ default:
+ printk(KERN_INFO "error in parsing arguments \"%s\" using format %s\n", str, type);
+ return 0;
+ }
+ if (*p == ',')
+ p++;
+ cnt++;
+ } while (*p && cnt < max);
+
+ return 1;
+}
+
+
+
+
On Sun, Nov 19, 2000 at 07:00:41PM -0800, Dan Hollis wrote:
> On Mon, 20 Nov 2000, David Woodhouse wrote:
> > On Sun, 19 Nov 2000, Dan Hollis wrote:
> > > Writeprotect the flashbios with the motherboard jumper, and remove the
> > > cmos battery.
> > > Checkmate. :-)
> > Only if you run your kernel XIP from the flash. If you load it into RAM,
> > it's still possible for an attacker to modify it. You can load new code
> > into the kernel even if the kernel doesn't make it easy for you by having
> > CONFIG_MODULES defined.
>
> The original assertion made was that a script kiddie could modify the
> kernel so you wouldnt be able to detect a rooted box even after a reboot.
>
> What I posted would stop that cold, 100%. Boot from writeprotected floppy,
> writeprotect the flashbios, and remove the cmos battery.
There was some patch floating around so you could boot a new kernel without
having to reboot. And I'm guessing you could also "box" it into a plex86
vm.
--
____/| Ragnar H?jland Freedom - Linux - OpenGL Fingerprint 94C4B
\ o.O| 2F0D27DE025BE2302C
=(_)= "Thou shalt not follow the NULL pointer for 104B78C56 B72F0822
U chaos and madness await thee at its end." hkp://keys.pgp.com
Handle via comment channels only.