Re: [gentoo-hardened] grsec in qemu/kvm gives PAX: attempted to modify kernel code

On 5 Jul 2007 at 10:19, Natanael Copa wrote:

> I'm tryning to run a gentoo hardened kernel as a qemu guest but PAX is
> not happy. It works fine in vmware.

'fine' is a relative word here, see below ;-).

> Any ideas how to find out what this really is?
>
> I tried kvm-28 (with kvm-intel) and qemu-0.9 (non kvm).
[...] 
> PAX: swapper:1, uid/euid: 0/0, attempted to modify kernel code at virtual address c0551c08
>  printing eip:
> 0000e9d7

this says that the kernel wanted to write to some otherwise read-only
area (as created/enforced by KERNEXEC that the hardened kernel uses).
after some decoding of the oops code i figured that it must come from
the free_initmem() function where KERNEXEC activates the read-only
mappings for the kernel. and after a split second of reflection one
can figure out that there's indeed a bug in there in that KERNEXEC
can shoot itself in the foot so to speak.

while going through the kernel's page directory to modify the writable
entries to become read-only (covering the read-only kernel virtual
address range), it will make the page directory (swapper_p[gm]_dir)
read-only as well - even before it has modified the last needed entry
in it -> instant page fault as you reported it, but only *if* the TLBs
get flushed somehow during this short tight loop.

apparently the intercept logic in qemu/kvm does/causes this TLB flush
while vmware doesn't (or it has some extra detection logic that still
enables writes to this read-only area, not that good then as it
circumvents security, and to be honest, i've never once seen vmware
fault here for the past 4 years, so my bet is on the extra logic).

for an extra confirmation, can you post the output of

   egrep 'swapper_p|MODULES_| _data' System.map

?

in any case, thanks for the report, i'll fix it for 2.6.22.

-- 
gentoo-hardened@g.o mailing list