On 28/04/10 15:43, John Haxby wrote:
kdboe (or kgdboe) isn't part of the kernel and I don't think it necessarily fits all the use cases for xt_SYSRQ. The one I have in mind is where there is a non-kernel hacker whose machine has got into trouble. The poor harrassed sys admin (in this case) has configured netconsole and knows that sysrq-t and sysrq-m are useful as a first attempt at passing useful information to someone who knows what might be going on and that sysrq-c to get a crash dump will also be useful. (This represents quite a few of the better sys admins that I come across.) xt_SYSRQ is likewise easy to set up and easy to use. It's true that k(g)dboe would provide this kind of information provided that the debuginfo was present on the target machine and the environment was such that any sort of debugging over netconsole was sufficiently secure ... (is it at least as secure as the xt_SYSRQ controls?)
I really must read what I've written more carefully. I should have gone on to say that I don't see that k(g)dboe will be viable in this use case although for someone actually debugging a kernel on a machine that they have access to xt_SYSRQ leaves an awful lot to be desired :-) But that isn't the common use-case I see -- the one I see is where the sys admins used to have a "crash trolley" which was a console and PS/2 keyboard which they could plug into a machine to get some information, but as many rack machines no longer have anything PS/2 and USB hot plug is unlikely to work on a sick machine we need a sufficiently light mechanism that it will work in most cases (xt_SYSRQ is careful to pre-allocate most of the resources it will need).
And then I should have said that moving on to the possibility of a standalone module and that ...
I was running over the design of a standalone module in my head on the way in this morning. It seems fairly straightforward, but as I started adding in necessary requirements like limited IP addresses (which I know are not actually secure), limited interfaces (which are more secure in a controlled physical environment), user-space control and so on the more it was sounding as though it would just be a cut-down iptables. And then, of course, that begs the question "why don't you leave all that extra stuff to iptables?"
So unless I'm missing something obvious and different, I don't see that a standalone module is going to be lightweight enough to be acceptable.
Sorry for not making filling this parts in earlier. jch -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
