Breaking security on x86_64 in four simple steps

  1. Begin by putting kernel and processes in separate address spaces, thinking that maximal isolation is a good thing and that we can still map parts of the kernel in the process’ address space later if it’s needed for performance reasons.
  2. Discover that it’s impossible to make a context switch on x86 if the kernel and the process do not share part of their address space.
  3. Map the kernel in the process’ address space as normal data, forget to make it unaccessible from non-privileged process.
  4. Congratulations, process may now read and write the kernel’s data freely !

Well, still I’m happy that I discover this bug now and not ages later…

Apart from breaking my codebase, I’ve been switching to makefiles for compilation, in order to use a more standard solution. At the moment, it’s a bit imperfect, as modifying a single header causes large parts of the codebase to be rebuilt. If this becomes a major annoyance in the future, as build times grow, I’ll consider using a more fine-grained dependency model at the cost of higher complexity in the building process.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s