Fedora Core 1 Release Notes

fedora-list@redhat.com — For users of Fedora Core releases

fedora-test-list@redhat.com — For testers of Fedora Core test releases

fedora-devel-list@redhat.com — For developers, developers, developers

fedora-docs-list@redhat.com — For participants of the docs project

Minimum: Pentium-class

NOTE: Fedora Core 1 is optimized for Pentium PRO (and later) CPUs, but also supports Pentium-class CPUs. This approach has been taken because Pentium-class optimizations actually result in reduced performance for non-Pentium-class processors.

Recommended for text-mode: 200 MHz Pentium-class or better

Recommended for graphical: 400 MHz Pentium II or better

Custom Installation (Minimal): 520MB

Server: 870MB

Personal Desktop: 1.9GB

Workstation: 2.4GB

Custom Installation (Everything): 5.3GB

Minimum for text-mode: 64MB

Minimum for graphical: 192MB

Recommended for graphical: 256MB

The Fedora Core installation program has the ability to test the integrity of the installation media. It works with the CD, DVD, hard drive ISO, and NFS ISO installation methods. Red Hat recommends that you test all installation media before starting the installation process, and before reporting any installation-related bugs (many of the bugs reported are actually due to improperly-burned CDs). To use this test, type linux mediacheck at the boot: prompt.

Memory testing may be performed prior to installing Fedora Core by entering memtest86 at the boot: prompt. This causes the Memtest86 standalone memory testing software to run. Memtest86 memory testing continues until the Esc key is pressed.

NOTE: You must boot from CD-ROM 1 (or a rescue CD-ROM) in order to use this feature.

During a graphical installation, you can press SHIFT-Print Screen and a screenshot of the current installation screen will be taken. These are stored in the following directory:

/root/anaconda-screenshots/

The screenshots can be accessed once the newly-installed system is rebooted.

Certain hardware configurations (particularly those with LCD displays) may experience problems while starting the Fedora Core installation program. In these instances, restart the installation, and add the "nofb" option to the boot command line.

NOTE: Chinese, Japanese, and Korean graphical installations started using the "nofb" option will start in English, and then switch to the appropriate language once the graphical phase of the installation process begins.

Some Sony VAIO® notebook systems may experience problems installing Fedora Core from CD-ROM. If this happens, restart the installation process and add the following option to the boot command line:

pci=off ide1=0x180,0x386

This option allows the installation to proceed normally; any devices not detected due to the use of this option will be configured the first time Fedora Core is booted.

Fedora Core 1 now supports graphical FTP and HTTP installations. The default for these installation modes remains text-based; however, graphical installations can be enabled by passing "graphical" as a boot-time option.

Note that graphical FTP and HTTP installations increase memory requirements by approximately 64MB, due to the necessity of containing the installer image. However, if you boot the installation program from CD-ROM 1, no additional RAM will be required; instead the installer image will be mounted from the CD-ROM.

Hard drive installations are now graphical by default. There is no memory penalty, as parted now uses a kernel interface that makes it possible to keep partitions mounted on a device while other partitions are being modified.

The firewall configuration screen in the Fedora Core installation program has been simplified. The previous "High", "Medium", and "No firewall" settings have been replaced by a more straightforward on/off-style control. In addition, the default firewall configuration is now stateful, making it more secure. The new design also makes it possible for users of NIS authentication, NFS, and DNS to deploy a firewall with no additional customization required (although customization by specifying port and protocol is still possible).

NOTE: This change also applies to the Security Level Configuration Tool (redhat-config-securitylevel).

Installation via VNC is now supported. To initiate a VNC-based installation, pass vnc as a boot-time option. If necessary, a password can be set by adding "vncpassword=<password>" to the boot-time options. The VNC display will be "<host>:1", where <host> is the hostname or IP address of the system installing Fedora Core.

It is also possible for the Fedora Core installation program to initiate a connection to a listening VNC client. This is done by using the vncconnect boot-time option:

linux vnc vncconnect=<client>[:<port>]

(Where <client> is the hostname or IP address of the system running the listening VNC client, and <port> is an optional port specification that may be specified if the VNC client is not listening on port 5500, which is the default port for this type of connection). The following examples show the how the boot-time option is specified for standard and non-standard ports:

linux vnc vncconnect=pigdog.example.com

linux vnc vncconnect=pigdog.example.com:27910

The system that is to run the listening VNC client must then launch the appropriate software to run the VNC client in its listening mode. For the VNC client supplied with Fedora Core 1, the following command is sufficient:

vncviewer -listen

In addition, a new kickstart directive has been added to support VNC-based installations:

vnc [--password <password>] [--connect <host>[:<port>]]

(Where --password <password> is an optional parameter for specifying a VNC password, and [--connect <host>[:<port>]] is an optional parameter for specifying the host (and optionally, port) of a system running a listening VNC client.)

NOTE: If you specify any of the VNC-related boot-time options, they will override the corresponding options present in the kickstart file.

The XFree86 "radeon" driver has been enhanced by Red Hat to include experimental 2D-only support for some of ATI's newer hardware, including the following models:

- Radeon 7000 IGP (A4+) 4237

- Radeon 9000 IGP (A5) 5834

- Radeon Mobility 9000 IGP (U3) 5835

- Radeon 9200 (AGP) 5964

- Radeon 9600 AP (AGP)

- Radeon 9600 Pro AR (AGP)

- Radeon Mobility M10 NP (AGP)

- FireGL (R350) AK (AGP)

- Radeon 9800 NH (AGP)

- FireGL (R350) NK (AGP)

NOTE: The new Radeon driver support has been included for people to test and to help identify possible instabilities requiring additional work in the future. Note also that there are even newer models of ATI hardware that are not supported at this time.

Users with unsupported video hardware can try to use the ChipID XFree86 config file option as documented in the XF86Config manpage to force the driver to treat the card as another, already-supported one, although there is no guarantee this will work. If a particular ATI chip does not work, or if the ChipID option works for a particular unsupported chip, file a bug report in bugzilla. Include your X server logs (/var/log/XFree86.*.log), X server config file (/etc/X11/XF86Config), and complete details, as this will help us to improve the driver as time permits.

The XFree86 open source vmware video driver is provided strictly as a convenience to the Fedora community. Any problems encountered with XFree86 under vmware should be reported directly to the XFree86 project by filing a bug report at http://bugs.xfree86.org. Red Hat will monitor changes made to the driver upstream, and may include updates in future releases as time permits.

There have been issues observed when upgrading Red Hat Linux 7.<x>, 8.0, 9 and Fedora Core 1 systems running Ximian GNOME. The issue is caused by version overlap between the official Red Hat Linux RPMs (or the ones from the Fedora Project) and the Ximian RPMs. This configuration is not supported. You have several choices in resolving this issue:

1) You may remove Ximian GNOME from your system prior to upgrading to Fedora Core.

2) You may upgrade your system, and then immediately reinstall Ximian GNOME.

3) You may upgrade your system, and then immediately remove all remaining Ximian RPMs, replacing them with the corresponding Fedora Core RPMs.

You must resolve the version overlap using one of the above choices. Failure to do so will result in an unstable GNOME configuration.

There has been some confusion regarding font-related issues under the X Window System in recent versions of Fedora Core (and versions of Red Hat Linux before it.) At the present time, there are two font subsystems, each with different characteristics:

- The original (15+ year old) subsystem is referred to as the "core X font subsystem". Fonts rendered by this subsystem are not anti-aliased, are handled by the X server, and have names like:

-misc-fixed-medium-r-normal--10-100-75-75-c-60-iso8859-1

The newer font subsystem is known as "fontconfig", and allows applications direct access to the font files. Fontconfig is often used along with the "Xft" library, which allows applications to render fontconfig fonts to the screen with antialiasing. Fontconfig uses more human-friendly names like:

Luxi Sans-10

Over time, fontconfig/Xft will replace the core X font subsystem. At the present time, applications using the Qt 3 or GTK 2 toolkits (which would include KDE and GNOME applications) use the fontconfig and Xft font subsystem; most everything else uses the core X fonts.

In the future, Fedora Core may support only fontconfig/Xft in place of the XFS font server as the default local font access method.

NOTE: An exception to the font subsystem usage outlined above is OpenOffice.org (which uses its own font rendering technology).

If you wish to add new fonts to your Fedora Core 1 system, you must be aware that the steps necessary depend on which font subsystem is to use the new fonts. For the core X font subsystem, you must:

1. Create the /usr/share/fonts/local/ directory (if it doesn't already exist):

mkdir /usr/share/fonts/local/

2. Copy the new font file into /usr/share/fonts/local/

3. Update the font information by issuing the following commands (note that, due to formatting restrictions, the following commands may appear on more than one line; in use, each command should be entered on a single line):

ttmkfdir -d /usr/share/fonts/local/ -o /usr/share/fonts/local/fonts.scale

mkfontdir /usr/share/local/

4. If you had to create /usr/share/fonts/local/, you must then add it to the X font server (xfs) path:

chkfontpath --add /usr/share/fonts/local/

Adding new fonts to the fontconfig font subsystem is more straightforward; the new font file only needs to be copied into the /usr/share/fonts/ directory (individual users can modify their personal font configuration by copying the font file into the ~/.fonts/ directory).

After the new font has been copied, use fc-cache to update the font information cache:

fc-cache <directory>

(Where <directory> would be either the /usr/share/fonts/ or ~/.fonts/ directories.)

Individual users may also install fonts graphically, by browsing fonts:/// in Nautilus, and dragging the new font files there.

NOTE: If the font filename ends with ".gz", it has been compressed with gzip, and must be decompressed (with the gunzip command) before the fontconfig font subsystem can use the font.

Due to the transition to the new font system based on fontconfig/Xft, GTK+ 1.2 applications are not affected by any changes made via the Font Preferences dialog. For these applications, a font can be configured by adding the following lines to the file ~/.gtkrc.mine:

style "user-font" {

fontset = "<font-specification>"

}

widget_class "*" style "user-font"

(Where <font-specification> represents a font specification in the style used by traditional X applications, such as "-adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-*".)

CUPS is now the only print spooler provided. During upgrades, if LPRng is installed, it will be replaced by CUPS.

The Red Hat Update Agent (up2date) now supports installing packages from apt and yum repositories as well as local directories. This includes dependency solving and obsoletes handling. Additional repositories can be configured in the /etc/sysconfig/rhn/sources file.

Fedora Core 1 includes Postfix 2.0. If you are upgrading from Red Hat Linux 9 or earlier and were using Postfix 1.x, you should review your Postfix configuration for compatibility with the newer version.

Also note that Postfix is no longer configured to operate in a chroot'ed environment. There are several reasons for this change; among them are:

- Easier utilization of authentication methods

- Using a chroot'ed environment is no longer recommended by Postfix author Wietse Venema for many installations. However, if such an environment is still desired, the system administrator may manually configure Postfix after the installation/upgrade process is complete. Note, however, that the system administrator will be responsible for maintaining all files in the chroot "jail," as the Fedora Core packages no longer attempt maintenance of these files.

Fedora Core 1 now ships with Mailman version 2.1.2. This version includes significant changes from the earlier versions of Mailman that were included with Red Hat Linux. If you use Mailman, you should consult /usr/share/doc/mailman*/INSTALL.REDHAT for additional information. In particular, note that aliases have changed between Mailman 2.0 and 2.1; a script (named update) has been provided to upgrade existing mail lists and their aliases.

The openldap, postfix, and sendmail packages are now compiled using version 2 of the Cyrus SASL library. For these packages, the default location of each application's SASL configuration files has changed from /usr/lib/sasl to /usr/lib/sasl2. In addition, some SASL configuration options have changed; refer to /usr/share/doc/cyrus-sasl*/options.html for a list of options recognized by version 2 of the Cyrus SASL library.

Configuration files that specified a pwcheck_method of sasldb must be changed to specify auxprop, the auxprop_plugin setting must be set to sasldb, and the contents of /etc/sasldb must be migrated into /etc/sasldb2 using the dbconverter-2 tool.

Configurations that set pwcheck_method to other values must be set to saslauthd, and the saslauthd service must be enabled and started.

Refer to /usr/share/doc/cyrus-sasl*/upgrading.html for more information.

Fedora Core 1 includes the Native POSIX Thread Library (NPTL), a new implementation of POSIX threads for Linux. This library provides performance improvements and increased scalability.

This thread library is designed to be binary compatible with the old LinuxThreads implementation; however, applications that rely on the places where the LinuxThreads implementation deviates from the POSIX standard will need to be fixed. Notable differences include:

· Signal handling has changed from per-thread signal handling to POSIX process signal handling.

· getpid() returns the same value in all threads.

· Thread handlers registered with pthread_atfork are not run if vfork() is used.

· No manager thread.

Applications that are known to have problems using NPTL include:

- Sun JRE prior to version 1.4.1

- IBM JRE

If an application does not work properly with NPTL, it can be run using the old LinuxThreads implementation by setting the following environment variable:

LD_ASSUME_KERNEL=<kernel-version>

The following versions are available:

· 2.4.19 — Linuxthreads with floating stacks

· 2.2.5 — Linuxthreads without floating stacks

Note that software using errno, h_errno, and _res must #include the appropriate header file (errno.h, netdb.h, and resolv.h respectively) before they are used. However, LD_ASSUME_KERNEL=2.4.19 can be used as a workaround until the software can be fixed.

Multi-threaded C++ programs using thread cancellation might need to be forced to use the LinuxThreads library using the LD_ASSUME_KERNEL=2.4.19 environment variable setting. Otherwise, the program will terminate abnormally if the cancellation is acted on (since the generated exception is not caught).

Newly-written C++ code that uses functions from the C runtime environment might have to be adjusted to take the cancellation into account. This can be done by one of the following methods:

· Not marking the C++ function with throw() (so that callers are aware that an exception might be thrown) and by compiling the code with exceptions. This is the default compilation option; users should not specify -fno-exceptions when compiling.

· Disabling cancellation completely before entering the functions that call the cancel-able C runtime functions. This can be done with the following call:

pthread_setcancelstate (PTHREAD_CANCEL_DISABLE, &oldstate)

After the C functions are called cancellation can be enabled again with the following call:

pthread_setcancelstate (oldstate, NULL)

NOTE: At this point the cancellations are acted upon and therefore the function calling pthread_setcancelstate() must be compiled with exceptions enabled and must be marked as throwing exceptions.

Prelinking is now enabled by default on Fedora Core 1. Prelinking reduces the time taken by the dynamic linker when starting programs. It does this by performing some of the dynamic linker's tasks ahead of time, and is done on a regular basis via cron. The current prelink behavior is controlled by the /etc/sysconfig/prelink file.

NOTE: Because prelinking affects the virtual memory layout of programs and libraries, there is an impact on Exec-shield, in that the full VM mapping ramdomization done by Exec-shield is not possible on prelinked binaries. However, the prelinking operation itself does randomize VM mapping; the biggest difference is that this randomization is done once during the prelinking, and does not change (unless the library is prelinked again).

Fedora Core 1 includes the capability of producing Position Independent Executables (PIE) for C, C++, and Java. This feature is enabled with the -fpie and -fPIE GCC options to compile, which are similar in usage to the -fpic and -fPIC options, respectively, and at link time with the -pie option.

If the Exec-shield feature is enabled, PIEs get assigned random load addresses each time, making the exploitation of possible security problems more difficult. This is in contrast to regular application code, which is always loaded at the same virtual address and therefore provides predictable addresses for possible exploits.

Fedora Core 1 now uses a graphical interface while booting. The graphical boot screen will appear once the kernel has loaded. Graphical booting is controlled by the GRAPHICAL line in the /etc/sysconfig/init file; set it to "no" to permanently disable graphical booting. In addition, the parameter rhgb must be appended to your bootloader command line.

Systems that have been upgraded to Fedora Core 1 will not be configured to include the graphical boot feature. You must install the rhgb package, and add the rhgb boot-time parameter to your bootloader configuration.

The Security Level Configuration Tool (redhat-config-securitylevel) has been simplified. The previous "High", "Medium", and "No firewall" settings have been replaced by a more straightforward on/off-style control. In addition, the default firewall configuration is now stateful, making it more secure. The new design also makes it possible for users of NIS authentication, NFS, and DNS to deploy a firewall with no additional customization required (although customization by specifying port and protocol is still possible).

NOTE: This change also affects the Fedora Core installation program.

For proper Java operation, the Mozilla Web browser requires a Java plugin compatible with GCC 3.2 (such as the plugin included with Sun j2re 1.4.2, in the ns610-gcc32/ directory).

Historically, the SSH and Telnet protocols have not included negotiation of the character encoding to be used for text sent over the connection. Instead, it has been assumed that both ends will use Latin-1, Latin-2, UTF-8, EUC-JP, or whatever the most appropriate character encoding for the user's language might be.

Fedora Core has made a transition from single-locale encodings such as Latin-1 to UTF-8. As a result, you may have problems when making a Telnet or SSH connection between newer versions of Fedora Core and older versions, or between newer versions of Fedora Core and other operating systems. Symptoms of possible problems include (for example) a mangled display in "mc", or the inability to read non-ASCII files.

In the long term, all systems are expected to migrate to UTF-8, eliminating this issue. In the short term, there are some workarounds to be aware of:

- In gnome-terminal, the "Terminal->Character Coding" menu allows you to force a specific encoding.

- The xterm(1) and luit(1) man pages describe the -en and -lc options, which can be useful.

- The iconv command line utility, especially with the -c option to handle invalid characters, can be useful for converting files to other encodings.

The BIND nameserver has had its security tightened. The /var/named/ directory is no longer owned by "named", but rather by "root". Slave zone files should now be stored in the new /var/named/slaves/ directory, which is owned by "named". In addition, a new bind-chroot package makes it possible to run the named daemon in a chroot() "jail" (located in /var/named/chroot/) for greater security.

As part of the migration to UTF-8, some issues should be kept in mind:

- Filenames located on ext3 file systems should be in UTF-8.

- The input of non-ASCII characters from the system console is not possible; only graphical applications support the input of these characters.

- Some languages currently do not display correctly in Fedora Core 1. These languages include Greek, and Gaelic (both types).

The default system and user encoding for Japanese, Korean, Simplified Chinese and Traditional Chinese locales has changed to UTF-8.

For backward compatibility support in the legacy character set, you can override your existing locale by editing /etc/sysconfig/i18n or ~/.i18n. Changes made to the /etc/sysconfig/i18n file effect the entire system, while changes made to the ~/.i18n file only affect that user's login session.

You can also pass a LANG environment variable when you run a application to change the character set:

LANG=ja_JP.eucJP gedit

You can also view files using different encodings in a virtual terminal by using the following command:

lv <filename>

Current known issues to new locales — Korean man pages are still in the legacy character set.

OpenLDAP Upgrade-Related Notes — The on-disk storage format used by slapd, the standalone OpenLDAP server binary, has changed. Users upgrading LDAP servers from previous releases of Fedora Core must dump their directories to LDIF files using slapcat and re-import them into the new format using slapadd.

Because OpenLDAP now uses version 2 of the Cyrus SASL library, secrets stored in databases used by version 1 of the SASL library will not be usable for authenticating clients to an LDAP directory server. Administrators can generate an initial database for use with version 2 of the library by running the following command:

dbconverter-2 /etc/sasldb

By default, the Sendmail mail transport agent (MTA) does not accept network connections from any host other than the local computer. If you want to configure Sendmail as a server for other clients, you must edit /etc/mail/sendmail.mc and change the DAEMON_OPTIONS line to also listen on network devices (or comment out this option entirely using the dnl comment delimiter). You must then regenerate /etc/mail/sendmail.cf by running the following command (as root):

make -C /etc/mail

Note that you must have the sendmail-cf package installed for this to work.

The PHP domxml extension module has been moved into the php-domxml subpackage, which must be installed to retain domxml support. A new subpackage (php-xmlrpc) has been added, which includes XML-RPC support for PHP.

The Fedora Core 1 kernel includes support for ACPI (Advanced Configuration and Power Interface). By default, ACPI support is disabled; it can be enabled by using the following boot-time option:

acpi=on

When enabled, ACPI is used for device enumeration, and will load all appropriate power and thermal control modules located in the /lib/modules/<kernel-version>/kernel/drivers/acpi/ directory. However, be aware that ACPI-based power and thermal control is in the early stages of development, and not all functions (or hardware support) are fully implemented. For example, any sleep/suspend functionality is unlikely to work.

NOTE: The ACPI subsystem results in a kernel too big to fit on a diskette; therefore, the kernel placed on boot diskettes does not include ACPI support. In addition, because of these size issues, emergency boot diskettes will not work if you require ACPI device enumeration to boot. You must use Anaconda's rescue mode instead of an emergency boot diskette.

The Fedora Core 1 kernel includes support for CPU clock throttling control using the /proc/cpufreq file. In order to use this feature, you must load one of the following modules:

- longhaul.o

- p4-clockmod.o

- longrun.o

- speedstep-centrino.o

- powernow-k6.o

- powernow-k7.o

- speedstep-ich.o

- speedstep-lib.o

Using cat to display the file results in output similar to the following:

          minimum CPU frequency  -  maximum CPU frequency  -  policy
CPU  0       1200000 ( 75%)      -     1600000 (100%)      -  performance

        

This means that CPU 0 has a minimum clock frequency of 1.2GHz, a maximum clock frequency of 1.6GHz, and is set to maximize performance.

To change these settings, use the following command:

echo -n "<cpu><delimiter><min><delimiter><max><delimiter><policy>" > /proc/cpufreq

(Where <cpu> represents a CPU number starting at 0 (and can be omitted if all CPUs are to use the same settings), <min> is the minimum clock frequency (which can be specified as a percentage or in KHz), <max> is the maximum clock frequency (which can be specified as a percentage or in KHz), and <policy> is the desired policy, which is either powersave or performance. NOTE: For <delimiter> you must use ":" as the delimiter when specifying frequencies, and "%" when specifying percentages.)

It is also possible to set minimum, maximum, and policy using the following boot-time parameter:

cpufreq=<min>:<max>:<policy>

(Where <policy> is as before. However, <min> and <max> have the same meanings as before, but must be specified in KHz. Note that it is not possible to specify a CPU number; the settings are applied to all available CPUs.

NOTE: The values entered are validated according to hardware or thermal considerations; therefore, a subsequent display of /proc/cpufreq may differ from the desired settings. Note also that automatic manipulation of CPU frequency is currently limited; some hardware may support this, but little software-based solutions presently exist.

The Fedora Core 1 kernel now includes support for laptop mode. When placed in laptop mode, the kernel batches disk I/O, allowing the disk drive to become idle long enough for the drive's power-saving features to take affect. This can result in significant increases in battery runtime.

To enable laptop mode, issue the following command:

echo 1 > /proc/sys/vm/laptop_mode

To disable laptop mode, issue the following command:

echo 0 > /proc/sys/vm/laptop_mode

NOTE: The APM scripts included with Fedora Core 1 automatically enable laptop mode when switching to battery power.

The Fedora Core 1 kernel includes new Exec-shield functionality. 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. Exec-shield is related to the older "non-exec stack patch" but has the potential to provide greater protection.

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.

NOTE: Prelinking also plays a part in the randomization of VM mapping.

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

- 2 — Exec-shield is enabled for all binaries, regardless of marking (To be used for testing purposes ONLY)

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

NOTE: Exec-shield functionality is available only to binaries that have been built (and marked) using the toolchain (compiler, assembler, linker) available with Fedora Core 1 (or a recent upstream version of gcc and binutils that correctly inserts .note.GNU-stack and PT_GNU_STACK information, respectively). 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.

The Fedora Core 1 kernel now makes it possible to prevent the loading of kernel modules. This can be useful for system administrators wanting to ensure that only a strictly-controlled set of modules are loaded. To disable kernel module loading, issue the following command:

echo off > /proc/modules

Once this command has been issued, all further attempts to load kernel modules will fail.

NOTE: Once kernel module loading has been disabled, a reboot is required to re-enable it.