linux-kernel - Re: [PATCH] 2.6.27: add a kernel hacking option to protect kernel memory between different modules

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 03 Nov 2008 07:29:39 -0500
From:	Valdis.Kletnieks@...edu
To:	Pengfei Hu <hpfei.cn@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] 2.6.27: add a kernel hacking option to protect kernel memory between different modules

On Sun, 02 Nov 2008 22:15:11 +0800, Pengfei Hu said:

> efficiency and simplicity. But now more and more embed application use
> linux. In the traditional embed system, all the task run in kernel and
> share the memory. Using kernel thread can immigrate these application
> easily. So there will be many task run in the kernel.

So the target is embedded systems doing all sorts of stupid-crazy kernel
thread tricks...

> +          Change page table's present flag to prevent other module's accidental
> +          access. This results in a large slowdown and waste more memory, but
> +          helps to find certain types of memory corruptions.

And your solution is to create a large slowdown, which will just make them
look for ways to make it go faster... perhaps including even *more* stupid-crazy
kernel thread tricks?

Can you point at any bugs/failure modes that this patch would detect, but
would *not* be found by any of the already-existing memory debugging tools?

Is it at all sane to expect that a reasonable setting can be done for
things like slab and vmalloc?  What happens when multiple modules allocate
out of the same slab, or even worse, get vmalloc/kmalloc for *different*
things on the same physical page?  It seems that unless you can separate
memory allocations by module, this isn't going to provide a lot of help in
finding memory allocation/usage issues.

And I won't even *start* on all the data structures in the kernel that are
shared across modules - do a 'cat /proc/slabinfo' or equivalent, and ask
yourself how many of those you could tag as "private to module A", or
"read/write by B, read-only by C, no-access by others".

You *really* don't want to re-invent the IBM MVS-style "GETMAIN/FREEMAIN SP=nnn"
mess. Trust me on this one. ;)

Content of type "application/pgp-signature" skipped