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] [day] [month] [year] [list]
Date:   Wed, 20 Sep 2023 17:49:02 +0200
From:   Juergen Gross <jgross@...e.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org,
        virtualization@...ts.linux-foundation.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Srivatsa S. Bhat (VMware)" <srivatsa@...il.mit.edu>,
        Alexey Makhalov <amakhalov@...are.com>,
        VMware PV-Drivers Reviewers <pv-drivers@...are.com>
Subject: Re: [RFC PATCH 3/3] x86/paravirt: switch mixed paravirt/alternative
 calls to alternative_2

On 20.09.23 16:52, Peter Zijlstra wrote:
> On Thu, Jun 08, 2023 at 04:03:33PM +0200, Juergen Gross wrote:
>> Instead of stacking alternative and paravirt patching, use the new
>> ALT_FLAG_CALL flag to switch those mixed calls to pure alternative
>> handling.
>>
>> This eliminates the need to be careful regarding the sequence of
>> alternative and paravirt patching.
>>
>> For call depth tracking callthunks_setup() needs to be adapted to patch
>> calls at alternative patching sites instead of paravirt calls.
>>
>> Remove the no longer needed paravirt patching and related code.
> 
> I think this becomes easier if you first convert the paravirt sites to
> alternatives, such that .parainstructions is empty, and then in a
> subsequent patch remove all the paravirt infrastructure that is unused.

Fine with me.

Speaking of additional patches: any idea how the related objtool change(s)
should look like? I suspect they are needed ...

> 
> 
>> +#define SAVE_FLAGS	ALTERNATIVE_2 "PARA_IRQ_save_fl;", ALT_CALL_INSTR, \
>> +				      ALT_CALL_ALWAYS, "pushf; pop %rax;", \
>> +				      ALT_NOT(X86_FEATURE_XENPV)
> 
> I find this more readable when written as:
> 
> #define SAVE_FLAGS	ALTERNATIVE_2 "PARA_IRQ_save_fl;",		\
> 				      ALT_CALL_INSTR, ALT_CALL_ALWAYS,	\
> 				      "pushf; pop %rax;", ALT_NOT(X86_FEATURE_XENPV)
> 
> (and perhaps ALT_NOT_XEN is in order, there's a ton of those)

I like both suggestions.

> 
> If you base this on top of the nested alternative patches, another
> helper might be:
> 
> #define __PV_ALTERNATIVE(old) __ALTERNATIVE(old, ALT_CALL_INSTR, ALT_CALL_ALWAYS)
> 
> So that you can then write:
> 
> #define SAVE_FLAGS	__ALTERNATIVE(__PV_ALTERNATIVE("PARA_IRQ_save_fl;"),
> 				      "pushf; pop %rax;", ALT_NOT_XEN)
> 
> But perhaps I'm over-cooking things now..

I don't think this is needed for the single instance it is useful for.


Juergen

Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3099 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (496 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ