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: <20200315181256.dwj6izb7mdb3v7bq@treble>
Date:   Sun, 15 Mar 2020 13:12:56 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     tglx@...utronix.de, linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [RFC][PATCH 00/16] objtool: vmlinux.o and noinstr validation

On Thu, Mar 12, 2020 at 02:41:07PM +0100, Peter Zijlstra wrote:
> Hi all,
> 
> These patches extend objtool to be able to run on vmlinux.o and validate
> Thomas's proposed noinstr annotation:
> 
>   https://lkml.kernel.org/r/20200310170951.87c29e9c1cfbddd93ccd92b3@kernel.org
> 
>  "That's why we want the sections and the annotation. If something calls
>   out of a noinstr section into a regular text section and the call is not
>   annotated at the call site, then objtool can complain and tell you. What
>   Peter and I came up with looks like this:
> 
>   noinstr foo()
> 	do_protected(); <- Safe because in the noinstr section
> 	instr_begin();  <- Marks the begin of a safe region, ignored
> 			   by objtool
> 	do_stuff();     <- All good
> 	instr_end();    <- End of the safe region. objtool starts
> 			   looking again
> 	do_other_stuff();  <- Unsafe because do_other_stuff() is
> 			      not protected
> 
>   and:
> 
>   noinstr do_protected()
> 	bar();          <- objtool will complain here
>   "
> 
> It should be accompanied by something like the below; which you'll find in a
> series by Thomas.

Awesome work!

This is also a big step towards other eventual objtool features, like
LTO compatibility.

I did have a few concerns about the overall "noinstr" implementation,
mentioned in my reply to patch 15.

Other than that, and the minor comments I sent, the code looks great.

-- 
Josh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ