BTTV detection broken in 2.4.0-test11-pre5

BTTV detection broken in 2.4.0-test11-pre5

[Werner Almesberger]

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           Werner.Almesberger@epfl.ch /
/_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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: BTTV detection broken in 2.4.0-test11-pre5

[Gerd Knorr]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: BTTV detection broken in 2.4.0-test11-pre5

[Werner Almesberger]

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           Werner.Almesberger@epfl.ch /
/_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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: BTTV detection broken in 2.4.0-test11-pre5

[Gerd Knorr]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: BTTV detection broken in 2.4.0-test11-pre5

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

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


[-- Attachment #2: Card for David Ford --]
[-- Type: text/x-vcard, Size: 176 bytes --]

begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:david@kalifornia.com
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard

Re: BTTV detection broken in 2.4.0-test11-pre5

[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.

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: BTTV detection broken in 2.4.0-test11-pre5

[Keith Owens]

On 19 Nov 2000 12:56:17 GMT, 
kraxel@bytesex.org (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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: BTTV detection broken in 2.4.0-test11-pre5

[Alexander Viro]

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.

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

Re: BTTV detection broken in 2.4.0-test11-pre5

[Keith Owens]

On Sun, 19 Nov 2000 07:16:52 -0800 (PST), 
David Lang <david.lang@digitalinsight.com> 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.

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

Re: BTTV detection broken in 2.4.0-test11-pre5

[Christer Weinigel]

In article <Pine.LNX.4.30.0011190710440.13087-100000@anime.net> 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?"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: BTTV detection broken in 2.4.0-test11-pre5

[Dan Hollis]

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

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

Re: BTTV detection broken in 2.4.0-test11-pre5

[David Lang]

-----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 kraxel@bytesex.org wrote:

> Date: 19 Nov 2000 12:56:17 GMT
> From: kraxel@bytesex.org
> To: linux-kernel@vger.kernel.org
> 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 majordomo@vger.kernel.org
> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: BTTV detection broken in 2.4.0-test11-pre5

[Alexander Viro]

On Sun, 19 Nov 2000, Christer Weinigel wrote:

> In article <Pine.LNX.4.30.0011190710440.13087-100000@anime.net> 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.

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

Re: BTTV detection broken in 2.4.0-test11-pre5

[Dan Hollis]

On Sun, 19 Nov 2000, Christer Weinigel wrote:
> In article <Pine.LNX.4.30.0011190710440.13087-100000@anime.net> 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

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

Re: BTTV detection broken in 2.4.0-test11-pre5

[Dan Hollis]

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

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

Re: BTTV detection broken in 2.4.0-test11-pre5

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]

> 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


[-- Attachment #2: Card for David Ford --]
[-- Type: text/x-vcard, Size: 176 bytes --]

begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:david@kalifornia.com
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard

Re: BTTV detection broken in 2.4.0-test11-pre5

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]

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


[-- Attachment #2: Card for David Ford --]
[-- Type: text/x-vcard, Size: 176 bytes --]

begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:david@kalifornia.com
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard

Re: BTTV detection broken in 2.4.0-test11-pre5

[Alan Cox]

> > 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: BTTV detection broken in 2.4.0-test11-pre5

[Gerd Knorr]

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

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

Re: BTTV detection broken in 2.4.0-test11-pre5

[Gerd Knorr]

On Mon, 20 Nov 2000, Keith Owens wrote:

> On 19 Nov 2000 12:56:17 GMT, 
> kraxel@bytesex.org (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

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

Re: BTTV detection broken in 2.4.0-test11-pre5

[Rogier Wolff]

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. 


-- 
** R.E.Wolff@BitWizard.nl ** 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: BTTV detection broken in 2.4.0-test11-pre5

[Ben Ford]

Christer Weinigel wrote:

> In article <Pine.LNX.4.30.0011190710440.13087-100000@anime.net> 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 majordomo@vger.kernel.org
> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: BTTV detection broken in 2.4.0-test11-pre5

[Ben Ford]

Alexander Viro wrote:

> On Sun, 19 Nov 2000, Christer Weinigel wrote:
>
> > In article <Pine.LNX.4.30.0011190710440.13087-100000@anime.net> 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 majordomo@vger.kernel.org
> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: BTTV detection broken in 2.4.0-test11-pre5

[Keith Owens]

On Sun, 19 Nov 2000 20:03:52 +0100 (CET), 
Gerd Knorr <kraxel@bytesex.org> 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.

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

Re: BTTV detection broken in 2.4.0-test11-pre5

[David Woodhouse]

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


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

Re: BTTV detection broken in 2.4.0-test11-pre5

[Dan Hollis]

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

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

Re: BTTV detection broken in 2.4.0-test11-pre5

[Dan Hollis]

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

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

Re: BTTV detection broken in 2.4.0-test11-pre5

[Wayne.Brown]

David Ford <david@linux.com> 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.


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

Re: BTTV detection broken in 2.4.0-test11-pre5

[Ragnar Hojland Espinosa]

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/