Re: readl() / writel() on PowerPC
On Mon, Jul 02, 2001 at 08:22:55PM -0400, David T Eger wrote: > > I have been working on a driver for a PowerPC PCI card/framebuffer device, > and noticed that the standard readl() and writel() for this platform to > byte swapping, since PowerPC runs big-endian. However, at least for my > hardware it's *really* not needed, and should just do a regular load > store, as is done for CONFIG_APUS. Looking at another driver > (drivers/char/bttv.h) I notice that Mr. Metzler redefines his read and > write routines for PowerPC as well to do simple loads and stores to IO > regions. I believe you are looking for __raw_readl(), __raw_writel(). dave... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: readl() / writel() on PowerPC
On Mon, Jul 02, 2001 at 08:22:55PM -0400, David T Eger wrote: I have been working on a driver for a PowerPC PCI card/framebuffer device, and noticed that the standard readl() and writel() for this platform to byte swapping, since PowerPC runs big-endian. However, at least for my hardware it's *really* not needed, and should just do a regular load store, as is done for CONFIG_APUS. Looking at another driver (drivers/char/bttv.h) I notice that Mr. Metzler redefines his read and write routines for PowerPC as well to do simple loads and stores to IO regions. I believe you are looking for __raw_readl(), __raw_writel(). dave... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] copy_*_user length bugs?
On Tue, Apr 17, 2001 at 09:39:15PM -0700, Dawson Engler wrote: > Hi All, > > at the suggestion of Chris ([EMAIL PROTECTED]) I wrote a simple > checker to warn when the length parameter to copy_*_user was (1) an > integer and (2) not checked < 0. > > As an example, the ipv6 routine rawv6_geticmpfilter gets an integer 'len' > from user space, checks that it is smaller than a struct size and then > uses length as an argument to copy_to_user: > > if (get_user(len, optlen)) > return -EFAULT; > if (len > sizeof(struct icmp6_filter)) > len = sizeof(struct icmp6_filter); > if (put_user(len, optlen)) > return -EFAULT; > if (copy_to_user(optval, >tp_pinfo.tp_raw.filter, len)) > return -EFAULT; > > Is this a real bug? Or is the checked rule only applicable to > __copy_*_user routines rather than copy_*_user routines? (If its a real > bug, theres about 8 others that we found). The len parameter is an unsigned value, so this code is ok as long as access_ok() correctly checks that the range to copy doesn't stray outside of the userspace range, including the possible wraparound for a very large len. access_ok() on i386 checks for the wraparound. m68k doesn't use it. PowerPC is correct, but only because TASK_SIZE is 0x8000. If it is ever changed, there could be a problem. I didn't check other architectures, because I don't understand the asm. dave... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] copy_*_user length bugs?
On Tue, Apr 17, 2001 at 09:39:15PM -0700, Dawson Engler wrote: Hi All, at the suggestion of Chris ([EMAIL PROTECTED]) I wrote a simple checker to warn when the length parameter to copy_*_user was (1) an integer and (2) not checked 0. As an example, the ipv6 routine rawv6_geticmpfilter gets an integer 'len' from user space, checks that it is smaller than a struct size and then uses length as an argument to copy_to_user: if (get_user(len, optlen)) return -EFAULT; if (len sizeof(struct icmp6_filter)) len = sizeof(struct icmp6_filter); if (put_user(len, optlen)) return -EFAULT; if (copy_to_user(optval, sk-tp_pinfo.tp_raw.filter, len)) return -EFAULT; Is this a real bug? Or is the checked rule only applicable to __copy_*_user routines rather than copy_*_user routines? (If its a real bug, theres about 8 others that we found). The len parameter is an unsigned value, so this code is ok as long as access_ok() correctly checks that the range to copy doesn't stray outside of the userspace range, including the possible wraparound for a very large len. access_ok() on i386 checks for the wraparound. m68k doesn't use it. PowerPC is correct, but only because TASK_SIZE is 0x8000. If it is ever changed, there could be a problem. I didn't check other architectures, because I don't understand the asm. dave... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
On Thu, Apr 12, 2001 at 09:04:28PM -0700, Andre Hedrick wrote: > On Thu, 12 Apr 2001, george anzinger wrote: > > > Actually we could do the same thing they did for errno, i.e. > > > > #define jiffies get_jiffies() > > extern unsigned get_jiffies(void); > > > No, not really. HZ still defines the units of jiffies and most all the > > timing is still related to it. Its just that interrupts are only "set > > up" when a "real" time event is due. > > Great HZ always defines units of jiffies, but that is worthless if there > is not a ruleset that tells me a value to divide by to return it to a > specific quantity of time. It makes more sense to start migrating drivers to macros such as msec_to_jiffies(), msec_to_whatever_add_timer_wants(), etc. (Names changed to protect the innocent.) And leave HZ approximately the way it is, because that's what the code expects. A good transition is for add_timer() to be defined as #define add_timer(a) add_timer_ns(a*10/HZ) although this causes problems with timers over 4 seconds. As much as I like nanoseconds, it's probably overkill here, since one should be requesting absolute time if it's specified in nanoseconds. dave... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-Kernel Archive: No 100 HZ timer !
On Thu, Apr 12, 2001 at 09:04:28PM -0700, Andre Hedrick wrote: On Thu, 12 Apr 2001, george anzinger wrote: Actually we could do the same thing they did for errno, i.e. #define jiffies get_jiffies() extern unsigned get_jiffies(void); No, not really. HZ still defines the units of jiffies and most all the timing is still related to it. Its just that interrupts are only "set up" when a "real" time event is due. Great HZ always defines units of jiffies, but that is worthless if there is not a ruleset that tells me a value to divide by to return it to a specific quantity of time. It makes more sense to start migrating drivers to macros such as msec_to_jiffies(), msec_to_whatever_add_timer_wants(), etc. (Names changed to protect the innocent.) And leave HZ approximately the way it is, because that's what the code expects. A good transition is for add_timer() to be defined as #define add_timer(a) add_timer_ns(a*10/HZ) although this causes problems with timers over 4 seconds. As much as I like nanoseconds, it's probably overkill here, since one should be requesting absolute time if it's specified in nanoseconds. dave... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Tue, Apr 10, 2001 at 02:04:17PM +0200, Mikulas Patocka wrote: > > Adding and removing timers happens much more frequently than PIT tick, so > comparing these times is pointless. > > If you have some device and timer protecting it from lockup on buggy > hardware, you actually > > send request to device > add timer > > receive interrupt and read reply > remove timer > > With the curent timer semantics, the cost of add timer and del timer is > nearly zero. If you had to reprogram the PIT on each request and reply, it > would slow things down. > > Note that you call mod_timer also on each packet received - and in worst > case (which may happen), you end up reprogramming the PIT on each packet. This just indicates that the interface needs to be richer -- i.e., such as having a "lazy timer" that means: "wake me up when _at least_ N ns have elapsed, but there's no hurry." If waking you up at N ns is expensive, then the wakeup is delayed until something else interesting happens. This is effectively what we have now anyway. Perhaps the current add_timer() should be mapped to lazy timers. dave... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Mon, Apr 09, 2001 at 11:35:44PM +0100, Alan Cox wrote: > > > Its worth doing even on the ancient x86 boards with the PIT. > > > > Note that programming the PIT is slw and doing it on every timer > > add_timer/del_timer would be a pain. > > You only have to do it occasionally. > > When you add a timer newer than the current one > (arguably newer by at least 1/2*HZ sec) > When you finish running the timers at an interval and the new interval is > significantly larger than the current one. > > Remember each tick we poke the PIT anyway Reprogramming takes 3-4 times as long. However, I still agree it's a good idea. RTAI will run the 8254 timer in one-shot mode if you ask it to. However, on machines without a monotonically increasing counter, i.e., the TSC, you have to use 8254 timer 0 as both the timebase and the interval counter -- you end up slowly losing time because of the race condition between reading the timer and writing a new interval. RTAI's solution is to disable kd_mksound and use timer 2 as a poor man's TSC. If either of those is too big of a price, it may suffice to report that the timer granularity on 486's is 10 ms. It would be nice to see any redesign in this area make it more modular. I have hardware that would make it possible to slave the Linux system clock directly off a high-accuracy timebase, which would be super-useful for some applications. I've been doing some of this already, both as a kernel patch and as part of RTAI; search for 'timekeeper' in the LKML archives if interested. dave... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Mon, Apr 09, 2001 at 11:35:44PM +0100, Alan Cox wrote: Its worth doing even on the ancient x86 boards with the PIT. Note that programming the PIT is slw and doing it on every timer add_timer/del_timer would be a pain. You only have to do it occasionally. When you add a timer newer than the current one (arguably newer by at least 1/2*HZ sec) When you finish running the timers at an interval and the new interval is significantly larger than the current one. Remember each tick we poke the PIT anyway Reprogramming takes 3-4 times as long. However, I still agree it's a good idea. RTAI will run the 8254 timer in one-shot mode if you ask it to. However, on machines without a monotonically increasing counter, i.e., the TSC, you have to use 8254 timer 0 as both the timebase and the interval counter -- you end up slowly losing time because of the race condition between reading the timer and writing a new interval. RTAI's solution is to disable kd_mksound and use timer 2 as a poor man's TSC. If either of those is too big of a price, it may suffice to report that the timer granularity on 486's is 10 ms. It would be nice to see any redesign in this area make it more modular. I have hardware that would make it possible to slave the Linux system clock directly off a high-accuracy timebase, which would be super-useful for some applications. I've been doing some of this already, both as a kernel patch and as part of RTAI; search for 'timekeeper' in the LKML archives if interested. dave... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: No 100 HZ timer !
On Tue, Apr 10, 2001 at 02:04:17PM +0200, Mikulas Patocka wrote: Adding and removing timers happens much more frequently than PIT tick, so comparing these times is pointless. If you have some device and timer protecting it from lockup on buggy hardware, you actually send request to device add timer receive interrupt and read reply remove timer With the curent timer semantics, the cost of add timer and del timer is nearly zero. If you had to reprogram the PIT on each request and reply, it would slow things down. Note that you call mod_timer also on each packet received - and in worst case (which may happen), you end up reprogramming the PIT on each packet. This just indicates that the interface needs to be richer -- i.e., such as having a "lazy timer" that means: "wake me up when _at least_ N ns have elapsed, but there's no hurry." If waking you up at N ns is expensive, then the wakeup is delayed until something else interesting happens. This is effectively what we have now anyway. Perhaps the current add_timer() should be mapped to lazy timers. dave... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OFFTOPIC] Hardlink utility - reclaim drive space
On Mon, Mar 05, 2001 at 07:17:18PM +, Padraig Brady wrote:
> Hmm.. useful until you actually want to modify a linked file,
> but then your modifying the file in all "merged" trees.
Use emacs, because you can configure it to do something
appropriate with linked files. But for those of us addicted
to vi, the attached wrapper script is pretty cool, too.
dave...
#!/bin/bash
#
# copy-on-write wrapper for hard linked files
# Copyright 2000 David A. Schleef <[EMAIL PROTECTED]>
#
# Please send me any improvments you make to this script. I just
# wrote it as a quick and dirty hack.
linkedfiles=
for each in $*
do
case $each in
-*)
# ignore
;;
*)
if [ -f "$each" ];then
nlinks=$(stat $each|grep Links|sed 's/.*Links:
\(.*\)\{1\}/\1/')
if [ $nlinks -gt 1 ];then
#echo unlinking $each
linkedfiles="$linkedfiles $each"
mv $each $each.orig
cp $each.orig $each
fi
fi
;;
esac
done
/usr/bin/vim $*
for each in $linkedfiles
do
if cmp $each $each.orig &>/dev/null
then
#echo relinking $each
rm $each
mv $each.orig $each
fi
done
Re: [OFFTOPIC] Hardlink utility - reclaim drive space
On Mon, Mar 05, 2001 at 07:17:18PM +, Padraig Brady wrote:
Hmm.. useful until you actually want to modify a linked file,
but then your modifying the file in all "merged" trees.
Use emacs, because you can configure it to do something
appropriate with linked files. But for those of us addicted
to vi, the attached wrapper script is pretty cool, too.
dave...
#!/bin/bash
#
# copy-on-write wrapper for hard linked files
# Copyright 2000 David A. Schleef [EMAIL PROTECTED]
#
# Please send me any improvments you make to this script. I just
# wrote it as a quick and dirty hack.
linkedfiles=
for each in $*
do
case $each in
-*)
# ignore
;;
*)
if [ -f "$each" ];then
nlinks=$(stat $each|grep Links|sed 's/.*Links:
\(.*\)\{1\}/\1/')
if [ $nlinks -gt 1 ];then
#echo unlinking $each
linkedfiles="$linkedfiles $each"
mv $each $each.orig
cp $each.orig $each
fi
fi
;;
esac
done
/usr/bin/vim $*
for each in $linkedfiles
do
if cmp $each $each.orig /dev/null
then
#echo relinking $each
rm $each
mv $each.orig $each
fi
done
Re: Linus's include file strategy redux
On Mon, Dec 18, 2000 at 10:51:09AM -0500, Dana Lacoste wrote:
>
> Can we get a #3 going? I think it could really help both the cross-compile
> people and those who just want to make sure their modules are compiling in
> the 'correct' environment. It also allows for things like 'kgcc vs. gcc' to
> be 'properly' resolved by the distribution-creator as it should be, instead of
> linux-kernel or the 3rd party module mailing lists.
I use the following script (scripts/dep.linux from Comedi-0.7.53).
It could easily be improved to handle the /lib/modules/*/build/include
link. I've also developed (actually, "gathered") a lot of other stuff
for convenient non-kernel module compiling, including compatiblity
header files, Makefiles, etc. Good places to look for stuff include
comedi, RTAI, RTLinux, PCMCIA, and MTD.
Keep in mind that there is no "correct" environment except that
which the user specifies.
dave...
#!/bin/sh
if [ "$LINUXDIR" = "" ]
then
echo -n "Enter location of Linux source tree [/usr/src/linux]: "
read LINUXDIR
: ${LINUXDIR:=/usr/src/linux}
fi
if [ ! -f "$LINUXDIR/.config" ];then
echo Kernel source tree at $LINUXDIR is not configured
echo Fix before continuing
exit 1
fi
echo using LINUXDIR=$LINUXDIR
echo LINUXDIR=$LINUXDIR >.sourcedirs
. $LINUXDIR/.config
#
# check for a bad situation
#
if [ "$CONFIG_MODULES" = "n" ]
then
cat <.uts_version
if [ "$(uname -r)" != "$UTS_VERSION" ]
then
cat
Re: Linus's include file strategy redux
On Mon, Dec 18, 2000 at 10:51:09AM -0500, Dana Lacoste wrote:
Can we get a #3 going? I think it could really help both the cross-compile
people and those who just want to make sure their modules are compiling in
the 'correct' environment. It also allows for things like 'kgcc vs. gcc' to
be 'properly' resolved by the distribution-creator as it should be, instead of
linux-kernel or the 3rd party module mailing lists.
I use the following script (scripts/dep.linux from Comedi-0.7.53).
It could easily be improved to handle the /lib/modules/*/build/include
link. I've also developed (actually, "gathered") a lot of other stuff
for convenient non-kernel module compiling, including compatiblity
header files, Makefiles, etc. Good places to look for stuff include
comedi, RTAI, RTLinux, PCMCIA, and MTD.
Keep in mind that there is no "correct" environment except that
which the user specifies.
dave...
#!/bin/sh
if [ "$LINUXDIR" = "" ]
then
echo -n "Enter location of Linux source tree [/usr/src/linux]: "
read LINUXDIR
: ${LINUXDIR:=/usr/src/linux}
fi
if [ ! -f "$LINUXDIR/.config" ];then
echo Kernel source tree at $LINUXDIR is not configured
echo Fix before continuing
exit 1
fi
echo using LINUXDIR=$LINUXDIR
echo LINUXDIR=$LINUXDIR .sourcedirs
. $LINUXDIR/.config
#
# check for a bad situation
#
if [ "$CONFIG_MODULES" = "n" ]
then
cat EOF
*
*WARNING!!!
*
*Your kernel is configured to not allow loadable modules.
*You are attempting to compile a loadable module for this
*kernel. This is a problem. Please correct it.
*
EOF
exit
fi
#
# check running kernel vs. /usr/src/linux and warn if necessary
#
read dummy dummy dummy2 $LINUXDIR/include/linux/version.h
UTS_VERSION=`echo $dummy2|sed 's/"//g'`
echo UTS_VERSION=$UTS_VERSION .uts_version
if [ "$(uname -r)" != "$UTS_VERSION" ]
then
cat EOF
*
*WARNING!!!
*
*The kernel that is currently running is a different
*version than the source in $LINUXDIR. The current
*compile will create a module that is *incompatible*
*with the running kernel.
*
EOF
fi
-
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/
Re: Pls add this driver to the kernel tree !!
On Fri, Dec 01, 2000 at 09:26:29AM +, David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > Not necessarily - it all depends on what your driver does. In many > > cases, supporting 2.2 and 2.4 is easy, and all you need are a few > > #if's. It's certainly much better to have a dozen or so #if's > > sprinkled throughout the code than to have two separate source trees, > > and have to make the same change to multiple files. > > It's even better to do it without the ugly preprocessor magic - see > include/linux/compatmac.h > > There are a few things missing from there - include/linux/mtd/compatmac.h > has more. One day we'll get round to removing the latter and merging it > into the main one, hopefully. A while ago, I started working on the Mother Of All compatmac.h files, trying to merge Don Becker's stuff, yours, David Hinds, and stuff from my own Comedi package. It quickly got out of control, as including compatmac.h (or kern_compat.h, as I called it) would include most of the include/linux directory. I've since settled for setting up a separate include/linux tree with header files named pci.h, mm.h, etc., that #define the right things and then do an #include_next. Interested parties can find it in Comedi (http://stm.lbl.gov/comedi). dave... - 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/
Re: Pls add this driver to the kernel tree !!
On Fri, Dec 01, 2000 at 09:26:29AM +, David Woodhouse wrote: [EMAIL PROTECTED] said: Not necessarily - it all depends on what your driver does. In many cases, supporting 2.2 and 2.4 is easy, and all you need are a few #if's. It's certainly much better to have a dozen or so #if's sprinkled throughout the code than to have two separate source trees, and have to make the same change to multiple files. It's even better to do it without the ugly preprocessor magic - see include/linux/compatmac.h There are a few things missing from there - include/linux/mtd/compatmac.h has more. One day we'll get round to removing the latter and merging it into the main one, hopefully. A while ago, I started working on the Mother Of All compatmac.h files, trying to merge Don Becker's stuff, yours, David Hinds, and stuff from my own Comedi package. It quickly got out of control, as including compatmac.h (or kern_compat.h, as I called it) would include most of the include/linux directory. I've since settled for setting up a separate include/linux tree with header files named pci.h, mm.h, etc., that #define the right things and then do an #include_next. Interested parties can find it in Comedi (http://stm.lbl.gov/comedi). dave... - 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/
Re: "couldn't find the kernel version the module was compiled for" - help!
On Tue, Nov 14, 2000 at 05:44:42PM -0600, Timur Tabi wrote: > ** Reply to message from Keith Owens <[EMAIL PROTECTED]> on Wed, 15 Nov 2000 > 10:41:42 +1100 > > > > __NO_VERSION__ must be defined before #include . > > It is: > > #ifdef LINUX > #ifndef __ENTRY_C__ > #define __NO_VERSION__ > #endif > #include > #include > #include > #include > > >Do it by hand. > > I don't know what you mean by that. > Module source should look like this: single .c -> single .o #include #include multiple .c -> single .o, main .c file (contains init_module(), etc.) #include #include multiple .c -> single .o, secondary .c file #include multiple .c -> single .o, secondary .c file that requires module.h for a particular purpose, such as EXPORT_SYMBOL() #define __NO_VERSION__ #include #include Note that in most cases, you _don't_ need to include module.h. Your Makefile should call gcc with '-D__KERNEL__ -DMODULE', as well as other approprate flags. dave... - 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/
Re: More modutils: It's probably worse.
On Tue, Nov 14, 2000 at 09:59:22AM +0100, Olaf Kirch wrote: > On Tue, Nov 14, 2000 at 12:06:32AM +0100, Michal Zalewski wrote: > > Maybe I am missing something, but at least for me, modprobe > > vulnerabilities are exploitable via privledged networking services, > > nothing more. > > Maybe not. ncpfs for instance has an ioctl that seems to allow > unprivileged users to specify a character set (codepage in m$speak) > that's requested via load_nls(), which in turn does a > > sprintf(buf, "nls_%s", codepage); > request_module(buf); > > Yummy. Then it looks like the driver is broken, not modutils. > Everyone is fixing modutils right now. Fine, but what about next > year's modutils rewrite? > > This is why I keep repeating over and over again that we should make > sure request_module _does_not_ accept funky module names. Why allow > people to shoot themselves (and, by extension, all other Linux users > out there) in the foot? Although I agree that having request_module() do a sanity check is the best place to do a sanity check, I think it should be up to the driver to not be stupid. The drivers are trusted with copy_to/from_user(), so why can't they be trusted to not pass bad strings. An inline function module_name_sanity_check() would be convenient for those cases where "it is just necessary." Rogue request_module() calls are bad in general, not only because they might have dangerous invalid strings, but also because they might have dangerous _valid_ strings. I can imagine a not-too-unlikely scenario where repeatedly loading a module causes a DoS. dave... - 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/
Re: More modutils: It's probably worse.
On Tue, Nov 14, 2000 at 09:59:22AM +0100, Olaf Kirch wrote: On Tue, Nov 14, 2000 at 12:06:32AM +0100, Michal Zalewski wrote: Maybe I am missing something, but at least for me, modprobe vulnerabilities are exploitable via privledged networking services, nothing more. Maybe not. ncpfs for instance has an ioctl that seems to allow unprivileged users to specify a character set (codepage in m$speak) that's requested via load_nls(), which in turn does a sprintf(buf, "nls_%s", codepage); request_module(buf); Yummy. Then it looks like the driver is broken, not modutils. Everyone is fixing modutils right now. Fine, but what about next year's modutils rewrite? This is why I keep repeating over and over again that we should make sure request_module _does_not_ accept funky module names. Why allow people to shoot themselves (and, by extension, all other Linux users out there) in the foot? Although I agree that having request_module() do a sanity check is the best place to do a sanity check, I think it should be up to the driver to not be stupid. The drivers are trusted with copy_to/from_user(), so why can't they be trusted to not pass bad strings. An inline function module_name_sanity_check() would be convenient for those cases where "it is just necessary." Rogue request_module() calls are bad in general, not only because they might have dangerous invalid strings, but also because they might have dangerous _valid_ strings. I can imagine a not-too-unlikely scenario where repeatedly loading a module causes a DoS. dave... - 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/
Re: couldn't find the kernel version the module was compiled for - help!
On Tue, Nov 14, 2000 at 05:44:42PM -0600, Timur Tabi wrote: ** Reply to message from Keith Owens [EMAIL PROTECTED] on Wed, 15 Nov 2000 10:41:42 +1100 __NO_VERSION__ must be defined before #include module.h. It is: #ifdef LINUX #ifndef __ENTRY_C__ #define __NO_VERSION__ #endif #include linux/version.h #include linux/module.h #include linux/kernel.h #include linux/types.h Do it by hand. I don't know what you mean by that. Module source should look like this: single .c - single .o #include linux/kernel.h #include linux/module.h multiple .c - single .o, main .c file (contains init_module(), etc.) #include linux/kernel.h #include linux/module.h multiple .c - single .o, secondary .c file #include linux/kernel.h multiple .c - single .o, secondary .c file that requires module.h for a particular purpose, such as EXPORT_SYMBOL() #define __NO_VERSION__ #include linux/kernel.h #include linux/module.h Note that in most cases, you _don't_ need to include module.h. Your Makefile should call gcc with '-D__KERNEL__ -DMODULE', as well as other approprate flags. dave... - 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/
