lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH2-hcLoz591mduTVPtFd0ZOEzMNSzhU108qqvv-ZWre7+jm9Q@mail.gmail.com>
Date:   Mon, 13 Nov 2023 22:09:50 +0100
From:   Tomáš Mudruňka <tomas.mudrunka@...il.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Jiri Slaby <jirislaby@...nel.org>, linux-kernel@...r.kernel.org,
        linux-serial@...r.kernel.org
Subject: Re: [PATCH] /proc/sysrq-trigger: accept multiple keys at once

po 13. 11. 2023 v 19:33 Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
> What did you just break where people would send a string and only relied
> on the first character being checked?  This might not be ok to do.

It truly might not be ok. But i hope you will not consider me impolite
if i open further discussion. Is this actual use case for some people?
I understand that it might be, but currently i can only think about
this being done by mistake, rather than on purpose... are you aware of
any software actually leveraging this feature?

Please also note that there is really good use case for this. if i do
the REISUB bash loop as suggested, the bash will be killed during E or
I and the rest of emergency procedure will not finish. Therefore i
really think it makes sense to be able to pass whole sysrq batch to
the kernel at once.

In case you are sure that this is a bad idea, i can suggest
alternative approach. only activate the "bulk mode" when first
character is '_' (underscore).
User would then be able to do
echo _reisub > /proc/sysrq-trigger

Would you prefer if i do it this way? In my opinion it does introduce
little unnecessary complexity, to fix something that might arguably
not be actual issue. I mean... we still have /dev/null in case people
need to discard some extra characters. :-)
But if you think it's better to stay on safe side, i think it's viable
option as well...

> Also, no documentation update?

Will fix this one in v2.

> thanks,
>
> greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ