Hi!
> > [..] combined
> > with an automatic oops/panic/bug-report this would be _very_ useful I think.
>
> That would be nice addition IMHO. It'll be more complex since it'll
> involve netconsole dumping and passing the klive session to the kernel
> somehow (userland would be too unreliable to push the oops to the
> server). The worst part is that oops dumping might expose random kernel
> data (it could contain ssh keys as well), so I would either need to
> purify the stack/code/register lines making the oops quite useless, or
> not to show it at all (and only to show the count of the oopses
> publically). A parameter could be used to tell the kernel if the whole
> oops should be sent to the klive server or if only the notification an
> oops should be sent (without sending the payload with potentially
> sensitive data inside).
Well, you could remove everything that is not valid kernel text from backtrace.
That should make ssh keys non-issue and still provide usefull information.
Oh and you probably want to somehow identify modified kernels.
Otherwise if I do some development on 2.3.4-foo5, you'll get many oopsen
caused by my development code... it is getting complex.
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
On Wed, Aug 31, 2005 at 08:20:51PM +0200, Pavel Machek wrote:
> Well, you could remove everything that is not valid kernel text from backtrace.
What if the corruption wrote the ssh key inside a the kernel text?
As suggested before, I suspect the only way would be to make it
optional.
> Oh and you probably want to somehow identify modified kernels.
> Otherwise if I do some development on 2.3.4-foo5, you'll get many oopsen
> caused by my development code... it is getting complex.
Agreed, however there's no way to do it reliably, since if you apply a
patch before compiling the kernel, there's no way to know it unless we
do a md5sum of the whole source at every compilation and that would be
too slow ;)
Thanks.