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: <20210520092144.509729406@linuxfoundation.org>
Date:   Thu, 20 May 2021 11:22:48 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     linux-kernel@...r.kernel.org
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        stable@...r.kernel.org, Randy Dunlap <rdunlap@...radead.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Sasha Levin <sashal@...nel.org>
Subject: [PATCH 4.19 399/425] pinctrl: ingenic: Improve unreachable code generation

From: Josh Poimboeuf <jpoimboe@...hat.com>

[ Upstream commit d6d43a92172085a2681e06a0d06aac53c7bcdd12 ]

In the second loop of ingenic_pinconf_set(), it annotates the switch
default case as unreachable().  The annotation is technically correct,
because that same case would have resulted in an early function return
in the previous loop.

However, the compiled code is suboptimal.  GCC seems to work extra hard
to ensure that the unreachable code path triggers undefined behavior.
The function would fall through to start executing whatever function
happens to be next in the compilation unit.

This is problematic because:

  a) it adds unnecessary 'ensure undefined behavior' logic, and
     corresponding i-cache footprint; and

  b) it's less robust -- if a bug were to be introduced, falling through
     to the next function would be catastrophic.

Yet another issue is that, while objtool normally understands
unreachable() annotations, there's one special case where it doesn't:
when the annotation occurs immediately after a 'ret' instruction.  That
happens to be the case here because unreachable() is immediately before
the return.

Remove the unreachable() annotation and replace it with a comment.  This
simplifies the code generation and changes the unreachable error path to
just silently return instead of corrupting execution.

This fixes the following objtool warning:

  drivers/pinctrl/pinctrl-ingenic.o: warning: objtool: ingenic_pinconf_set() falls through to next function ingenic_pinconf_group_set()

Reported-by: Randy Dunlap <rdunlap@...radead.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@...hat.com>
Link: https://lore.kernel.org/r/bc20fdbcb826512cf76b7dfd0972740875931b19.1582212881.git.jpoimboe@redhat.com
Signed-off-by: Linus Walleij <linus.walleij@...aro.org>
Signed-off-by: Sasha Levin <sashal@...nel.org>
---
 drivers/pinctrl/pinctrl-ingenic.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-ingenic.c b/drivers/pinctrl/pinctrl-ingenic.c
index a5accffbc8c9..babf6d011264 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -642,7 +642,8 @@ static int ingenic_pinconf_set(struct pinctrl_dev *pctldev, unsigned int pin,
 			break;
 
 		default:
-			unreachable();
+			/* unreachable */
+			break;
 		}
 	}
 
-- 
2.30.2



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ