BTTV detection broken in 2.4.0-test11-pre5
Subsystems (4)
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 28Signature · 7 lines
_________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH [email protected] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/ - 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/
Quoted 1 line · Werner Almesberger
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).
Quoted 2 lines
The problem seems to be that my card sets
PCI_SUBSYSTEM_IDandPCI_SUBSYSTEM_VENDOR_IDto 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
Signature · 7 lines
Wirtschaftsinformatiker == Leute, die zwar die aktuellen Aktienkurse jedes Softwareherstellers kennen, aber keines der Produkte auch nur ansatzweise bedienen können. -- Benedict Mangelsdorff - 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/
Quoted 3 lines · Gerd Knorr
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
Signature · 7 lines
_________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH [email protected] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/ - 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/
Quoted 6 lines · Werner Almesberger
Quoted 3 lines · Gerd Knorr
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
__setupparameter :-(
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 ...
Quoted 3 lines
Should it be called
bttv_cardorbt484_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
Signature · 7 lines
Wirtschaftsinformatiker == Leute, die zwar die aktuellen Aktienkurse jedes Softwareherstellers kennen, aber keines der Produkte auch nur ansatzweise bedienen können. -- Benedict Mangelsdorff - 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/
Quoted 4 lines · Gerd Knorr
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
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:[email protected]
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard
Quoted 10 lines
Quoted 4 lines
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.
Quoted 1 line
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.
Quoted 1 line
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...
Quoted 3 lines
--------------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/
Quoted 3 lines · 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.
-
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/
Quoted 9 lines · Keith Owens
Quoted 3 lines · 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_PARMin 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
Signature · 8 lines
Wirtschaftsinformatiker == Leute, die zwar die aktuellen Aktienkurse jedes Softwareherstellers kennen, aber keines der Produkte auch nur ansatzweise bedienen können. -- Benedict Mangelsdorff - 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/
Quoted 10 lines · Gerd Knorr
Quoted 3 lines · Keith Owens
On my list for 2.5. If foo is declared as
MODULE_PARMin 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.
-
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 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
Quoted 57 lines · 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-pre5Quoted 10 lines
Quoted 4 lines
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.
Quoted 1 line
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.
Quoted 1 line
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.confand 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/networkstop; rmmod de4x5; modprobe tulip;/etc/rc.d/init.d/networkstart (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...Quoted 3 lines
--------------E48A413646B728A179A7D2FC
Content-Type: text/x-vcard; charset=us-ascii;
name="david.vcf"
Quoted 9 lines
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-----
-
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/
Quoted 3 lines · David Lang
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.
-
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/
Quoted 7 lines · Alexander Viro
Quoted 3 lines · David Lang
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
-
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/
In article <[email protected]> you write:
Quoted 10 lines · Alexander Viro
Quoted 7 lines · David Lang
Quoted 3 lines
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
Signature · 5 lines
"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/
Quoted 11 lines · Christer Weinigel
In article <[email protected]> you write:
Quoted 10 lines · Alexander Viro
Quoted 7 lines · David Lang
Quoted 3 lines
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.
Quoted 3 lines
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)
Quoted 3 lines
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/
Quoted 3 lines · Alexander Viro
Quoted 1 line
Quoted 1 line
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
-
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/
Quoted 8 lines · Alexander Viro
Quoted 6 lines · Christer Weinigel
In article <[email protected]> you write:
Quoted 5 lines · Alexander Viro
Quoted 4 lines · David Lang
Quoted 3 lines
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.
Quoted 9 lines
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
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
Quoted 7 lines
Quoted 4 lines
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)
Quoted 8 lines
Quoted 3 lines
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/
-
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/
Quoted 6 lines · Christer Weinigel
In article <[email protected]> you write:
Quoted 5 lines · Alexander Viro
Quoted 4 lines · David Lang
Quoted 3 lines
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.
Quoted 7 lines
Quoted 4 lines
Quoted 3 lines
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
-
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/
Quoted 8 lines
Quoted 3 lines
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
-
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/
Quoted 6 lines · Someone
Quoted 6 lines
Quoted 3 lines
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.
Signature · 8 lines
** [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. - 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/
Quoted 9 lines · Rogier Wolff
Quoted 5 lines · Someone
Quoted 5 lines
Quoted 3 lines
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
-
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/
Quoted 4 lines · Dan Hollis
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.
Signature · 7 lines
dwmw2 - 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/
Quoted 8 lines · David Woodhouse
Quoted 3 lines · Dan Hollis
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_MODULESdefined.
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
-
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/
Quoted 10 lines · Dan Hollis
Quoted 8 lines · David Woodhouse
Quoted 3 lines · Dan Hollis
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_MODULESdefined.
Quoted 5 lines
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.
Signature · 10 lines
____/| 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. - 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/
Quoted 9 lines · Christer Weinigel
Quoted 1 line
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
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:[email protected]
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard
Quoted 10 lines · Christer Weinigel
In article <[email protected]> you write:
Quoted 9 lines · Alexander Viro
Quoted 7 lines · David Lang
Quoted 3 lines
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.
Quoted 6 lines
Quoted 1 line
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
Quoted 5 lines
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.
Quoted 7 lines
/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/
-
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/
Quoted 3 lines · David Lang
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.
-
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/
Quoted 3 lines · David Lang
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
-
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/
Quoted 3 lines · Gerd Knorr
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/
include/linux/module.h +9 -2
@@ -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__
lib/Makefile +1 -1
@@ -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
lib/parse.c +119 -0
119 lines not on this page · raw message
-
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/
Quoted 1 line
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.
Quoted 5 lines
Quoted 1 line
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.
Quoted 9 lines
Quoted 1 line
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.confand 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.
Quoted 4 lines
* rmmod ide-cd; modprobe ide-scsi; modprobe
sr_mod(for burning CD's)
*/etc/rc.d/init.d/networkstop; rmmod de4x5; modprobe tulip;/etc/rc.d/init.d/networkstart (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.
Quoted 1 line
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
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:[email protected]
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard
PATCH 1/1 bttv_card & bttv_radio (was Re: BTTV detection broken in 2.4.0-test11-pre5)
In reply to Werner AlmesbergerQuoted 1 line · Gerd Knorr
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 -----------------------------------
Documentation/kernel-parameters.txt +15 -0
@@ -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]
drivers/media/video/bttv-cards.c +18 -0
@@ -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
drivers/media/video/bttv-driver.c +18 -0
@@ -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
Signature · 7 lines
_________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH [email protected] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/ - 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/