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: <20180117163007.GA2249@hirez.programming.kicks-ass.net>
Date:   Wed, 17 Jan 2018 17:30:07 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     David Woodhouse <dwmw2@...radead.org>,
        linux-kernel@...r.kernel.org, Dave Hansen <dave.hansen@...el.com>,
        Ashok Raj <ashok.raj@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Arjan Van De Ven <arjan.van.de.ven@...el.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Jun Nakajima <jun.nakajima@...el.com>,
        Asit Mallick <asit.k.mallick@...el.com>,
        Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH v2 06/10] objtool: Implement jump_assert for
 _static_cpu_has()

On Wed, Jan 17, 2018 at 08:30:21AM -0600, Josh Poimboeuf wrote:
> On Wed, Jan 17, 2018 at 08:27:59AM -0600, Josh Poimboeuf wrote:
> > > > > +			if (insn->jump_dest == fake_jump) {
> > > > > +				WARN_FUNC("jump inside alternative for _static_cpu_has()",
> > > > > +					  insn->sec, insn->offset);
> > > > > +			}
> > > > 
> > > > The error message doesn't seem to match the condition, so I'm not sure
> > > > which one you're trying to check, or why.
> > > > 
> > > > IIRC, 'insn->jump_dest == fake_jump' means we reached the end of the
> > > > alternative code block without hitting a jump.
> > > > 
> > > > But based on the loop exit condition, I don't think it's ever possible
> > > > for insn->jump_dest to ever point to the fake_jump at the end.
> > > 
> > > Oof, now what was I thinking again.. So that fake_jump is inserted at
> > > the end of the alternative and jumps to the code after where the
> > > alternative will be patched in to simulate the code flow.
> > > 
> > > If there is a jump inside the alternative that jumps to the end, it's
> > > destination will be set to the fake jump, we have this clause for that:
> > > 
> > > 	dest_off = insn->offset + insn->len + insn->immediate;
> > > 	if (dest_off == special_alt->new_off + special_alt->new_len)
> > > 		insn->jump_dest = fake_jump;
> > > 
> > > if that happens for static_cpu_has(), bad things happened.
> > > 
> > > So the only way for a jump to have fake_jump as destination is if the
> > > jump is inside the alternative (but to the end) and we must assert this
> > > didn't happen.
> > > 
> > > Unlikely, yes, but I figured we want to know about it if it ever does
> > > happen.
> 
> So the case you're worried about, is it an unconditional jump?  As that
> would be the only possibility based on the other warning.

Right, the code up to that point would allow (if something really weird
happened) to have fake_jump as destination there. We want to flag if
that happens because bad.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ