[13/13] UBUNTU: [Config] Set CONFIG_BHI to enabled (auto)

Adjusting the config to have BHI mitigations enabled (for now we do use
the auto mode, this differs from upstream).

CVE-2024-2201
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
 debian.master/config/annotations | 3 +++
 1 file changed, 3 insertions(+)

Hi Stefan,

On Tue, Apr 16, 2024 at 04:53:25PM +0200, Stefan Bader wrote:
> Adjusting the config to have BHI mitigations enabled (for now we do use
> the auto mode, this differs from upstream).
> 
> CVE-2024-2201
> Signed-off-by: Stefan Bader <stefan.bader at canonical.com>
> ---
>  debian.master/config/annotations | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/debian.master/config/annotations b/debian.master/config/annotations
> index 23e37ffe0af7..27e46caf9b0d 100644
> --- a/debian.master/config/annotations
> +++ b/debian.master/config/annotations
> @@ -11942,6 +11942,9 @@ CONFIG_SPEAKUP_SYNTH_LTLK                       policy<{'amd64': 'm', 'arm64': '
>  CONFIG_SPEAKUP_SYNTH_SOFT                       policy<{'amd64': 'm', 'arm64': 'm', 'armhf': 'm', 'ppc64el': 'm', 's390x': '-'}>
>  CONFIG_SPEAKUP_SYNTH_SPKOUT                     policy<{'amd64': 'm', 'arm64': 'm', 'armhf': 'm', 'ppc64el': 'm', 's390x': '-'}>
>  CONFIG_SPEAKUP_SYNTH_TXPRT                      policy<{'amd64': 'm', 'arm64': 'm', 'armhf': 'm', 'ppc64el': 'm', 's390x': '-'}>
> +CONFIG_SPECTRE_BHI_AUTO                         policy<{'amd64': 'y'}>
> +CONFIG_SPECTRE_BHI_OFF                          policy<{'amd64': 'n'}>
> +CONFIG_SPECTRE_BHI_ON                           policy<{'amd64': 'n'}>

May I get you to share a bit more about the decision to go with "auto"?

Linux 6.9-rc4 and patches queued for 5.15.156 stable[1] eliminate the
"auto" option for "spectre_v2" and "spectre_bhi".   If the goal is to
stay as close to upstream as possible, avoiding the "auto" option would
reduce confusion when it's subsequently removed.

The auto case leads to an odd patchwork of software defenses being used
in some cases, but not all, and hardware defenses used in other cases,
if they exist.  CPUs that have retpolines and RRSBA still need the BHB
clearing sequence, as do those running eIBRS without retpolines.

The on / off cases are pretty clear cut.  Either the user gets the
mitigations if one exists for their CPU, or they're switched off.

Given how quickly things are moving here, it might be worth picking up
the additional patches from 5.15.156 from x86/cpu and x86/bugs, if it's
possible.  There are some additional RRSBA fixups, as well as the
removal of the auto behavior.

Is there a reason not to follow the upstream behavior of
CONFIG_SPECTRE_BHI=ON. Users who want to disable the behavior may still
set the appropriate boot options.

-K

[1] https://lore.kernel.org/stable/2024041612-bacterium-scratch-22ea@gregkh/T/#m08b6bad7528c10b5c75aef8eb850e62801a65310

On 17.04.24 05:41, Krister Johansen wrote:
> Hi Stefan,
> 
> On Tue, Apr 16, 2024 at 04:53:25PM +0200, Stefan Bader wrote:
>> Adjusting the config to have BHI mitigations enabled (for now we do use
>> the auto mode, this differs from upstream).
>>
>> CVE-2024-2201
>> Signed-off-by: Stefan Bader <stefan.bader at canonical.com>
>> ---
>>   debian.master/config/annotations | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/debian.master/config/annotations b/debian.master/config/annotations
>> index 23e37ffe0af7..27e46caf9b0d 100644
>> --- a/debian.master/config/annotations
>> +++ b/debian.master/config/annotations
>> @@ -11942,6 +11942,9 @@ CONFIG_SPEAKUP_SYNTH_LTLK                       policy<{'amd64': 'm', 'arm64': '
>>   CONFIG_SPEAKUP_SYNTH_SOFT                       policy<{'amd64': 'm', 'arm64': 'm', 'armhf': 'm', 'ppc64el': 'm', 's390x': '-'}>
>>   CONFIG_SPEAKUP_SYNTH_SPKOUT                     policy<{'amd64': 'm', 'arm64': 'm', 'armhf': 'm', 'ppc64el': 'm', 's390x': '-'}>
>>   CONFIG_SPEAKUP_SYNTH_TXPRT                      policy<{'amd64': 'm', 'arm64': 'm', 'armhf': 'm', 'ppc64el': 'm', 's390x': '-'}>
>> +CONFIG_SPECTRE_BHI_AUTO                         policy<{'amd64': 'y'}>
>> +CONFIG_SPECTRE_BHI_OFF                          policy<{'amd64': 'n'}>
>> +CONFIG_SPECTRE_BHI_ON                           policy<{'amd64': 'n'}>
> 
> May I get you to share a bit more about the decision to go with "auto"?
> 
> Linux 6.9-rc4 and patches queued for 5.15.156 stable[1] eliminate the
> "auto" option for "spectre_v2" and "spectre_bhi".   If the goal is to
> stay as close to upstream as possible, avoiding the "auto" option would
> reduce confusion when it's subsequently removed.
> 
> The auto case leads to an odd patchwork of software defenses being used
> in some cases, but not all, and hardware defenses used in other cases,
> if they exist.  CPUs that have retpolines and RRSBA still need the BHB
> clearing sequence, as do those running eIBRS without retpolines.
> 
> The on / off cases are pretty clear cut.  Either the user gets the
> mitigations if one exists for their CPU, or they're switched off.
> 
> Given how quickly things are moving here, it might be worth picking up
> the additional patches from 5.15.156 from x86/cpu and x86/bugs, if it's
> possible.  There are some additional RRSBA fixups, as well as the
> removal of the auto behavior.

The immediate goal is to stay close code-wise with the least amount of 
performance impact. This can be changed once we reach the upstream 
stable that contains the set. By then it could also be that things have 
settled a bit more.

Users can change to on from the command-line if they are ok with the 
trade-off. Just as long as things are still somewhat rushed we try to go 
with the lesser intrusion by default and document how to change it.

All the other fixes will come in their time. Just not quickly in the 
current cycle.

-Stefan
> 
> Is there a reason not to follow the upstream behavior of
> CONFIG_SPECTRE_BHI=ON. Users who want to disable the behavior may still
> set the appropriate boot options.
> 
> -K
> 
> [1] https://lore.kernel.org/stable/2024041612-bacterium-scratch-22ea@gregkh/T/#m08b6bad7528c10b5c75aef8eb850e62801a65310