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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |