grsecurity & skas3

[phil]

Hi everyone!

I know that question had already been posted a while ago, but maybe something has changed in the meantime.

The skas3 patch is quite useful when running usermode-linux (as far as I heard), but unfortunately it doesn't apply cleanly on a grsecurity-patched 2.4.27. The main conflicts seem to be the do_mmap_pgoff / __do_mmap_pgoff calls, maybe it could be solved by adding extra-parameters for struct mm_struct *mm in do_mmap_pgoff that can be passed through to __do_mmap_pgoff or whatever - I only have limited knowledge of kernel hacking.

So - has anybody succeeded in running kernel 2.4.27 with grsec and skas3? Or is there a similar mechanism in grsecurity that speeds up the host system like skas3 does?

Last but not least - is that skas3 patch really an improvement of speed that can be feeled, not just measured (like in: "wow, performance increased by 0.3853 percent!")?

Kind regards,

Phil


(keywords: uml, user-mode-linux, Separate Kernel Address Space, skas, skas-3)

[torne]

The skas3 patch for UML makes a huge performance difference (but it's still much slower than Xen.. mmm.. Xen..)

[phil]

Xen.. mmm.. Xen.. what?

edit: okay, I think I found it: http://www.cl.cam.ac.uk/Research/SRG/netos/xen/

Well, it seems that for Xeno the host kernel needs to be patched even more badly than for skas3. Not really an alternative, although it might be faster than UML.

[phil]

okay, I'm trying to merge the skas3 patch with a grsecurity 2.0.1 patched kernel 2.4.27, but there are some parts I need a little help with.

[*] PAX_MPROTECT
Grsecurity modifies linux/mm/mprotect.c.
skas3 renames the function sys_mprotect to do_mprotect and adds an argument of type struct mm_struct, then inserts a wrapper called sys_mprotect that invokes do_mprotect with the new parameter current->mm.
In the original sys_mprotect (that's now called do_mprotect), current->mm is being replaced by mm.
IMHO these changes shouldn't affect grsecurity's changes, do they?

[*] do_mmap_pgoff and __do_mmap_pgoff (linux/mm/mmap.c)
Grsecurity rewrote parts of do_mmap_pgoff sothat it calls a newly introduced function __do_mmap_pgoff. skas3 modifies the argument list of do_mmap_pgoff and adds an argument of type struct mm_struct. Also it removes the previous deklaration & definition of mm = current->mm.
What should I do here - should I add the same argument (struct mm_struct *mm) to __do_mmap_pgoff and remove the line "struct mm_struct * mm = current->mm;"? Should I replace current->mm with mm in these functions? And - what about linux/fs/binfmt_elf.c where do_mmap_pgoff and __do_mmap_pgoff are being called - should I add a parameter current->mm?

- Phil

[torne]

The host for Xen is Xen, not a modified Linux; it's a freestanding virtual machine monitor. I wasn't suggesting it; I just worked on it for a good while =)

[phil]

Can you give me a short overview of what Xen is?
As far as I understood Xen is a patch for the linux kernel that encapsulates (? - dunno the right word) the original linux kernel in a privileged virtual machine and it is possible to run several virtual machines in parallel to the original linux, right?
Dunno, but I don't like the idea of degrading the master linux machine to a guest vm of a foreign os

[torne]

Xen is a free-standing virtual machine monitor for x86 boxes, similar to the server-side version of VMWare (GSX and ESX) in that the 'host' OS is not a full operating system. It's pretty much the 'minimum required' kernel to run in ring 0 - it can do virtualisation, memory management and access control, and that's about it. It's not based on Linux, though some of the code was sourced from the Linux kernel (Xen is under the GPL). The 'host' OS is just the Xen kernel, and has no interface to the outside world except the serial console for debugging. A guest OS that wants to run on Xen has to be ported to run in ring 1 - a halfway-house between the UML and VMWare approaches. Most system-level access (managing user-level processess..etc) can be done without making Xen calls, and there is a fast-path system call handler that allows userspace apps to make calls into their guest OS's kernel (with the ring 1 transition) without having to transition through ring 0 to Xen. Linux has been ported as XenoLinux, a patch to the Linux kernel much like the UML one, except using Xen's hypercall interface instead of running in userspace and using Linux's system call interface. One of the BSDs is being ported too, though I'm not involved in that effort. I worked on porting the Windows NT kernel a while back and we made good progress, but currently that port is only available to MS Shared Source licencees and is still experimental in any case. You can run any number or combination of guest OSes, as long as they are all ported.

There is no 'master Linux machine' - the first guest OS started (which currently has to be Linux, but this restriction should vanish eventually) is considered privileged in that it has the ability to start and stop other guests, but those permissions can be given away or restricted; only Xen is special. In the latest CVS of Xen, hardware drivers can run in isolated guest OSes (using native Linux drivers, for example) without ring-0 privileges, only the inter-OS communication being handled by Xen. This makes Xen much smaller and simpler, and means it's possible for your system to survive a device driver crash.

Xen's paravirtualisation is much more efficient than UML (with or without skas3, because of tricks like direct system calls to the guest OS kernels) and beats the pants off VMWare (which has to do binary rewriting in exchange for the ability to run unmodified operating systems). It also does a better job of performance isolation than UML, making it extremely hard for one guest to deprive the others of resources.

This has wandered a bit off-topic, but, ah well. GRSec would still apply to XenoLinux (though the merging would still cause problems, especially as guest OSes can't write directly to their page tables for security reasons and must buffer updates through Xen), as the tricks it uses like VM mirroring and such would still work through paravirtualisation. Xen itself shouldnt need security help, though, as it doesn't communicate with the outside world directly and keeps itself and each guest OS strictly isolated.

[phil]

Wow thanks for the info, sounds very interesting. I'll give it a try

[phil]

Okay, here's a patch that contains grsecurity-2.0.1, devicemapper and skas3-v3. Applies to 2.4.27 and returned no errors when compiling. I didn't had time to test it, though. Feel free to give it a try and tell me if it's working

[phil]

grsecurity + skas3 + devicemapper for 2.4.28

[kaio]

It's applicabile uml + grsec with kernel 2.6.11?

Thanks in advice!

[phil]

I don't think so. It applies to 2.4.28 (which reminds me I should add a more recent patch for 2.4.30).

[kaio]

where is that patch?

thanks!

[phil]

where is that patch?

See above for 2.4.28. There's yet no skas3/grsec patch for 2.4.30, but I'm working on it.

[kaio]

In order to have a kernel 2.4.28 with uml and grsec supports, what patches must i apply?
I downloaded vanilla kernel (official kernel.org 2.4.28) and i applied grsec patches, but there is'nt official uml patches for this kernel.
Where is the uml patch for this kernel?
What is the order to apply uml+ grsec patches in order to have an uml kernel with support uml+grsec?

Thanks for your patience