Linux-Development-Sys Digest #457, Volume #8 Thu, 1 Feb 01 04:13:10 EST
Contents:
Re: can Linux be secure? (Toby Haynes)
Re: What's wrong with my lilo.conf? ([EMAIL PROTECTED])
Re: 2.4.1pre and 2.4.0ac problem: __buggy_fxsr_alignment undefined (Trevor Hemsley)
ALD - Assembly Language Debugger - where? ([EMAIL PROTECTED])
Re: Semaphore use with C++ Linux driver code ("D. Stimits")
Re: No of CPUs in a SMP system on 2.4.0 and Cacheline size (Ronald Cole)
Re: No of CPUs in a SMP system on 2.4.0 and Cacheline size (Kaelin Colclasure)
Re: can Linux be secure? ([EMAIL PROTECTED])
Isn't ReiserFS in 2.4.1 (bjrosen)
Re: can Linux be secure? ([EMAIL PROTECTED])
Re: Isn't ReiserFS in 2.4.1 (Don Carroll)
Re: Isn't ReiserFS in 2.4.1 (Paul Kimoto)
porting 2.2.x driver , looking for kfree_s (Don Carroll)
porting 2.2.x driver , looking for kfree_s (Don Carroll)
Re: Newbie to kernel module programming (Arne Driescher)
Re: PCI bus access (Arne Driescher)
----------------------------------------------------------------------------
From: Toby Haynes <[EMAIL PROTECTED]>
Subject: Re: can Linux be secure?
Date: 31 Jan 2001 16:14:59 -0500
On Wed, 31 Jan 2001, [EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
>>
>> On 30 Jan 2001 18:50:02 GMT Juha Laiho <[EMAIL PROTECTED]> wrote:
>>
>> | Things that might be worth a look:
>> | - NSA has built some kind of secured Linux system
>> | - Trustix Secure Linux distribution looks rather nice
>>
>> I didn't see any kernel changes in it. The biggest problems out there
>> seem to be all the userland programs, especially the daemons and suid
>> programs. I know about all that. I'm asking about the kernel, and
>> so many people are still doing the usenet practice of diverting the
>> question.
>
> I repeat there have been one or two local kernel exploits over the
> last five or so year that I can remember. I do not remember seeing
> ANY remote kernel exploits.
Linux kernels up to 2.2.15 (or was it 16) had a vulnerability where you could
fake the system into not releasing setuid properly and tailoring processes
using this method into obtaining root priviledges. Fixed in 2.2.17 and later
definitely. But you had to be on the machine to get this exploit to work - you
couldn't get a straight remote buffer overflow to give you a root shell by this
method.
Like a lot of the security postings about Linux vulnerabilites, this was a
fairly obscure problem and difficult to implement an attack exploit. And once
it was known about, the fix appeared extremely quickly.
Cheers,
Toby Haynes
--
Toby Haynes
The views and opinions expressed in this message are my own, and do
not necessarily reflect those of IBM Canada.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: What's wrong with my lilo.conf?
Date: Wed, 31 Jan 2001 21:25:37 -0000
On Wed, 31 Jan 2001 09:30:12 +0100 Kasper Dupont <[EMAIL PROTECTED]> wrote:
| Another possibility is to pass the
| root as an argument to the kernel:
| append="root=/dev/hda1", in that
| case the kernel will do the
| translation at boot time. Since no
| filesystem is available at that
| point the translation uses a table
| found in the kernel source.
This does limit the range of devices that can be root, but the good
ones are covered.
| I don't know how rdev does the
| translation, but I believe it does
| the same as lilo but in this case
| there has not been a chroot to
| /mnt/floppy first.
I've always gotten the idea it did stat on the name.
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
From: [EMAIL PROTECTED] (Trevor Hemsley)
Subject: Re: 2.4.1pre and 2.4.0ac problem: __buggy_fxsr_alignment undefined
Date: 31 Jan 2001 21:33:58 GMT
On Wed, 31 Jan 2001 13:51:11, [EMAIL PROTECTED] (J³rgen
Koslowski) wrote:
> Kasper Dupont ([EMAIL PROTECTED]) wrote:
>
> : It sounds like something similar to the get_user and
> : put_user macros.
>
> : The get_user and put_user macros can only be called
> : with elements of size 1, 2 or 4. In the macro there
> : is a switch on sizeof applied to the argument. In
> : the default case there is a reference to a
> : nonexisting function. This reference is removed by
> : the optimizer. This means that if you don't optimize
> : or if there are invalid calls to the macro, the
> : program cannot link.
>
> : Search through the header files for the string
> : __buggy_fxsr_alignment. If you don't find it it is
> : probably made up by the ## preprocessor concatenate
> : directive, then search for the words buggy, fxsr
> : and alignment.
>
> Well, so far I haven't found these words in any header files
> besides linux/include/asm-i386/bugs.h. The relvant bits seem to be
>
> * Pentium III FXSR, SSE support
> * Gareth Hughes <[EMAIL PROTECTED]>, May 2000
>
> and
>
> /* Enable FXSR and company _before_ testing for FP problems. */
> /*
> * Verify that the FXSAVE/FXRSTOR data will be 16-byte aligned.
> */
> if (offsetof(struct task_struct, thread.i387.fxsave) & 15) {
> extern void __buggy_fxsr_alignment(void);
> __buggy_fxsr_alignment();
> }
>
> I have an ordinary old pentium 133 (pentium classic?) and I suspect
> that this bit of code is built into the kernel before checking the
> processor properly. Just strange that nobody else seems to see this
> problem.
That bit of code is #ifdef'ed dependent on you specifying your
processor type correctly. You haven't. You've left it as the default
of P-III.
--
Trevor Hemsley, Brighton, UK.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: ALD - Assembly Language Debugger - where?
Date: Wed, 31 Jan 2001 22:12:10 GMT
This Linux tool used to be available (apparently) at
www.ellipse.magenet.com/ald.html but this link is now
broken. Does anyone have a (recent) copy of ALD or
knows of a new URL that works?
TIA.
dan
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: Wed, 31 Jan 2001 15:40:31 -0700
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Semaphore use with C++ Linux driver code
"Ahmed, Suhail" wrote:
>
> Hi,
>
> I have written an IP chains driver and that uses some C++ object-oriented
> code. My linux kernel version is 2.2.12 and I have RedHat 6.0 installed. I
> am using "struct semaphore" of type "MUTEX" for syncronization purposes. I
> have moticed that some times the system locks up and forces me to re-boot.
> When I comment out the use of semaphore I don't see any system hangs.
>
> I have made the following declaration in my 'C' file:
> struct semaphore MySem = MUTEX;
>
> to use this in the C++ file I have to do the following:
> extern struct semaphore MySem;
>
> Is there any issues with use of the above semaphore (up() & down()) with the
> C++ files??
This *might* help, or it might be total nonsense for this case (it won't
hurt). When compiling C++ you probably want to make sure you are using
the compiler flag "-D__cplusplus", which in many C libs wraps them as:
extern "C" whatever;
In this particular case, instead of the extern you used, use both
-D__cplusplus for general compiling, and modify the extern as:
extern "C" struct semaphore MySem;
Don't use extern "C" around true C++ code, but it is applicable to glibc
functions that are really C and not C++; within glibc, the extern "C"
will be defined by using -D__cplusplus (at least in most cases).
>
> Any pointers would be helpful,
>
> Thanks
> ~Suhail
>
> --
> Posted from thalia.fm.intel.com [132.233.247.11]
> via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
From: Ronald Cole <[EMAIL PROTECTED]>
Subject: Re: No of CPUs in a SMP system on 2.4.0 and Cacheline size
Date: 31 Jan 2001 16:04:07 -0800
kiran <[EMAIL PROTECTED]> writes:
> Was wonderin how to retrive no of cpus on intel SMP.
There's a sysinfo() call in glibc for that.
--
Forte International, P.O. Box 1412, Ridgecrest, CA 93556-1412
Ronald Cole <[EMAIL PROTECTED]> Phone: (760) 499-9142
President, CEO Fax: (760) 499-9152
My GPG fingerprint: C3AF 4BE9 BEA6 F1C2 B084 4A88 8851 E6C8 69E3 B00B
------------------------------
From: Kaelin Colclasure <[EMAIL PROTECTED]>
Subject: Re: No of CPUs in a SMP system on 2.4.0 and Cacheline size
Date: 31 Jan 2001 18:54:17 -0800
kiran <[EMAIL PROTECTED]> writes:
> Hi,
> Was wonderin how to retrive no of cpus on intel SMP. I stumbled across
> smp_num_cpus which is exported in i386_ksyms.c, Looks like it is
> initialized in smpboot.c. Can somebody tell me if i am right?? (problem
> is i don't have a smp box to test it oit as of now :-) )
Assuming you're already kernel-side, then yes, smp_num_cpus will tell
you how many processors are present.
-- Kaelin
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: can Linux be secure?
Date: Thu, 01 Feb 2001 04:31:52 -0000
On 31 Jan 2001 13:39:08 -0500 Toby Haynes <[EMAIL PROTECTED]> wrote:
| On Tue, 30 Jan 2001, [EMAIL PROTECTED] wrote:
|
|> On 30 Jan 2001 10:03:14 -0500 Toby Haynes <[EMAIL PROTECTED]> wrote:
|>
|>| If you are worried about exploits which attain root status and/or fiddle the
|>| kernel by trick-loading kernel modules, then I suggest you take a look at
|>| LIDS. http://www.lids.org/ details most of what you need to know. As a brief
|>| (and incomplete) summary:
|> There will be no users on the machine. Local exploits are not an
|> issue. I guess I neglected to mention this. Sorry.
|
| But you will have 'users' running services. Even 'nobody' is a user. Or are you
| only ever running kernel-level services? Even embedded applications are likely
| to have some user-level services.
As long as these services are secure, there won't be the human users.
Sure, nothing is ever 100% secure, and it is the case if a cracker
gets in on such a service, that 'user' level security may hold them
off.
However, I am not addressing that issue in this thread.
I am currently trying to address direct security issues. I don't want to be
sidetracked. So I'm not going to pursue the 'user' thread at this time.
| Buffer overflow attacks in the kernel? What are you running - Ingo's TUX
| webserver? I'm not aware of any kernel-level buffer overflow attacks - anyone
| care to point at a CERT advisory to prove me wrong?
I haven't heard of any, either. But I do want to get some feedback on
the theoretical possibilities. To what extent is the kernel source
audited by either the developers, or others?
| Anyway, take a look at this:
|
| http://www.bell-labs.com/org/11356/libsafe.html
|
| There are also kernel patches to make the stack non-executable, which should
| cut most exploits off at the pass. Of course, if you actually handle buffers
| properly and truncate the incoming data at your buffer boundary, buffer
| overflow is not possible but they are often subtle and tricky to fully remove..
Sounds like a good tool. But that's another thread.
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
From: bjrosen <[EMAIL PROTECTED]>
Subject: Isn't ReiserFS in 2.4.1
Date: Thu, 01 Feb 2001 04:26:34 GMT
I thought that ReiserFS support was supposed to be in 2.4.1? I didn't
see it listed as one of the choices in file system section of xconfig.
Did I miss it or did ReiserFS get left out of 2.4.1?
Thanks,
Josh
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: can Linux be secure?
Date: Thu, 01 Feb 2001 04:40:18 -0000
On 31 Jan 2001 16:14:59 -0500 Toby Haynes <[EMAIL PROTECTED]> wrote:
| Linux kernels up to 2.2.15 (or was it 16) had a vulnerability where you could
| fake the system into not releasing setuid properly and tailoring processes
| using this method into obtaining root priviledges. Fixed in 2.2.17 and later
| definitely. But you had to be on the machine to get this exploit to work - you
| couldn't get a straight remote buffer overflow to give you a root shell by this
| method.
I remember that one.
| Like a lot of the security postings about Linux vulnerabilites, this was a
| fairly obscure problem and difficult to implement an attack exploit. And once
| it was known about, the fix appeared extremely quickly.
Once I feel confident to simply dismiss security concerns in the
kernel, then I can move on to userland programs (a small subset
of them, to be sure) and their security issues. For them, I do
suspect I will have to address a lot of issues. I will be able
to focus better once confident the kernel can't be an issue.
Then I can make decisions on direction. I'd rather go with Linux
instead of OpenBSD for a couple reasons (features found only in
Linux that I might want to use in these firewalls, and greater
familiarity with Linux which can translate into fewer mistakes
on my part ... there's nothing wrong with OpenBSD at all).
--
=================================================================
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
=================================================================
------------------------------
From: Don Carroll <[EMAIL PROTECTED]>
Subject: Re: Isn't ReiserFS in 2.4.1
Date: Thu, 01 Feb 2001 05:37:49 GMT
bjrosen wrote:
>
> I thought that ReiserFS support was supposed to be in 2.4.1? I didn't
> see it listed as one of the choices in file system section of xconfig.
> Did I miss it or did ReiserFS get left out of 2.4.1?
>
> Thanks,
>
> Josh
>
> Sent via Deja.com
> http://www.deja.com/
I just compiled it and it was there
stock 2.4.1
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: Isn't ReiserFS in 2.4.1
Date: 1 Feb 2001 00:54:11 -0500
Reply-To: [EMAIL PROTECTED]
In article <95aohk$ot7$[EMAIL PROTECTED]>, bjrosen wrote:
> I thought that ReiserFS support was supposed to be in 2.4.1? I didn't
> see it listed as one of the choices in file system section of xconfig.
> Did I miss it or did ReiserFS get left out of 2.4.1?
Did you turn on CONFIG_EXPERIMENTAL?
--
Paul Kimoto
This message was originally posted on Usenet in plain text. Any images,
hyperlinks, or the like shown here have been added without my consent,
and may be a violation of international copyright law.
------------------------------
From: Don Carroll <[EMAIL PROTECTED]>
Subject: porting 2.2.x driver , looking for kfree_s
Date: Thu, 01 Feb 2001 05:41:41 GMT
in slab there used to be kfree_s(buf size_t)
which the wlan drivers use ( 802.11b cards)
kfree(buf) is still there
what can I use to replace this ?
Linus ? Alan ?
thanks
------------------------------
From: Don Carroll <[EMAIL PROTECTED]>
Subject: porting 2.2.x driver , looking for kfree_s
Date: Thu, 01 Feb 2001 05:42:21 GMT
forgot , porting to 2.4.x
in slab there used to be kfree_s(buf size_t)
which the wlan drivers use ( 802.11b cards)
kfree(buf) is still there
what can I use to replace this ?
Linus ? Alan ?
thanks
------------------------------
From: Arne Driescher <[EMAIL PROTECTED]>
Subject: Re: Newbie to kernel module programming
Date: Thu, 01 Feb 2001 09:55:54 +0100
Rich wrote:
>
> In article <5Q7d6.17022$[EMAIL PROTECTED]>, "Rich C."
> <[EMAIL PROTECTED]> wrote:
>
> > Hey all,
> >
> > I am trying to learn to program kernel modules, so I read the Linux
> > Kernel Module Programming Guide_.
> >
> > I followed all the examples exactly, and tried to compile them. For
> > some reason, I get errors when I try to compile the lines:
> >
> > #if CONFIG_MODVERSIONS==1
> > #define MODVERSIONS
> > #include <linux/modversions.h>
> > #endif
> >
> > if I comment these lines out of the hello world example, it compiles
> > fine.
> > If I leave them in, I get truckloads of errors. The same thing happens
> > when I try to include proc_fs.h using the line:
> >
> > #include <linux/proc_fs.h>
> >
> > How could there be errors in the header files themselves? This doesn't
> > seem to make sense to me. Has anyone else encountered this problem? Are
> > my header files out of date?
> >
> > Thanks for any help!
> >
> > Rich.
>
> Just some additional information, I hope this helps:
>
> As a test, I created a file with the only line in it being:
>
> #include <linux/proc_fs.h>
>
> I then compiled it using the command:
>
> gcc -Wall -DMODULE -D__KERNEL__ -O2 -DLINUX -c tst-procfs.c
>
> and I still got all the errors. The errors were in proc_fs.h as well as
> other files which proc_fs.h includes. Examples of errors I'm getting are
> like this:
>
> /usr/include/linux/proc_fs.h:397: parse error before `ino_t'
> /usr/include/linux/proc_fs.h:397: warning: no semicolon at end of struct
> or union
> /usr/include/linux/proc_fs.h:399: parse error before `mode'
> /usr/include/linux/proc_fs.h:399: warning: data definition has no type or
> storage class
> /usr/include/linux/proc_fs.h:400: conflicting types for `name'
> /usr/include/linux/coda.h:537: previous declaration of `name'
> /usr/include/linux/proc_fs.h:401: parse error before `}'
>
> Any help would be appreciated. Thanks all for the great response so far!
>
> Rich.
Hmm, I tried this examle and it compiles without error.
I would say this is a installation problem. You probably
have upgraded your kernel, compiler or what ever and got
some inconsistent header files. Perhaps setting an input path
to /usr/src/linux/include would help.
-Arne
------------------------------
From: Arne Driescher <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.hardware,comp.os.linux.misc
Subject: Re: PCI bus access
Date: Thu, 01 Feb 2001 10:08:23 +0100
David Florez wrote:
>
> Arne,
> I searched the web after reading your post and found this:
> http://kernelnewbies.org/code/mmap/
>
> The concept seems to be what I'm looking for but I've got a doubt:
> I believe that when you map a file into user space by using mmap() the
> kernel thinks it's a real file and therefore uses cache pages to do that
> mapping. What if what you are really mapping is the PCI bus with lots of
> changing hardware registers? How can I get rid of any caching at all?
>
The Linux files system interface is designed in a very generic way.
All drivers can implement mmap even if they don't access real files.
The kernel knows that char devices should not be cached and does
not interfer with your memory handling. You have probably read some
stuff
about the "normal" use of mmap to access files on your drive. This does
not
apply to your own device driver.
-Arne
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to the
comp.os.linux.development.system newsgroup.
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
