linux-kernel - Re: [RFC][PATCH 00/16] objtool: vmlinux.o and noinstr validation

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: <20200317121428.GI12521@hirez.programming.kicks-ass.net>
Date:   Tue, 17 Mar 2020 13:14:28 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     tglx@...utronix.de, jpoimboe@...hat.com,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        Dan Carpenter <dan.carpenter@...cle.com>
Subject: Re: [RFC][PATCH 00/16] objtool: vmlinux.o and noinstr validation

On Tue, Mar 17, 2020 at 09:56:28AM +0900, Masami Hiramatsu wrote:
> On Thu, 12 Mar 2020 17:23:37 +0100
> Peter Zijlstra <peterz@...radead.org> wrote:

> > So one of the problem i've ran into while playing with this and Thomas'
> > patches is that it is 'difficult' to deal with indirect function calls.
> > 
> > objtool basically gives up instantly.
> 
> Can we introduce a "safe-call" wrapper function instead of indirect
> call, and if objtool found an indirect call without safe-call function,
> it can make it an error?
> 
> static int __noinstr safe_indirect_callback(int (*fn)(...), real-args)
> {
> 	if (!is_instr_text(fn))
> 		return -ERANGE;
> 	return fn(real-args)
> }

That is a runtime test and as such susceptible to code coverage issues.

I could probably frob a few cases manually in objtool; so far I've
managed to just make them go away.

> BTW, out of curiously, if BUG*() or WARN*() cases happens in the noinstr
> section, do we also need to move them (register dump, stack unwinding,
> printk, console output, etc.) all into noinstr section?

Since BUG/WARN should not happen, we've added instr_begin()/instr_end()
to their slow path. If those trigger, we've got bigger issues.