Re: [PATCH]: Add Network Sysrq Support

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

On 22/06/11 11:54, Florian Westphal wrote:
> Prarit Bhargava <prarit@redhat.com> wrote:
>
> [ cc'd John Haxby, who worked on xt_SYSREQ ]
>
>> On 06/21/2011 06:58 PM, David Miller wrote:
>>> From: Florian Westphal <fw@strlen.de>
>>> Date: Wed, 22 Jun 2011 00:56:45 +0200
>>>> This is one of the reasons why I still think that
>>>> xt_SYSREQ would be the better solution, you get all
>>>> kinds of filtering features for free.
>>>>
>>>> You could even use crazy things like '-m time' to restrict
>>>> sysreq availability to working hours and whatnot.
>>>>
>>> Agreed.
>> Using the netfilter xt-SYSRQ code seems to store the entered code and
>> execute it later after the system has returned to a normal state....
>> which is much too late to be useful.
> The target handler of the kernel part invokes handle_sysrq(),
> I don't see any delaying/queueing?
>
> FWIW, the old discussion is in the archives:
> search for subject "nf-next: sysrq and condition 20100421" from Jan
> Engelhardt, or try
> http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/33615/focus=34808
>
> As far as i understand the use case described by John Haxby matches yours.
>
> 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.

The xt_SYSRQ calls handle_sysrq() in BH context, much the same context
as ping is handled in.  (Actually, it's likely xt_SYSRQ will work even
if ping doesn't since nothing has to come back.)

It's possible for xt_SYSRQ to fail.   My usual case for failure was
simply not enabling it :-)  However, as you typically have to fight your
way through iptables to get to xt_SYSRQ then you can get into trouble
that way.

Although I wasn't sure that it could happen, it's also possible that the
cryptographic functions can get in your way.  xt_SYSRQ does its best to
avoid problems by pre-allocating everything it can so there is as little
as possible to do when it is needed, but it is possible for it to fail.

The module that Patrick McHardy suggested works up to a point:
handle_sysrq() can still be called in BH context but unfortunately I
couldn't get it working for IPv6: the necessary hook isn't implemented
for IPv6 (or rather, it wasn't, I don't know if something has changed
since then).

jch