Backports for stable branches

Backports for stable branches

[Andrew Cooper]

Hello,

Two python bugfixes which definitely qualify for backport:

897257ba49d0 tools/python: change 's#' size type for Python >= 3.10
3a59443c1d5a tools/xenmon: Fix xenmon.py for with python3.x

Next, I'm going to argue for taking:

f7d07619d2ae x86/vmx: implement VMExit based guest Bus Lock detection
d329b37d1213 x86/vmx: introduce helper to set VMX_INTR_SHADOW_NMI
573279cde1c4 x86/vmx: implement Notify VM Exit
5f08bc9404c7 x86/vmx: Partially revert "x86/vmx: implement Notify VM Exit"

These are technically new features for Sapphire Rapids, but they're both
very simple (in the grand scheme of new features), and are both
mitigations to system-wide denial of services that required silicon
changes to make happen.

Either way, there is a security argument to be made for backporting these.

~Andrew

Re: Backports for stable branches

[Jan Beulich]

On 03.03.2023 16:56, Andrew Cooper wrote:
> Two python bugfixes which definitely qualify for backport:
> 
> 897257ba49d0 tools/python: change 's#' size type for Python >= 3.10
> 3a59443c1d5a tools/xenmon: Fix xenmon.py for with python3.x

Queued. I wasn't entirely certain about these when I saw them going in.
They also had no Fixes: tags.

> Next, I'm going to argue for taking:
> 
> f7d07619d2ae x86/vmx: implement VMExit based guest Bus Lock detection
> d329b37d1213 x86/vmx: introduce helper to set VMX_INTR_SHADOW_NMI
> 573279cde1c4 x86/vmx: implement Notify VM Exit
> 5f08bc9404c7 x86/vmx: Partially revert "x86/vmx: implement Notify VM Exit"
> 
> These are technically new features for Sapphire Rapids, but they're both
> very simple (in the grand scheme of new features), and are both
> mitigations to system-wide denial of services that required silicon
> changes to make happen.
> 
> Either way, there is a security argument to be made for backporting these.

I have to admit I'm not entirely certain here. At present my inclination
would be to put them in 4.17 only, where - it only going to be 4.17.1 -
the "new feature" aspect is more reasonable to accept. 4.16, otoh, is
relatively soon to go out of general support (albeit I notice not yet
after the next stable release, as this time round the 4 month cadence
was followed pretty closely). Thoughts?

Jan

Re: Backports for stable branches

[Andrew Cooper]

On 06/03/2023 7:28 am, Jan Beulich wrote:
> On 03.03.2023 16:56, Andrew Cooper wrote:
>> Two python bugfixes which definitely qualify for backport:
>>
>> 897257ba49d0 tools/python: change 's#' size type for Python >= 3.10
>> 3a59443c1d5a tools/xenmon: Fix xenmon.py for with python3.x
> Queued. I wasn't entirely certain about these when I saw them going in.
> They also had no Fixes: tags.

In both cases, they're requirements added by an external party after the
code was in our tree, so there are no obvious fixes tags.

The first patch is really "support compiling with Python 3.10", while
the second is arguably a bug in Xen 4.10(?) when declared full Python 3
support.

>> Next, I'm going to argue for taking:
>>
>> f7d07619d2ae x86/vmx: implement VMExit based guest Bus Lock detection
>> d329b37d1213 x86/vmx: introduce helper to set VMX_INTR_SHADOW_NMI
>> 573279cde1c4 x86/vmx: implement Notify VM Exit
>> 5f08bc9404c7 x86/vmx: Partially revert "x86/vmx: implement Notify VM Exit"
>>
>> These are technically new features for Sapphire Rapids, but they're both
>> very simple (in the grand scheme of new features), and are both
>> mitigations to system-wide denial of services that required silicon
>> changes to make happen.
>>
>> Either way, there is a security argument to be made for backporting these.
> I have to admit I'm not entirely certain here. At present my inclination
> would be to put them in 4.17 only, where - it only going to be 4.17.1 -
> the "new feature" aspect is more reasonable to accept. 4.16, otoh, is
> relatively soon to go out of general support (albeit I notice not yet
> after the next stable release, as this time round the 4 month cadence
> was followed pretty closely). Thoughts?

Bus Lock detection is a "simple" DoS mitigation.  The system continues
to function in presence of a rogue core generating buslocks as fast as
possible.  So this is (ultimately) a nice-to-have.

Notify Exit is different.  It is intended to mitigate pipeline infinite
loops - two we've issued an XSA for, but the PCI Passthrough one that
has no mitigation other than this.

The further we backport Notify Exit, the more we shrink the affected
versions on a theoretical future pipeline infinite loop.  (Marginally,
perhaps, but its still a good start.)


So putting them into 4.17 is definitely an improvement over only being
in 4.18.

But I think if we do get a new pipeline infinite loop issue in the
future, I'll be backporting Notify Exit as a prerequisite on all
security branches that don't currently have it.

~Andrew