Hello,
I know about a few people who would like to use some functionality of
the Magic Sysrq but don't want to enable all the functions it provides.
So I wrote a patch which should allow them to do so. It allows to
configure available functions of Sysrq via /proc/sys/kernel/sysrq (the
interface is backward compatible). If you think it's useful then use it :)
Andrew, do you think it can go into mainline or it's just an overdesign?
Thanks in advance for comments, bugreports
Honza
--
Jan Kara <[email protected]>
SuSE CR Labs
Jan Kara <[email protected]> wrote:
>
> I know about a few people who would like to use some functionality of
> the Magic Sysrq but don't want to enable all the functions it provides.
That's a new one. Can you tell us more about why people want to do such a
thing?
> So I wrote a patch which should allow them to do so. It allows to
> configure available functions of Sysrq via /proc/sys/kernel/sysrq (the
> interface is backward compatible). If you think it's useful then use it :)
> Andrew, do you think it can go into mainline or it's just an overdesign?
Patch looks reasonable - we just need to decide whether the requirement
warrants its inclusion.
There have been a few changes in the sysrq code since 2.6.9 and there are
more changes queued up in -mm. The patch applies OK, but it'll need
checking and redoing. There's a new `sysrq-f' command in the pipeline
which causes a manual oom-killer call.
> Jan Kara <[email protected]> wrote:
> >
> > I know about a few people who would like to use some functionality of
> > the Magic Sysrq but don't want to enable all the functions it provides.
>
> That's a new one. Can you tell us more about why people want to do such a
> thing?
For example in a computer lab at the university the admin don't want
to allow users to Umount/Kill (mainly to make it harder for users to
screw up the computer) but wants to allow SAK/Unraw.
Another (actually not so legitimate ;) example is that in e.g. SUSE
kernels sysrq is turned off by default (some people are afraid that it
could be a security issue) so most users have it turned off and hence
when the computer deadlocks, there's no debugging output. When you could
allow only debugging outputs then the fear about security would be much
smaller.
So in general it's mainly to make life a bit easier to
admins/developpers...
> > So I wrote a patch which should allow them to do so. It allows to
> > configure available functions of Sysrq via /proc/sys/kernel/sysrq (the
> > interface is backward compatible). If you think it's useful then use it :)
> > Andrew, do you think it can go into mainline or it's just an overdesign?
>
> Patch looks reasonable - we just need to decide whether the requirement
> warrants its inclusion.
>
> There have been a few changes in the sysrq code since 2.6.9 and there are
> more changes queued up in -mm. The patch applies OK, but it'll need
> checking and redoing. There's a new `sysrq-f' command in the pipeline
> which causes a manual oom-killer call.
OK, I'll rediff it againts latest -mm if we agree that inclusion
would be useful.
Honza
--
Jan Kara <[email protected]>
SuSE CR Labs
Jan Kara <[email protected]> wrote:
>
> > Jan Kara <[email protected]> wrote:
> > >
> > > I know about a few people who would like to use some functionality of
> > > the Magic Sysrq but don't want to enable all the functions it provides.
> >
> > That's a new one. Can you tell us more about why people want to do such a
> > thing?
> For example in a computer lab at the university the admin don't want
> to allow users to Umount/Kill (mainly to make it harder for users to
> screw up the computer) but wants to allow SAK/Unraw.
> Another (actually not so legitimate ;) example is that in e.g. SUSE
> kernels sysrq is turned off by default (some people are afraid that it
> could be a security issue) so most users have it turned off and hence
> when the computer deadlocks, there's no debugging output.
OK, fair enough. I'll merge the patch if you talk suse into enabling
sysrq-T and sysrq-P and sysrq-M by default ;)
Andrew Morton <[email protected]> writes:
> Jan Kara <[email protected]> wrote:
>>
>> I know about a few people who would like to use some functionality of
>> the Magic Sysrq but don't want to enable all the functions it provides.
>
> That's a new one. Can you tell us more about why people want to do such a
> thing?
>
>> So I wrote a patch which should allow them to do so. It allows to
>> configure available functions of Sysrq via /proc/sys/kernel/sysrq (the
>> interface is backward compatible). If you think it's useful then use it :)
>> Andrew, do you think it can go into mainline or it's just an overdesign?
>
> Patch looks reasonable - we just need to decide whether the requirement
> warrants its inclusion.
>
> There have been a few changes in the sysrq code since 2.6.9 and there are
> more changes queued up in -mm. The patch applies OK, but it'll need
> checking and redoing. There's a new `sysrq-f' command in the pipeline
> which causes a manual oom-killer call.
See also the patch I just posted to lkml.
I also thought of an improved way of selecting keys to enable.
Instead of an arbitrary bitmask, would it be possible to simply list
the keys you want to enable, such as "echo sku > /proc/sys/kernel/sysrq"?
--
M?ns Rullg?rd
[email protected]
> Andrew Morton <[email protected]> writes:
>
> > Jan Kara <[email protected]> wrote:
> >>
> >> I know about a few people who would like to use some functionality of
> >> the Magic Sysrq but don't want to enable all the functions it provides.
> >
> > That's a new one. Can you tell us more about why people want to do such a
> > thing?
> >
> >> So I wrote a patch which should allow them to do so. It allows to
> >> configure available functions of Sysrq via /proc/sys/kernel/sysrq (the
> >> interface is backward compatible). If you think it's useful then use it :)
> >> Andrew, do you think it can go into mainline or it's just an overdesign?
> >
> > Patch looks reasonable - we just need to decide whether the requirement
> > warrants its inclusion.
> >
> > There have been a few changes in the sysrq code since 2.6.9 and there are
> > more changes queued up in -mm. The patch applies OK, but it'll need
> > checking and redoing. There's a new `sysrq-f' command in the pipeline
> > which causes a manual oom-killer call.
>
> See also the patch I just posted to lkml.
OK, Andrew, are you accepting the patch? The sysrq should probably go
into SYSRQ_ENABLE_SIGNAL group...
> I also thought of an improved way of selecting keys to enable.
> Instead of an arbitrary bitmask, would it be possible to simply list
> the keys you want to enable, such as "echo sku > /proc/sys/kernel/sysrq"?
That would be possible of course but you'd have to do your own parsing
in kernel and you are not supposed to change the sysrq setting often - usually
just compute your favourite number, put it into boot scripts and you're
done. So I'm not convinced it's useful very much. The attached patch is
against 2.6.10-rc1-mm1 (I also added poweroff to SYSRQ_ENABLE_BOOT group
of functions).
Honza
--
Jan Kara <[email protected]>
SuSE CR Labs
Jan Kara <[email protected]> writes:
>> Andrew Morton <[email protected]> writes:
>>
>> > Jan Kara <[email protected]> wrote:
>> >>
>> >> I know about a few people who would like to use some functionality of
>> >> the Magic Sysrq but don't want to enable all the functions it provides.
>> >
>> > That's a new one. Can you tell us more about why people want to do such a
>> > thing?
>> >
>> >> So I wrote a patch which should allow them to do so. It allows to
>> >> configure available functions of Sysrq via /proc/sys/kernel/sysrq (the
>> >> interface is backward compatible). If you think it's useful then use it :)
>> >> Andrew, do you think it can go into mainline or it's just an overdesign?
>> >
>> > Patch looks reasonable - we just need to decide whether the requirement
>> > warrants its inclusion.
>> >
>> > There have been a few changes in the sysrq code since 2.6.9 and there are
>> > more changes queued up in -mm. The patch applies OK, but it'll need
>> > checking and redoing. There's a new `sysrq-f' command in the pipeline
>> > which causes a manual oom-killer call.
>>
>> See also the patch I just posted to lkml.
> OK, Andrew, are you accepting the patch? The sysrq should probably go
> into SYSRQ_ENABLE_SIGNAL group...
Don't miss the update I posted a few minutes later.
>> I also thought of an improved way of selecting keys to enable.
>> Instead of an arbitrary bitmask, would it be possible to simply list
>> the keys you want to enable, such as "echo sku > /proc/sys/kernel/sysrq"?
> That would be possible of course but you'd have to do your own
> parsing in kernel and you are not supposed to change the sysrq
> setting often - usually just compute your favourite number, put it
> into boot scripts and you're done. So I'm not convinced it's useful
> very much.
I'm not likely to use either of them, so I'll leave it to you.
--
M?ns Rullg?rd
[email protected]
>> >> I know about a few people who would like to use some functionality of
>> >> the Magic Sysrq but don't want to enable all the functions it provides.
>> >
>> > That's a new one. Can you tell us more about why people want to do such a
>> > thing?
Like me, I only need sysrq's S, U, B and sometimes K ;-)
How much space does it take anyway for the other sysrqs?
If it's below 8K (arbitrarily chosen limit) then I can live with "all sysrqs"
being in.
Jan Engelhardt
--
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, http://www.gwdg.de
> >> >> I know about a few people who would like to use some functionality of
> >> >> the Magic Sysrq but don't want to enable all the functions it provides.
> >> >
> >> > That's a new one. Can you tell us more about why people want to do such a
> >> > thing?
>
> Like me, I only need sysrq's S, U, B and sometimes K ;-)
> How much space does it take anyway for the other sysrqs?
> If it's below 8K (arbitrarily chosen limit) then I can live with "all sysrqs"
> being in.
It's not about the kernel size but about allowing user to invoke just
some functions and not the other (see my other mail).
Honza
--
Jan Kara <[email protected]>
SuSE CR Labs
> It's not about the kernel size but about allowing user to invoke just
>some functions and not the other (see my other mail).
That's like giving a user m$ windows without the ctrl+alt+del functionality,
if you omit considering that either os has a different level of stability.
But I like the idea. Maybe a bitmask which can be set via /proc/sys/.../xxx?
Jan Engelhardt
--
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, http://www.gwdg.de
On Fri, Oct 29, 2004 at 03:24:20AM -0700, Andrew Morton wrote:
> OK, fair enough. I'll merge the patch if you talk suse into enabling
> sysrq-T and sysrq-P and sysrq-M by default ;)
you already have those available if /proc/sys/kernel/sysrq is 0.
alt-scrolllock / ctrl-scrolllock / shift-scrolllock.
Dave
On Fri, Oct 29, Dave Jones wrote:
> On Fri, Oct 29, 2004 at 03:24:20AM -0700, Andrew Morton wrote:
> > OK, fair enough. I'll merge the patch if you talk suse into enabling
> > sysrq-T and sysrq-P and sysrq-M by default ;)
>
> you already have those available if /proc/sys/kernel/sysrq is 0.
>
> alt-scrolllock / ctrl-scrolllock / shift-scrolllock.
How do I trigger that via serial/hvc?
--
USB is for mice, FireWire is for men!
sUse lINUX ag, nÜRNBERG
Hi!
> I know about a few people who would like to use some functionality of
> the Magic Sysrq but don't want to enable all the functions it provides.
> So I wrote a patch which should allow them to do so. It allows to
> configure available functions of Sysrq via /proc/sys/kernel/sysrq (the
> interface is backward compatible). If you think it's useful then use it :)
> Andrew, do you think it can go into mainline or it's just an overdesign?
Actually, there's one more thing that wories me... Original choice of
PC hotkey (alt-sysrq-key) works *very* badly on many laptop
keyboards. Like sysrq is only recognized with fn, but key is not
recognized when you hold fn => you have no chance to use magic sysrq.
Perphaps sysrq could be made prefix notation? Like alt-sysrq, release,
press s is sync?
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Hi!
> > > I know about a few people who would like to use some functionality of
> > > the Magic Sysrq but don't want to enable all the functions it provides.
> >
> > That's a new one. Can you tell us more about why people want to do such a
> > thing?
> For example in a computer lab at the university the admin don't want
> to allow users to Umount/Kill (mainly to make it harder for users to
> screw up the computer) but wants to allow SAK/Unraw.
In that particular computer lab, admin is *****, and paranoid one,
too. He's more worried about security that functionality, and then you
find suid bash in /tmp and learn that root password is name of the
laboratory, with first character uppercased. Heh.
BTW interesting things can be done with sak alone. (It is bye-bye
vlock -a, right?). Changing console log-level and info-prints could
lead to user seeing some info he's not allowed to see [perhaps part of
some password are in the registers because they are now memcopied?],
but I agree allowing that is probably okay.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
On Sunday 31 October 2004 01:52 pm, Pavel Machek wrote:
> Hi!
>
> > I know about a few people who would like to use some functionality of
> > the Magic Sysrq but don't want to enable all the functions it provides.
> > So I wrote a patch which should allow them to do so. It allows to
> > configure available functions of Sysrq via /proc/sys/kernel/sysrq (the
> > interface is backward compatible). If you think it's useful then use it :)
> > Andrew, do you think it can go into mainline or it's just an overdesign?
>
> Actually, there's one more thing that wories me... Original choice of
> PC hotkey (alt-sysrq-key) works *very* badly on many laptop
> keyboards. Like sysrq is only recognized with fn, but key is not
> recognized when you hold fn => you have no chance to use magic sysrq.
>
Actually if I understand it correctly it is Alt-PrtScrn-key - just let go
of your "Fn" key and I think it will work fine. At least it does on my
laptop.
--
Dmitry
Pavel Machek <[email protected]> writes:
> Actually, there's one more thing that wories me... Original choice of
> PC hotkey (alt-sysrq-key) works *very* badly on many laptop
> keyboards. Like sysrq is only recognized with fn, but key is not
> recognized when you hold fn => you have no chance to use magic sysrq.
Doesn't it work to release fn (without releasing sysrq) before typing key?
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux AG, Maxfeldstra?e 5, 90409 N?rnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Hi!
> > > I know about a few people who would like to use some functionality of
> > > the Magic Sysrq but don't want to enable all the functions it provides.
> > > So I wrote a patch which should allow them to do so. It allows to
> > > configure available functions of Sysrq via /proc/sys/kernel/sysrq (the
> > > interface is backward compatible). If you think it's useful then use it :)
> > > Andrew, do you think it can go into mainline or it's just an overdesign?
> >
> > Actually, there's one more thing that wories me... Original choice of
> > PC hotkey (alt-sysrq-key) works *very* badly on many laptop
> > keyboards. Like sysrq is only recognized with fn, but key is not
> > recognized when you hold fn => you have no chance to use magic sysrq.
> >
>
> Actually if I understand it correctly it is Alt-PrtScrn-key - just let go
> of your "Fn" key and I think it will work fine. At least it does on my
> laptop.
Okay, it looks like I can actually type it on all notebooks here if I
try hard enough. On HP machines, the trick is
alt,fn,sysrq,releasealtandfn,key. Ouch.
The thing that confused me was some SuSE script redirecting messages
to other tty, so I saw nothing after magic-9, and assumed I did not
press it correctly.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Pavel Machek <[email protected]> said on Sun, 31 Oct 2004 19:52:22 +0100:
> Hi!
>
> > I know about a few people who would like to use some functionality of
> > the Magic Sysrq but don't want to enable all the functions it provides.
> > So I wrote a patch which should allow them to do so. It allows to
> > configure available functions of Sysrq via /proc/sys/kernel/sysrq (the
> > interface is backward compatible). If you think it's useful then use it :)
> > Andrew, do you think it can go into mainline or it's just an overdesign?
>
> Actually, there's one more thing that wories me... Original choice of
> PC hotkey (alt-sysrq-key) works *very* badly on many laptop
> keyboards. Like sysrq is only recognized with fn, but key is not
> recognized when you hold fn => you have no chance to use magic sysrq.
>
> Perphaps sysrq could be made prefix notation? Like alt-sysrq, release,
> press s is sync?
It seems to already do that for me.
What I do have, is some bizzaaro hardware that gives some weird escape
keycode for alt-sysreq, so alt-sysreq s,u,b doesn't work. Could be the
fact that it is a PS2 keyboard plugged into an old AT style connector,
or something else, but I don't know where to start looking to fix
it. It's a relatively recent and relatively clean debian install, and
I don't know what I did wrong - I noticed this behaviour pretty much
from the start.
Maybe I'm asking for not just alt to be the prefix, maybe give the
choice of ctrl, etc. But I have a feeling ctrl is kinda funky on the
console of this machine as well.
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
ALU n. Arthritic Logic Unit, or (rare) Arithmetic Logic Unit. A random
number generator supplied as standard with all computer systems. --unk
>
> > It's not about the kernel size but about allowing user to invoke just
> >some functions and not the other (see my other mail).
>
> That's like giving a user m$ windows without the ctrl+alt+del functionality,
> if you omit considering that either os has a different level of stability.
Yes. Some of the sysrq are considered insecure - for example OOM
kill, which was added lately, can be used to kill some process and I
could imagine security implications from cleverly killing syslogd (or
some other important process) by it. OTOH some other functionalities
are useful and safe...
> But I like the idea. Maybe a bitmask which can be set via /proc/sys/.../xxx?
And that is exactly what the patch does ;).
Honza
--
Jan Kara <[email protected]>
SuSE CR Labs
> On Fri, Oct 29, 2004 at 03:24:20AM -0700, Andrew Morton wrote:
> > OK, fair enough. I'll merge the patch if you talk suse into enabling
> > sysrq-T and sysrq-P and sysrq-M by default ;)
>
> you already have those available if /proc/sys/kernel/sysrq is 0.
>
> alt-scrolllock / ctrl-scrolllock / shift-scrolllock.
I admit I didn't know that but I also just found out that there's no
scrolllock on my notebook keyboard... But anyway thanks for info.
Honza
--
Jan Kara <[email protected]>
SuSE CR Labs