linux-kernel - Re: [RFC PATCH 3/3] x86/paravirt: switch mixed paravirt/alternative calls to alternative

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]

Message-ID: <e2d1157e-47cc-467d-a319-12bb07ef960c@suse.com>
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)