Peter Jay Salzman said: > there's a new "major catagory" in 2.4.20: "library routines". under > that, there are two options: compression and decompression support for > zlib. no help files for it. > > anyone know what kernel-space libz style support is for? is the kernel > now compressing portions of itself on the fly or something zany like > that?
I had a guess on the purpose... (background) Issues have come up with zlib in the past. Older copies of the zlib libs permited exploits and this lead to headlines in bugtraq for a while. The problems in zlib were *big*. Many apps use zlib, and though many dyn link against the zlib on your system, not all need to do this, and some link to zlib staticly. (This meant upgrading you zlib may not be enough to "secure" the system against zlib expolts.) Then again, some are commercial/proprietary and though "strings" may provide you with some information in the application, that is not guarantee for detecting use of zlib in an application. (obfuscation, etc.) I seem to recall the bug in zlib that was exploited was based on allocation of space for decompressing not being big enough for the actual content (carefully crafted content). My guess, was that the zlib kernel routines are designed to permit the kernel to deal with this issue by controlling the space allocation and allowing an extra layer of security if an application should use an insecure zlib. Now, the actual content of the docs suggest there is a relation to this. It appears as though the zlib stuff for 2.4.20 is a replacement for zlib. However, it appears as though apps must use the provided *.h files before they can take advantage of this. From: /usr/src/linux-2.4.20/lib/zlib_inflate/Makefile : # # This is a modified version of zlib, which does all memory # allocation ahead of time. # # This is only the decompression, see zlib_deflate for the # the compression # # Decompression needs to be serialized for each memory # allocation. # # (The upsides of the simplification is that you can't get in # any nasty situations wrt memory management, and that the # uncompression can be done without blocking on allocation). # >From the paired zlib_deflate a similar comment: # # This is a modified version of zlib, which does all memory # allocation ahead of time. # # This is the compression code, see zlib_inflate for the # decompression code. # I would have expected a *lot* of discussion on the inclusion of parts of lib routines into the kernel/kernel-space, but have not found much yet. Anyone else? -ME -- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS/CM$/IT$/LS$/S/O$ !d--( ) !s !a (-----) C $( ) U $( $) P $> L $( ) E W $( ) N o K w $> > O-@ M $ V-$>- !PS !PE Y PGP t@-( ) 5 @ X@ R- tv- b DI D G--@ e > > h( )> r*>? z? ------END GEEK CODE BLOCK------ decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html Campus IT(/OS Security): Operating Systems Support Specialist Assistant _______________________________________________ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
