Can we modify the int 0x80 routine?

Question

1. How does linux 2.6 differ from 2.4?
2. Can we modify the source kernel?
3. Can we modify the int 0x80 service routine?

Answer 1

UPDATE:
1. the 0x80 handler is essentially the same between 2.4 and 2.6, although the function called from the handler is called by the 'syscall' instruction handler for x86-64 in 2.6. 2. the 0x80 handler can be modified like the rest of the kernel.
3. You won't break anything by modifying it, unless you remove backwards compatibility. E.g., you can add your own trace or backdoor if you feel so inclined. The other post that says you will break your libs and toolchain if you modify the handler is incorrect. If you break the dispatch algorithm, or modify the dispatch table incorrectly, then you will break things.
3a. As I originally posted, the best way to extend the 0x80 service is to extend the system call handler.

As the kernel source says:

What:           The kernel syscall interface
Description:
        This interface matches much of the POSIX interface and is based
        on it and other Unix based interfaces.  It will only be added to
        over time, and not have things removed from it.

    Note that this interface is different for every architecture
    that Linux supports.  Please see the architecture-specific
    documentation for details on the syscall numbers that are to be
    mapped to each syscall.

The system call table entries for i386 are in:
arch/i386/kernel/syscall_table.S

Note that the table is a sequence of pointers, so if you want to maintain a degree of forward compatibility with the kernel maintainers, you'd need to pad the table before placement of your pointer.

The syscall vector number is defined in irq_vectors.h
Then traps.c sets the address of the system_call function via set_system_gate, which places the entry into the interrupt descriptor table. The system_call function itself is in entry.S, and calls the requested pointer from the system call table.
There are a few housekeeping details, which you can see reading the code, but direct modification of the 0x80 interrupt handler is accomplished in entry.S inside the system_call function. In a more sane fashion, you can modify the system call table, inserting your own function without modifying the dispatch mechanism.

In fact, having read the 2.6 source, it says directly that int 0x80 and x86-64 syscall use the same code, so far. So you can make portable changes for x86-32 and x86-64.
END Update

The INT 0x80 method invokes the system call table handler. This matches register arguments to a call table, invoking kernel functions based on the contents of the EAX register. You can easily extend the system call table to add custom kernel API functions.

This may even work with the new syscall code on x86-64, as it uses the system call table, too.

If you alter the current system call table in any manner other than to extend it, you will break all dependent libraries and code, including libc, init, etc.

Here's the current Linux system call table: http://asm.sourceforge.net/syscall.html

Answer 2

1. It's an architectural overhaul. Everything has changed internally. SMP support is complete, the process scheduler is vastly improved, memory management got an overhaul, and many, many other things.
2. Yes. It's open-source software. If you do not have a copy of the source, you can get it from your vendor or from kernel.org.
3. Yes, but it's not advisable because it will break libc, it will break your baselayout, and it will break your toolchain if you change the sequence of existing syscalls, and nearly everything you might think you want to do should be done in userspace when at all possible.