The following topics are covered in this document:
Changes to the CentOS installation program (Anaconda)
General information
Kernel-related information
Changes to drivers and hardware support
Changes to packages
The following section includes information specific to the CentOS installation program, Anaconda.
In order to upgrade an already-installed CentOS 3 system to Update 4, you must use yum to update those packages that have changed. The use of Anaconda to upgrade to Update 4 is not supported.
Use Anaconda only to perform a fresh install of CentOS 3 Update 4.
If you are copying the contents of the CentOS 3 Update 4 CD-ROMs (in preparation for a network-based installation, for example) be sure you copy the CD-ROMs for the operating system only. Do not copy the Extras CD-ROM, or any of the layered product CD-ROMs, as this will overwrite files necessary for Anaconda's proper operation.
These CD-ROMs must be installed after CentOS has been installed.
This section contains general information not specific to any other section of this document.
CentOS 3 Update 4 now includes Mailman, an electronic mail discussion and e-newsletter lists system. Mailman is integrated with the Web, making it easy for users to manage their accounts and for list owners to administer their lists. Mailman supports built-in archiving, automatic bounce processing, content filtering, digest delivery, spam filters, and more.
This section contains information related to the CentOS 3 Update 4 kernel.
The Open Sound System (OSS) AC97 plugin infrastructure has been backported to the CentOS 3 Update 4 kernel. This allows registering modules to modify the behavior of the OSS subsystem depending on the AC97 CODEC(s) in use.
Because the OSS subsystem is not supported in the hugemem kernel, the AC97 plugin infrastructure is unavailable in the hugemem kernel.
The release notes for CentOS 3 Update 3 contained information related to Exec-Shield. This information was not entirely accurate; the corrected information appears below.
The CentOS 3 Update 4 kernel includes a new security feature known as Exec-Shield. Exec-Shield is a security-enhancing modification to the Linux kernel that makes large parts of specially-marked programs — including their stack — not executable. This can reduce the potential damage of some security holes, such as buffer overflow exploits.
Exec-Shield can also randomize the virtual memory addresses at which certain binaries are loaded. This randomized VM mapping makes it more difficult for a malicious application to improperly access code or data based on knowledge of the code or data's virtual address.
Exec-Shield's behavior can be controlled via the proc file system. Two files are used:
/proc/sys/kernel/exec-shield
/proc/sys/kernel/exec-shield-randomize
The /proc/sys/kernel/exec-shield file controls overall Exec-Shield functionality, and can be manipulated using the following command:
echo <value> > /proc/sys/kernel/exec-shield
Where <value> is one of the following:
0 — Exec-Shield (including randomized VM mapping) is disabled for all binaries, marked or not
1 — Exec-Shield is enabled for all marked binaries
The default value for /proc/sys/kernel/exec-shield is 1.
The /proc/sys/kernel/exec-shield-randomize file controls whether Exec-Shield randomizes VM mapping, and can be manipulated using the following command:
echo <value> > /proc/sys/kernel/exec-shield-randomize
Where <value> is one of the following:
0 — Randomized VM mapping is disabled
1 — Randomized VM mapping is enabled
The default value for /proc/sys/kernel/exec-shield-randomize is 1.
It is also possible to configure Exec-Shield by including one (or both) of the following lines in the /etc/sysctl.conf file:
kernel.exec-shield=<value>
kernel.exec-shield-randomize=<value>
(Where <value> is as previously described.)
Exec-Shield can also be disabled at a system level by means of a kernel boot option. Appending the following parameter to the "kernel" line(s) in the /etc/grub.conf file will disable Exec-Shield:
exec-shield=0
Exec-Shield functionality is available only to binaries that have been built (and marked) using the toolchain (compiler, assembler, linker) available with CentOS 3. Binaries that have been built using a different version of the toolchain can still be used, but since they will not be marked, they will not take advantage of Exec-Shield.
Application developers should keep in mind that, in the majority of cases, GCC correctly marks its generated code as being capable of using Exec-Shield. In the few instances (usually caused by inline assembler or other nonportable code) where GCC non-optimally (or, more rarely, incorrectly) marks generated code, it is possible to pass GCC options to obtain the desired result.
The options controlling binary marking at the assembler level are:
-Wa,--execstack
-Wa,--noexecstack
The options controlling binary marking at the linker level are:
-Wl,-z,execstack
-Wl,-z,noexecstack
It is also possible to exert more fine-grained control by explicitly disabling Exec-Shield for a specific binary at run time. This is done using the setarch command:
setarch i386 <binary>
(Where <binary> represents the binary to be run.) The binary is then run without Exec-Shield functionality.
The proc file /proc/self/maps can be used to observe Exec-Shield's effects. By using cat to display the current process's VM mapping, you can see Exec-Shield at work. Similarly, you can use setarch in conjunction with cat to see how normal VM mapping differs from Exec-Shield's mapping.
This update includes bug fixes for a number of drivers. The more significant driver updates are listed below. In some cases, the original driver has been preserved under a different name, and is available as a non-default alternative for organizations that wish to migrate their driver configuration to the latest versions at a later time.
The migration to the latest drivers should be completed before the next CentOS update is applied, because in most cases only one older-revision driver will be preserved for each update.
These release notes also indicate which older-revision drivers have been removed from this kernel update. These drivers have the base driver name with the revision digits appended; for example, megaraid_2002.o. You must remove these drivers from /etc/modules.conf before installing this kernel update.
Keep in mind that the only definitive way to determine what drivers are being used is to review the contents of /etc/modules.conf. Use of the lsmod command is not a substitute for examining this file.
XXX
This section contains listings of packages that have been updated or added from CentOS 3 as part of Update 4.
These package lists include packages from all variants of CentOS 3. Your system may not include every one of the packages listed here.
The following packages have been updated from the original release of CentOS 3:
XXX
The following packages have been added to CentOS 3 Update 4:
XXX
The following packages have been removed from CentOS 3 Update 4:
XXX
( x86 )