FAQ

From Dazuko
(Difference between revisions)
Jump to: navigation, search
(When I run the GNU/Linux command "insmod" I get an error that is not mentioned here. What is wrong?: added (crazy) link)
(The Linux 2.6 kernel crashes in the change_page_attr() routine when I load a module with syscall hooking enabled.: added (crazy) link)
Line 400: Line 400:
 
=== The Linux 2.6 kernel crashes in the change_page_attr() routine when I load a module with syscall hooking enabled. ===
 
=== The Linux 2.6 kernel crashes in the change_page_attr() routine when I load a module with syscall hooking enabled. ===
   
You have most likely configured Dazuko using the --sct-readonly option for a kernel that does not have a read-only system call table. This option should only be used if problems (such as those mentioned in 5.5) are present. Since the true read-write status of the syscall table can be determined at neither compile time nor run time, you are forced to try one method (first as read-write) and then the other (as read-only).
+
You have most likely configured Dazuko using the --sct-readonly option for a kernel that does not have a read-only system call table. This option should only be used if problems (such as those [http://dazuko.dnsalias.org/wiki/index.php/FAQ#The_command_.22insmod.22_produces_a_segmentation_fault_when_I_load_a_module_with_syscall_hooking_enabled. mentioned above]) are present. Since the true read-write status of the syscall table can be determined at neither compile time nor run time, you are forced to try one method (first as read-write) and then the other (as read-only).
   
 
== Troubleshooting - running the example program ==
 
== Troubleshooting - running the example program ==

Revision as of 22:20, 4 February 2008

Contents


General

What is Dazuko?

Dazuko aims to be a cross-platform device driver that allows applications to control file access on a system. By installing the driver, your system will be able to support file access control applications that are based on Dazuko. As this project becomes more popular and more applications choose Dazuko for their file access needs, it is hoped that this driver will become a common component of most systems.

How do I use Dazuko?

In order to use Dazuko you must first build and insert the kernel module. This then adds a new device to your system (/dev/dazuko). Once you have the Dazuko device, you can run applications that take advantage of the file access control features Dazuko provides.

If you are interested in building your own applications, check out the Dazuko interface specification. You may also want to look at the example program provided with Dazuko for a working reference.

A list of applications known to work with Dazuko can be found on the applications page.

What operating systems are supported by Dazuko?

The current release of Dazuko supports Linux 2.2-2.6, Linux/RSBAC, and FreeBSD 4.x-6.x kernels. However, it is slowly being expanded to support other operating systems such as MacOS X, Solaris, NetBSD, OpenBSD, and Windows. Although all these operating systems have very different control mechanisms, it should still be possible to integrate Dazuko.

What license is Dazuko under?

In order to allow Dazuko to be used on as many operating systems (both proprietary and free) as possible and in order for all software (both proprietary and free) to be able to incorporate the driver's interface, Dazuko uses a BSD license. However, the Dazuko device driver has "extension modules" to implement platform-specific functionality. These extension modules will fall under the license of the operating system on which they will run, thus forcing the complete device driver to this license as well (at compile-time). Here is a quick summary:

Dazuko Application Interface (on all platforms): BSD License
Dazuko device driver (Linux):                    GPL License
Dazuko device driver (FreeBSD):                  BSD License

Does Dazuko detect file accesses over Samba, Netatalk, and NFS?

Yes, yes, and yes. This allows you to develop software to monitor, regulate, or protect file access on your Samba, Netatalk, or NFS File Server.

Note for Netatalk: In order to work correctly with Dazuko, Netatalk must be compiled using the --with-did=cnid option.

Note for NFS: In order to work correctly with Dazuko, the NFS User Server must be used (not the NFS Kernel Server). The NFS Kernel Server communicates over sockets directly from the kernel, thus bypassing Dazuko.

I don't know anything about compiling kernels. Can I just download a pre-compiled binary of Dazuko?

One of the greatest advantages of free operating systems is also for many a problem. That is, they can be customized to support exactly the hardware and features you desire thereby maximizing your system performance (and satisfaction). However, since Dazuko must load into the kernel itself, Dazuko must be compiled with exactly the same code that your kernel was compiled with. With so many different kernel configuration possibilities, it is impossible to precompile a binary for each one.

Therefore, the only way you can get a compiled Dazuko is by compiling it yourself. In the future, operating system distributors may offer Dazuko as a pre-compiled binary, which has already been built for their pre-compiled kernel. SuSE Linux is one such system that already provides a pre-compiled Dazuko driver "out-of-the-box". This makes Dazuko much easier for people to use. Hopefully Dazuko can evolve (politically) to the point where this is more common.

What does Avira GmbH (formerly known as H+BEDV Datentechnik GmbH) have to do with Dazuko?

Avira GmbH is an anti-virus company based in Tettnang, Germany. In order to allow on-access file scanning for the GNU/Linux operating system, they developed Dazuko (called the "AvGuard kernel module" at the time). However, it was felt that releasing the module source code as free software would not only broaden the available user base, but also provide an opportunity to create a common interface for 3rd party file access control. Avira GmbH continues to fund developers to work on the Dazuko project. Although Dazuko is still relatively young, it has become the basis for several products and thus will continue to have development interest from the community.

Where did the name "Dazuko" come from?

Since Dazuko originated from a german company, it was felt that the name should somehow reflect something german. Dazuko's main function is to provide an interface for "file access control", or in german, "Dateizugriffskontrolle". Alles klar?

How is "Dazuko" pronounced?

'dah-tsu-ko'

Troubleshooting - general

What are the known issues with Debian GNU/Linux?

The "dazuko-source" package that is available through apt-get for the current stable release, sarge, is very old (1.2.2). It is recommended that you download the latest stable version from the Dazuko Downloads page.

For Debian unstable and testing, a more recent version of the "dazuko-source" package is available via apt-get.

John Ogness is the current maintainer for the Debian "dazuko-source" package.

For the current stable release, you can download the latest stable version as a Debian package here:

dazuko-source_2.3.3-1_all.deb

The Debian package requires "module-assistant". This will automatically compile and install Dazuko. Here is the procedure:

# apt-get install module-assistant
# dpkg -i dazuko-source_2.3.3-1_all.deb
# m-a a-i dazuko

You can then load the module with:

# modprobe dazuko

What are the known issues with SUSE Linux?

Recent SuSE distributions (SUSE Linux 10, SLES 10, SLED 10) include and use AppArmor by default, which is why other modules cannot access the LSM API. This means that it is not possible to use Dazuko in its default configuration on these systems (because Dazuko by default uses the LSM interface on Linux 2.6 kernels).

As of version 2.3.0 of Dazuko, you can use syscall hooking as an alternative to LSM for Linux 2.6 systems. If you require AppArmor, then you will need to use the syscall hooking method. This must be specified when configuring Dazuko:

$ ./configure --enable-syscalls --mapfile=/path/to/mapfile

The mapfile (System.map) is usually located in /boot and has the kernel version as a suffix.

SuSE 9.1

The default kernel settings for SuSE 9.1 make it difficult to install Dazuko. Here is a set of steps that you will have to take. It will be necessary to have at least kernel version "2.6.5-7.108". This may require an online update.

1. download and build Dazuko 2.3.3

$ tar xzvf dazuko-2.3.3.tar.gz
$ cd dazuko-2.3.3
$ ./configure
$ make

2. copy dazuko.ko to kernel module directory and refresh module dependencies

# cp dazuko.ko /lib/modules/`uname -r`/kernel/security
# depmod -a

3. modify the boot parameters to disable NSA SELinux support

edit /boot/grub/menu.lst and add "selinux=0" to the end of the line:

kernel hd(... showopts

4. set Dazuko and Capability to be automatically loaded on startup

edit /etc/sysconfig/kernel and change the line:

MODULES_LOADED_ON_BOOT=""

to

MODULES_LOADED_ON_BOOT="dazuko capability"

5. reboot machine

What are the known issues with Fedora Core Linux?

A HOWTO for Fedora Core 4 was written by John Flanigan.

A HOWTO for Fedora Core 3 was written by Misu Moldovan.

Linux Default Capabilities are built into the kernel. Capabilities must be built as a module in order to work with Dazuko. This is because the "capabiltity" module does not support stacking.

Assuming you are using a fresh install of Fedora Core 2 and you have installed the kernel sources, here is a quick step-by-step procedure to installing Dazuko:

change to kernel source directory

# cd /usr/src/linux-`uname -r`

copy in the current kernel configuration

# cp /boot/config-`uname -r` .config

configure the kernel, change capabilities to be a module

# make menuconfig
Security options -> Default Linux Capabilities <M>

exit, saving changes

build the kernel

# make

install kernel modules

# make modules_install

install kernel

# make install

build dazuko

# cd <path-to-dazuko-source>
# ./configure --kernelsrcdir=/usr/src/linux-`uname -r`
# make

install dazuko kernel module

# cp dazuko.ko /lib/modules/`uname -r`custom/kernel/security
# depmod -ae `uname -r`custom

reboot

# reboot

After the machine reboots you can load Dazuko with:

# modprobe dazuko

Fedora Core 2 doesn't use devfs so you will need to create the dazuko device:

# mknod -m 600 /dev/dazuko c 254 0

What are the known issues with Mandrake Linux?

A HOWTO for Mandrake 10.1 was written by Scott Grayban.

Mandrake 10.1 has two problems:

1. Linux Default Capabilities are built into the kernel. Capabilities must be built as a module in order to work with Dazuko. This is because the "capabiltity" module does not support stacking.

2. When you build your own kernel using Mandrake's kernel-source package, modules are installed in /lib/modules/2.6.8.1-10mdkcustom but the kernel goes by the original name of 2.6.8.1-10mdksmp. The easiest solution is to rename the "custom" modules directory to the name of the original directory.

Mandrake 10.0 has two problems:

1. Mandrake 10.0 does not have Security turned on in the default kernel (this is what generated all the error messages). It also means that you MUST rebuild the kernel with Mandrake 10.0.

2. After rebuilding the kernel, running "make modules_install" does not install the security modules.

If you know these problems, then it is possible to install Dazuko on Mandrake 10.0. Assuming you have installed the kernel-source package, here is the step by step procedure of what to do:

change to kernel source directory

# cd /lib/modules/`uname -r`/build

copy in the current kernel configuration

# cp /boot/config-`uname -r` .config

configure the kernel

# make menuconfig
Security options -> Enable different security modules [*]
Security options -> Default Linux Capabilities <M>

exit, saving changes

build the kernel

# make

install kernel modules

# make modules_install

create security module directory

# mkdir /lib/modules/`uname -r`/kernel/security

copy over security modules

# cp security/*.ko /lib/modules/`uname -r`/kernel/security

install kernel

# cp System.map /boot/System.map-`uname -r`
# cp .config /boot/config-`uname -r`
# cp arch/i386/boot/bzImage /boot/vmlinuz-`uname -r`

update lilo

# lilo

build dazuko

# cd <path-to-dazuko-source>
# ./configure
# make

install dazuko kernel module

# cp dazuko.ko /lib/modules/`uname -r`/kernel/security
# depmod -a

reboot machine

# reboot

Since Mandrake 10.0 uses devfs, there is nothing more that you must do. After rebooting, you can load dazuko with:

# modprobe dazuko

You can have Dazuko automatically load at startup by adding "dazuko" to /etc/modprobe.preload

What are the known issues with Gentoo Linux?

There are no known problems with Gentoo Linux. If you are using Capabilities for Linux 2.6, make sure that Dazuko is loaded first, before Capabilities.

A Gentoo package of Dazuko is available here.

How do I configure my Linux kernel source code?

There are several methods for configuring your source code. Once you are in the directory of your kernel source code, you can type:

$ make menuconfig

This brings up a ncurses-based configuration utility. Another option is a graphical (tcl-based) version:

$ make xconfig

Both configuration utilities do exactly the same thing. First, they read the contents of the .config file that is in the kernel source directory. After you choose "Save and Exit" all configuration information is saved in the .config file but also in the include/linux/autoconf.h file where the settings are actually used during compilation. This means that the important file for compiling Dazuko is autoconf.h.

However, most distributions do not keep a copy of the autoconf.h used when the kernel was compiled. Rather, they keep a copy of the .config file and save it as /boot/config-x.x.x. By copying this file over the .config file in the kernel source directory, then running the configuration utility and saving changes, you will have generated the autoconf.h that matches your kernel. This is what is meant by configuring the source code. Now Dazuko can be compiled and should insert properly into the kernel.

Note: It is assumed that you have the kernel source code that matches your running kernel. It is also assumed that you have a /boot/config-x.x.x file that matches your running kernel. Please pay attention to version numbers.

Note: It is not required that you run "make menuconfig" or "make xconfig" to generate autoconf.h from the .config file. Other options include:

$ yes "" | make config

or

$ make oldconfig

My system hangs during shutdown if Dazuko is loaded. Why?

When an application registers with Dazuko, the kernel will send all appropriate file access calls to that application. It is the responsibility of the application to allow or deny the access. If the application does not respond, the kernel will wait, causing what appears to be a lock up (i.e. your kernel can't open any files because it is waiting for the application to respond).

During shutdown, some operating systems issue a SIGSTOP which will freeze all running processes (for example, using the killall5 program under GNU/Linux). If one of these processes is registered with Dazuko, the problem mentioned above will occur. To avoid this problem, all applications using Dazuko should be terminated before the system shuts down. This is usually implemented with runlevel control scripts. Under GNU/Linux, another option is to add the /proc directory as an excluded path for Dazuko since killall5 needs to read files from this directory while all other processes are in the STOP state.

Dazuko seems to crash immediately after startup or as soon as an application tries to register itself. What is wrong?

This is almost certainly because you have compiled Dazuko with source code that does not match your running kernel. Even if you have the same kernel source files, they must also be configured exactly the same as your running kernel. The best (and safest) option is to compile and install a new kernel yourself. Then compile Dazuko using that same code. This way you can be sure that the running kernel matches Dazuko.

Linux: Most distributions offer their own version of the Linux kernel source code. You may prefer to build a new kernel from their provided source code rather than a "pure" Linux kernel. See FAQ for information about how to configure your Linux kernel source code.

With Linux 2.6 I am only getting ON_OPEN and ON_EXEC events. What is wrong?

For Linux 2.6, Dazuko uses the new LSM (Linux Security Model) security hooks. This does not fit well into the current design of Dazuko. For this reason Dazuko will report every access event as ON_OPEN or ON_EXEC (even if the events were something different). If your application requires each event to be properly identified with Linux 2.6, then it is currently suggested that you patch your kernel with RSBAC. Dazuko is included in the RSBAC patchset and is based on RSBAC API's. This allows Dazuko to correctly identify each access event type.

Other solutions for Linux 2.6 and Dazuko are currently being investigated and worked on. In the future this should not be a problem.

What are the known issues with the LSM (Linux Security Modules) system?

Traditionally the Dazuko module uses the LSM API on Linux 2.6 kernels, because this API was announced as the preferred method of interfacing with the kernel for the kind of tasks an on access scanner or activity logger needs to do. As Linux 2.6 development progressed this method turned out to be a maintenance headache since the LSM API changes with almost every kernel version. Recent uses of the LSM API by other projects like SE Linux and AppArmor even made it impossible for a second module like Dazuko to use the API as soon as one of these projects had their module loaded. Since newer distributions activate these modules by default and would not work correctly without them, trying to use Dazuko (or any other modules using the LSM API) changed from problematic to impossible.

One alternative is to employ an RSBAC enabled kernel. Dazuko interfaces cleanly with RSBAC while other applications don't suffer from its presence. But administering RSBAC is complex and can lead to being locked out of the machine when done inappropriately.

Another alternative is to hook syscalls on Linux 2.6 systems as well, just like it is done on Linux 2.2 and 2.4. The use of this method is discouraged by official kernel development policy, but it might be the only viable route to get your on access scanner working. Syscall hooking requires at least Dazuko version 2.3.0 and can be activated using the --enable-syscalls configuration option.

What are the known issues with Linux 2.6 syscall hooking?

Since interfacing with Linux 2.6 kernels via the LSM API turned out to be problematic and getting worse with every new stage of development, Dazuko version 2.3.0 (re)introduced the option to hook syscalls. Although this method is discouraged by the official kernel development policy, it is believed to work correctly and in a stable manner as it does on Linux 2.2 and Linux 2.4 systems.

It's essential to specify the System.map file at compile time (when the configure script is run) which correctly describes the kernel you want to load the module into. Using a module which was built based on incorrect information will risk your system's stability or break it completely.

Some distributions ship with a System.map file which incorrectly describes the data page the sys_call_table variable is residing at as being read only. Trying to act based on this information will result in a kernel BUG(). Since this situation can be detected at neither compile time nor run time, the Makefile created by the configure script may produce an IMPORTANT NOTICE warning that there may be problems when loading the module. The notice explains what could happen and what actions must be taken to successfully configure Dazuko.

Another method to run Dazuko on Linux 2.6 kernels without the LSM API being available is to employ an RSBAC enabled kernel.

Troubleshooting - "configure"

What does "error: kernel source files not found" mean?

The "configure" script was unable to determine the location of the Linux kernel source code. This is required in order to build Dazuko. Make sure you have installed the "kernel-source" package. If you have the kernel source code, you can specify its location using the "--kernelsrcdir=" argument. For example:

$ ./configure --kernelsrcdir="/usr/src/linux-2.6.5"

What does "error: capabilities are built-in to the kernel" mean?

The Linux Default Capabilities security module has been compiled into the kernel itself rather than as a separate module. The Linux Security Model for Linux 2.6 allows multiple security modules to be loaded, but only when the modules themselves allow others to be loaded. The "capability" module unfortunately does not allow other modules to be loaded. However, Dazuko does allow module "stacking". This means that if Linux Default Capabilities are compiled as a separate module, then Dazuko can be loaded first and "capability" loaded afterwards, allowing both security modules to exist together.

This means that you will need to build a new kernel with Linux Default Capabilities as a module, rather than built in.

What does "error: security module support must be enabled in your kernel" mean?

Dazuko uses the new Linux Security Model for Linux 2.6. This means that Security must be enabled in the kernel in order to support Dazuko. This will require you to configure and build a new kernel.

What does "error: unable to compile linux_conf utility" mean?

linux_conf is a little helper program to help the "configure" script determine your kernel configurations. If there was an error building this little utility, look in the temporary output file linux_conf_make.out for details.

What does "error: no usable exported symbols found" mean?

Under Linux 2.2 and 2.4 Dazuko uses the system call table to register with the kernel. If the required symbols for this table are not available, you may have a special version of the Linux kernel that will not work with Dazuko.

Troubleshooting - "make"

What does "make: command not found" mean?

The program "make" cannot be found on your system. This is usually because it is not installed on your system. Make sure you install the "make" package.

What does "gcc: command not found" mean?

The program "gcc" cannot be found on your system. This is usually because it is not installed on your system. Make sure you install the "gcc" package. If you use a compiler other than "gcc" then you can specify your compiler by setting the CC environment variable.

What does "Makefile: *** missing separator. Stop." mean?

This occurs on FreeBSD systems that are using GNU's "make" program instead of the FreeBSD "make". For FreeBSD it is important that you use FreeBSD's "make" and not the GNU version, "gmake".

When I run "make" I get many error messages. What is wrong?

The problem is almost certainly that you do not have the complete kernel source code.

Linux: If the configure script cannot find your source code, it will assume that it is located in /usr/src/linux. If it is not, you can either run configure using the --kernelsrcdir argument, rename the directory where the kernel source really is, or create a soft link. The problem may also be that your source code is not correctly configured. See FAQ for information about how to configure your Linux kernel source code.

Linux 2.6: Please make sure that you compile your Linux 2.6 kernel with CONFIG_SECURITY enabled. If you have not done this, you will get errors about implicit declarations of _security functions.

FreeBSD: Make sure you have installed the src/sys distribution and that you are using FreeBSD's make program (ie. "make" is not really "gmake").

Troubleshooting - inserting the module

What does "insmod: error inserting './dazuko.ko': -1 Invalid parameters" mean?

This is a general error. Please look in /var/log/messages to see what the real problem is. Usually kernel messages are logged to this file.

In /var/log/messages it says "kernel: There is already a security framework initialized, register_security failed. kernel: dazuko: failed to register". What is wrong?

This occurs because another security module is already loaded and is not allowing Dazuko to be loaded. In order to allow multiple security modules, Linux 2.6 supports stacking. Unfortunately some modules do not implement this, which makes it impossible to load additional security modules. Dazuko does support stacking correctly. If you make sure that Dazuko is the first loaded security module, than other modules can also be loaded.

Typically the problem is the "capability" module. You can verify that this is the problem by unloading the "capability" module, loading Dazuko, and then reloading the "capability" module:

# rmmod capability
# insmod ./dazuko.ko
# modprobe capability

If this was indeed the problem, you can usually configure your system to load modules in a specific order. This varies between Linux distributions.

When I run the GNU/Linux command "insmod" I get an error about a kernel version mismatch. What is wrong?

This means that the kernel you are running is not the same as the kernel source code you are using to compile Dazuko. Either configure the kernel source code to match the kernel you are running or, even better, compile and install a new kernel from the source code.

See FAQ for information about how to configure your Linux kernel source code.

When I run the GNU/Linux command "insmod" I get an error that is not mentioned here. What is wrong?

Make sure you are inserting the module as root. If this is the case, the problem may be that you are using a different compiler (or compiler version) to build the Dazuko module than you used to build your kernel. Building your own kernel will guarentee that this is not a problem.

Note: There may be multiple versions of a compiler installed at the same time. Be sure to use the correct one.

Linux 2.6: You may be trying to use multiple security modules. This is not well supported under Linux 2.6. As long as Dazuko is loaded before any other security modules, other security modules may also be loaded. Dazuko version 2.0.4 or higher is required for this to work correctly. Here are some tips for Linux 2.6 users:

Tip 1. Configure and build your kernel with:

"Enable different security modules" ENABLED
"Default Linux Capabilities" as MODULE <M>
"NSA SELinux Support" DISABLED

Note: If SELinux has been built into your kernel, you can usually disable it at boot with the boot parameter "selinux=0"

Tip 2. Dazuko for Linux 2.6 requires the "commoncap" module. This module must be loaded before Dazuko can be loaded:

# modprobe commoncap

Tip 3. Once Dazuko has been loaded, you are free to load other security modules such as "capability" or "root_plug" if needed.

Note: If Dazuko was not loaded as the primary (first) security module, it may not work correctly or it may not be possible to add additional modules after Dazuko. This is a limitation of the first module loaded, not Dazuko. If Dazuko is loaded as the first security module, stacking will be correctly supported.

See FAQ for information about how to install Dazuko for SuSE 9.1.

The command "insmod" produces a segmentation fault when I load a module with syscall hooking enabled.

Most likely you are using a kernel that has a read-only syscall table. The configure script should have provided an IMPORTANT NOTICE about this. You will need to try to re-configure Dazuko with an additional option --sct-readonly. Unfortunately, you will need to reboot your system before continuing because the Dazuko module caused a crash during its initialization. Since the true read-write status of the syscall table can be determined at neither compile time nor run time, you are forced to try one method (first as read-write) and then the other (as read-only).

The Linux 2.6 kernel crashes in the change_page_attr() routine when I load a module with syscall hooking enabled.

You have most likely configured Dazuko using the --sct-readonly option for a kernel that does not have a read-only system call table. This option should only be used if problems (such as those mentioned above) are present. Since the true read-write status of the syscall table can be determined at neither compile time nor run time, you are forced to try one method (first as read-write) and then the other (as read-only).

Troubleshooting - running the example program

When I run the example program, it says that it failed to register. What is wrong?

Make sure you are running the example program as root. If this is the case, the problem may be that you are using a different compiler (or compiler version) to build the Dazuko module than you used to build your kernel. Building your own kernel will guarentee that this is not a problem.

Note: There may be multiple versions of a compiler installed at the same time. Be sure to use the correct one.

Troubleshooting - running Dazuko-based programs

Dazuko compiles fine (or was shipped with my operating system) but doesn't work correctly on my 64-bit machine. What is wrong?

In versions up to and including 2.0 it was important that the kernel module and the IO library are built with the same bit width and endianess. Dazuko 2.1.0 introduced the so called REQSTREAM feature to support mixed bit width and/or endianess between applications and the kernel module. This allows you to run 32-bit applications on 64-bit kernels.

Running Dazuko-based 32-bit applications on 64-bit GNU/Linux and FreeBSD systems requires Dazuko (kernel module and IO-library) version 2.1.0 or above. Otherwise the applications won't work and may even crash the system. If you are having problems, then you probably have an older Dazuko kernel module and/or a 32-bit application that was compiled with an older Dazuko IO library.

When I run Dazuko-based applications I get "RA missing" messages in my logs. Is this a problem?

This happens when applications built with the IO library of version 2.1.0 or above run with kernel modules below version 2.1.0. The applications will work correctly and the "RA missing" message should be considered a warning in this situation.

Dazuko 2.1.0 introduced a new device protocol (called REQSTREAM). This protocol allows 32-bit applications to communicate with 64-bit kernels. A Dazuko-based application using version 2.1.0 or higher of the IO library will try to use this protocol first. However, older Dazuko kernel modules do not understand this protocol and generate the error message "RA missing". The IO library in the application will automatically recognize this and switch to an older protocol that the kernel module does understand. Since the IO library is able to communicate using the older protocols, this is not a problem.

Personal tools