On 30.11.2018 20:12, Kees Cook wrote:

On Fri, Nov 30, 2018 at 9:09 AM Kees Cook [off-list ref] wrote:

quoted

On Fri, Nov 30, 2018 at 5:20 AM Alexander Popov [off-list ref] wrote:

quoted

Currently the 'stackleak_cleanup' pass deleting a CALL insn is executed
after the 'reload' pass. That allows gcc to do some weird optimization in
function prologues and epilogues, which are generated later [1].

Let's avoid that by registering the 'stackleak_cleanup' pass before
the 'mach' pass, which performs the machine dependent code transformations.
It's the moment when the stack frame size is final and function prologues
and epilogues are already generated.

[1] https://www.openwall.com/lists/kernel-hardening/2018/11/23/2

Reported-by: kbuild test robot <redacted>
Signed-off-by: Alexander Popov <redacted>

Thanks, applied!

Eek, no, this is breaking my build badly:

*** WARNING *** there are active plugins, do not report this as a bug
unless you can reproduce it without enabling any plugins.
Event                            | Plugins
PLUGIN_START_UNIT                | stackleak_plugin
kernel/exit.c: In function ‘release_task’:
kernel/exit.c:228:1: internal compiler error: Segmentation fault
 }

Failing with:

gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0

I've done debugging of gcc with gdb and now understand my mistake.

It turned out that I register the 'stackleak_cleanup' pass deleting CALL insn
for that particular moment when the control flow graph is inconsistent.

That's what the machine-specific reorg passes do on various architectures:

  /* We are freeing block_for_insn in the toplev to keep compatibility
     with old MDEP_REORGS that are not CFG based.  Recompute it now.  */
  compute_bb_for_insn ();

So recomputing basic block info for insns before calling delete_insn_and_edges()
fixes the issue.

But I think it's better to register the 'stackleak_cleanup' pass just one pass
earlier -- before the '*free_cfg' pass. I'll double check it for different
versions of gcc on all supported architectures and return with a new patch.

Best regards,
Alexander

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel