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  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]
Date:   Tue, 15 Dec 2020 18:38:02 -0600
From:   Josh Poimboeuf <>
To:     Peter Zijlstra <>
Cc:     Jürgen Groß <>,,,,,,,,
        Thomas Gleixner <>,
        Ingo Molnar <>, Borislav Petkov <>,
        "H. Peter Anvin" <>,
        Boris Ostrovsky <>,
        Stefano Stabellini <>,
        Deep Shah <>,
        "VMware, Inc." <>,
        "K. Y. Srinivasan" <>,
        Haiyang Zhang <>,
        Stephen Hemminger <>,
        Wei Liu <>,
        Paolo Bonzini <>,
        Sean Christopherson <>,
        Vitaly Kuznetsov <>,
        Wanpeng Li <>,
        Jim Mattson <>,
        Joerg Roedel <>,
        Daniel Lezcano <>,
        Juri Lelli <>,
        Vincent Guittot <>,
        Dietmar Eggemann <>,
        Steven Rostedt <>,
        Ben Segall <>, Mel Gorman <>,
        Daniel Bristot de Oliveira <>
Subject: Re: [PATCH v2 00/12] x86: major paravirt cleanup

On Tue, Dec 15, 2020 at 03:54:08PM +0100, Peter Zijlstra wrote:
> The problem is that a single instance of unwind information (ORC) must
> capture and correctly unwind all alternatives. Since the trivially
> correct mandate is out, implement the straight forward brute-force
> approach:
>  1) generate CFI information for each alternative
>  2) unwind every alternative with the merge-sort of the previously
>     generated CFI information -- O(n^2)
>  3) for any possible conflict: yell.
>  4) Generate ORC with merge-sort
> Specifically for 3 there are two possible classes of conflicts:
>  - the merge-sort itself could find conflicting CFI for the same
>    offset.
>  - the unwind can fail with the merged CFI.

So much algorithm.  Could we make it easier by caching the shared
per-alt-group CFI state somewhere along the way?

For example:

struct alt_group_info {

	/* first original insn in the group */
	struct instruction *orig_insn;

	/* max # of bytes in the group (cfi array size) */
	unsigned long nbytes;

	/* byte-offset-addressed array of CFI pointers */
	struct cfi_state **cfi;

We could change 'insn->alt_group' to be a pointer to a shared instance
of the above struct, so that all original and replacement instructions
in a group have a pointer to it.

Starting out, 'cfi' array is all NULLs.  Then when updating CFI, check

[ 'offset' is a byte offset from the beginning of the group.  It could
  be calculated based on 'orig_insn' or 'orig_insn->alts', depending on
  whether 'insn' is an original or a replacement. ]

If the array entry is NULL, just update it with a pointer to the CFI.
If it's not NULL, make sure it matches the existing CFI, and WARN if it

Also, with this data structure, the ORC generation should also be a lot
more straightforward, just ignore the NULL entries.

Thoughts?  This is all theoretical of course, I could try to do a patch


Powered by blists - more mailing lists