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
To:	Pengfei Hu <>
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

Powered by blists - more mailing lists