linux-kernel - Re: [PATCH] crypto: fix error flow of crypto/testmgr.c:test

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:	Wed, 26 Nov 2008 03:40:32 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	David Miller <davem@...emloft.net>
Cc:	herbert@...dor.apana.org.au, linux-kernel@...r.kernel.org,
	linux-crypto@...r.kernel.org
Subject: Re: [PATCH] crypto: fix error flow of crypto/testmgr.c:test_comp()


* David Miller <davem@...emloft.net> wrote:

> >     fix warning in drivers/net/sky2.c
> >     fix warning in net/sunrpc/svcauth_unix.c
> >     fix warning in security/selinux/netnode.c
> >     fix warning in net/packet/af_packet.c
> >     fix warning in net/rfkill/rfkill.c
> 
> Not applied.  Changing this from a BUG() to a panic() is wrong. 
> BUG() kills the current execution context, and allows the system to 
> potentially continue.  Panic() takes down the entire machine.

Yeah, although in practice a BUG() in some of those places will take 
down the whole machine:

  > >     fix warning in net/packet/af_packet.c

That's packet receive path, holding spinlocks or in other atomic 
context (irq/softirq)? A BUG() will take down the machine as we will 
crash and try to schedule in atomic context.

> The !CONFIG_BUG BUG() definition should be marked in such a way that 
> gcc thinks it is noreturn.  Otherwise BUG() isn't really BUG() 
> anymore.  The other option is to never allow BUG to be disabled or 
> have it always evaluate to a simple bug trap.

Yeah, but note that that's exactly the current behavior (and intent) 
of !CONFIG_BUG: it is not doing anything (it's just an empty macro 
which returns!), and we get those build warnings because the control 
flow becomes undefined. We cannot mark it noreturn because it does 
return.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/