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: <20190115223849.apk6tcbl7f7kd5d4@treble>
Date:   Tue, 15 Jan 2019 16:38:49 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Sean Christopherson <sean.j.christopherson@...el.com>
Cc:     Qian Cai <cai@....pw>, Paolo Bonzini <pbonzini@...hat.com>,
        rkrcmar@...hat.com, tglx@...utronix.de, mingo@...hat.com,
        bp@...en8.de, hpa@...or.com, x86@...nel.org, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kvm: add proper frame pointer logic for vmx

On Tue, Jan 15, 2019 at 11:06:17AM -0800, Sean Christopherson wrote:
> > I can see there are five options to solve it.
> > 
> > 1) always inline vmx_vcpu_run()
> > 2) always noinline vmx_vcpu_run()
> > 3) add -fdiable-ipa-fnsplit option to Makefile for vmx.o
> > 4) let STACK_FRAME_NON_STANDARD support part.* syntax.
> > 5) trim-down vmx_vcpu_run() even more to not causing splitting by GCC.
> > 
> > Option 1) and 2) seems give away the decision for user with
> > CONFIG_CC_OPTIMIZE_FOR_(PERFORMANCE/SIZE).
> > 
> > Option 3) prevents other functions there for splitting for optimization.
> > 
> > Option 4) and 5) seems tricky to implement.
> > 
> > I am not more leaning to 3) as only other fuction will miss splitting is
> > vmx_segment_access_rights().
> 
> Option 4) is the most correct, but "tricky" is an understatement.  Unless
> Josh is willing to pick up the task it'll likely have to wait.
> 
> There's actually a few more options:
> 
>  6) Replace "pop %rbp" in the vmx_vmenter() asm blob with an open-coded
>     equivalent, e.g. "mov [%rsp], %rbp; add $8, %rsp".  This runs an end-
>     around on objtool since objtool explicitly keys off "pop %rbp" and NOT
>     "mov ..., %rbp" (which is probably an objtool checking flaw?").
> 
>  7) Move the vmx_vmenter() asm blob and a few other lines of code into a
>     separate helper, e.g. __vmx_vcpu_run(), and mark that as having a
>     non-standard stack frame.

Do you mean moving the asm blob to a .S file instead of inline asm?  If
so, I think that's definitely a good idea.  It would be a nice cleanup,
regardless of the objtool false positive.

That would allow vmx_vcpu_run() to be a "normal" C function which
objtool can validate (and also create ORC data for).  It would also
prevent future nasty GCC optimizations (which was why the __noclone was
needed in the first place).

And also, I *think* objtool would no longer warn in that case, because
there would no longer be any calls in the function after popping %rbp.
Though if I'm wrong about that, I'd be glad to help fix the warning one
way or another.

-- 
Josh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ