linux-kernel - Re: [PATCH] powerpc/xmon: Dont register sysrq key when kernel param xmon=off

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 15 Feb 2018 12:13:03 +0530
From:   Vaibhav Jain <vaibhav@...ux.vnet.ibm.com>
To:     Michael Ellerman <mpe@...erman.id.au>,
        Balbir Singh <bsingharora@...il.com>
Cc:     "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
        Nicholas Piggin <npiggin@...il.com>,
        Paul Mackerras <paulus@...ba.org>,
        Douglas Miller <dougmill@...ux.vnet.ibm.com>,
        Pan Xinhui <xinhui.pan@...ux.vnet.ibm.com>,
        "open list\:LINUX FOR POWERPC \(32-BIT AND 64-BIT\)" 
        <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH] powerpc/xmon: Dont register sysrq key when kernel param xmon=off

Thanks for looking into this patch Mpe.

Michael Ellerman <mpe@...erman.id.au> writes:
> <snip>
>
> But the same crash happens with XMON_DEFAULT=n and nothing on the
> command line.
Yes, XMON_DEFAULT=n and empty boot command line implies xmon=off hence
you will see the same issue and this patch should fix that issue too.

>
> The problem is not xmon=off on the command line.
>
> The problem is that when xmon_on = false and we enter xmon via sysrq and
> then set breakpoints, we need to enable xmon_on before leaving xmon.
>
Agree on both the points made.

> So this is a bug introduced by:
>
>   3b5bf42b81d5 ("powerpc/xmon: Fix an unexpected xmon on/off state change")
>
>
> How to fix it is not entirely clear. In general I like the behaviour we
> have since the above commit, ie. quickly dropping into xmon and
> inspecting something doesn't leave xmon enabled, which then causes the
> system not to kdump/reboot later.
Agree on the convenience factor of leaving the xmon console
enabled. However we still need a way to disable xmon completely at
kernel-boot time. Leaving xmon enabled even if 'xmon=off' is provided at
command line is counter intuitive.

>
> What would be nice is if we keep that behaviour, but any action you take
> in xmon that requires xmon to remain resident, ie. setting a breakpoint,
> calls a function which makes sure xmon_on = true and if it wasn't prints
> a nice message saying "Turning xmon on due to breakpoint insertion" or
> something.
That makes sense to me and sounds workable. However we already have a
debugfs interface to enable/disable xmon debugger hook. I can also tweak
this interface to also register the sysrq key when xmon is enabled. This
should provide the user the ability to still use xmon if they want to
after the system has booted with xmon=off.

>
> cheers
>

-- 
Vaibhav Jain <vaibhav@...ux.vnet.ibm.com>
Linux Technology Center, IBM India Pvt. Ltd.