linux-kernel - Re: [PATCH v3 1/3] MIPS: Remove noreturn attribute for nmi_exception

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]

Message-ID: <d2a56d80-d71c-30e5-c001-13aa503398f3@loongson.cn>
Date:   Sat, 19 Aug 2023 10:38:00 +0800
From:   Tiezhu Yang <yangtiezhu@...ngson.cn>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>
Cc:     Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org,
        loongson-kernel@...ts.loongnix.cn
Subject: Re: [PATCH v3 1/3] MIPS: Remove noreturn attribute for
 nmi_exception_handler()



On 08/18/2023 10:39 AM, Maciej W. Rozycki wrote:
> On Mon, 14 Aug 2023, Tiezhu Yang wrote:
>
>> In the later patch, we will remove noreturn attribute for die(), in order
>> to make each patch can be built without errors and warnings, just remove
>> noreturn attribute for nmi_exception_handler() earlier because it calls
>> die(), otherwise there exists the following build error after the later
>> patch:
>
>  I find the wording a bit odd here, but you'll have to rewrite the change
> description for the update requested below, so let's defer any style fixes
> to v4.
>
>>   arch/mips/kernel/traps.c:2001:1: error: 'noreturn' function does return [-Werror]
>
>  Now that I've looked into it in detail, this change is incomplete and
> will make the kernel go astray if `nmi_exception_handler' actually ever
> does return.  See code in arch/mips/kernel/genex.S, which calls this
> function and doesn't expect it to return.  It has to be fixed before 2/3
> can be considered.  I wonder how you didn't catch it: you did check how
> this code is used, didn't you?
>

I think the proper way is to keep the noreturn attribute for
nmi_exception_handler(), and add a noreturn function BUG() at
the end of nmi_exception_handler() to make sure it does not
return.

>  Before submitting an updated version can you actually arrange for the
> NOTIFY_STOP condition to happen in your lab and verify it is handled as
> expected?  And what was the motivation for this code update, just a
> hypothetical scenario?

Yes, just a hypothetical scenario.

Thanks,
Tiezhu