Re: [PATCH]: Add Network Sysrq Support

[John Haxby <john.haxby@oracle.com>]

On 22/06/11 11:54, Florian Westphal wrote:
> Patrick McHardy suggested an alternative standalone method involving
> encapsulation sockets; perhaps the reasons why this path was not chosen
> have changed.
>
> I think that a standalone module (i.e. not requiring netfilter) that
> runs the sysreq handling after all netfilter hooks would be optimal,
> but I don't see a simple method to implement that.

Having just read the entire thread I have some different comments.

I think I mentioned that the standalone module didn't fly because I was
using an encapsulation socket: this preserved the ability to protect the
sysrq with iptables and also kept things nice and simple.  Unfortunately
that also meant I lost IPv6 ....

One of the comments in the thread (sorry, I've lost the attribution, not
to mention the exact quote) was that you would be crazy to run this in
production.    Hmmm.   One of the principle use cases of this is
precisely to run the code in production: machines in production do go
AWOL for all kinds of reasons and being able to run sysrq-m, t, s and c
is particularly useful.   It would be nice to be able to go up to the
machine and type on its keyboard.  If only it was even on the same
continent.   If only it a keyboard.  Or even a PS/2 keyboard socket
(getting a USB keyboard to configure itself when the machine is wedged
is, well, unlikely).

The changes I made to the xt_SYSRQ hashing a while back to avoid things
like replay were precisely because it needs to be run in a production
environment.   I've just submitted a patch that makes replay to other
machines that have the same password less likely to succeed, again, with
a view to how this thing would be used in production.

Sorry if I've repeated some things that have already been said.

jch