В Срд, 29/12/2010 в 23:28 +0100, Glenn пишет: > At 0:06 +0200 30/12/10, Timo Juhani Lindfors wrote: > >Glenn <glenn.mh...@gmail.com> writes: > >> Maybe it might be a good idea to embed grsecurity in the kernel - for > >> two reasons: > > > >I think the main goal should be to upstream our changes, not add new > >changes that are not upstream. > > > >> * Debug programs and drivers (faster debugging?) > > > >What has grsecurity to do with debugging? > ... > > > On there home page they write: > > # Prevention of arbitrary code execution, regardless of the technique > used (stack smashing, heap corruption, etc) > # Prevention of arbitrary code execution in the kernel > # Randomization of the stack, library, and heap bases > # Kernel stack base randomization > # Protection against exploitable null-pointer dereference bugs in the kernel > > E.g. Some buffer overflows will be stopped.
How do you see 'stopped buffer overflow'? Will it not overflow? I think it will still overflow, but no harm to security. Of course at cost of additional checks :) In general: This is just small phone, not super- secure device with highly secure data serving public available services. All this will have negative impact on performance and battery life. You welcome to research how it will work - just build kernel, run lmbench and see how much slower things will be, and use it if you like to build super-secure device, if would be interesting to read summary of your reserch, but FR stacks has thousands of software bugs, better fix em in normal way, not workaround by adding another chuck of self-checking. Gennady. _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community