Intel i7-1165G7 vulnerable to Spectre v2

Intel i7-1165G7 vulnerable to Spectre v2

[Christian Gelinek]

Hi Guix,

My CPU, an 11th Gen Intel(R) Core(TM) i7-1165G7, is reported to be 
vulnerable by `lscpu`:

--8<---------------cut here---------------start------------->8---
Vulnerabilities:
   Itlb multihit:         Not affected
   L1tf:                  Not affected
   Mds:                   Not affected
   Meltdown:              Not affected
   Mmio stale data:       Not affected
   Retbleed:              Not affected
   Spec store bypass:     Mitigation; Speculative Store Bypass disabled 
via prctl
   Spectre v1:            Mitigation; usercopy/swapgs barriers and 
__user pointer sanitization
   Spectre v2:            Vulnerable: eIBRS with unprivileged eBPF
   Srbds:                 Not affected
   Tsx async abort:       Not affected
--8<---------------cut here---------------end--------------->8---

with `uname -a` output being

--8<---------------cut here---------------start------------->8---
Linux gelil14 6.1.8-gnu #1 SMP PREEMPT_DYNAMIC 1 x86_64 GNU/Linux
--8<---------------cut here---------------end--------------->8---

On the same machine, I have run Debian 11 Live from a USB drive:

--8<---------------cut here---------------start------------->8---
Linux debian 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13) 
x86_64 GNU/Linux
--8<---------------cut here---------------end--------------->8---

and the equivalent `lscpu` section is

--8<---------------cut here---------------start------------->8---
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Mmio stale data:   Not affected
Vulnerability Retbleed:          Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass 
disabled via prctl and seccomp
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers 
and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Enhanced IBRS, IBPB 
conditional, RSB filling, PBRSB-eIBRS SW sequence
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
--8<---------------cut here---------------end--------------->8---

Does anyone know how to enable some sort of mitigation for Guix?

Thanks,
Christian

Re: Intel i7-1165G7 vulnerable to Spectre v2

[Felix Lechner via]

Hi Christian,

On Wed, Feb 1, 2023 at 2:26 AM Christian Gelinek
<christian.gelinek@mailbox.org> wrote:
>
> On the same machine, I have run Debian 11 Live from a USB drive:
>
> Vulnerability Spectre v2:        Mitigation; Enhanced IBRS, IBPB
> conditional, RSB filling, PBRSB-eIBRS SW sequence

Looks like the "Enhanced IBRS" feature is not active on your machine.
Intel submitted it to the kernel in 2018. [1]

Per the comments in the code it is only needed for firmware, but still
something seems to be not quite right with our kernels—or with their
initialization after booting.

Could you please check the output of 'lscpu' after running the
following command in a Bourne-compatible shell:

    echo 1 > /proc/sys/kernel/ibrs_enabled

as described here? [2]

We may have to look at the other missing features too, which are:
"IBPB conditional, RSB filling, PBRSB-eIBRS SW sequence".

Thanks for helping to make Guix better (and safer) for everyone!

Kind regards
Felix Lechner

[1] https://lkml.iu.edu/hypermail/linux/kernel/1807.3/00923.html
[2] https://www.linuxquestions.org/questions/slackware-14/how-to-enable-ibrs-support-4175671384/

Re: Intel i7-1165G7 vulnerable to Spectre v2

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

Christian Gelinek 写道：
> Spectre v2: Vulnerable: eIBRS with unprivileged eBPF
[…]
> Spectre v2: Mitigation; Enhanced IBRS, IBPB 
> conditional, RSB filling, PBRSB-eIBRS SW sequence

Does

  $ echo 1 | sudo tee /proc/sys/kernel/unprivileged_bpf_disabled

change this?

What does Debian's kconfig list for CONFIG_BPF_UNPRIV_DEFAULT_OFF?

Guix has it *unset* (which means default *on*) which means that 
unprivileged_bpf_disabled is 0 (which means *enabled*) because 
Linux is a hot mess and nobody cares.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Intel i7-1165G7 vulnerable to Spectre v2

[Ekaitz Zarraga]

Hi,

> Does
> 
> $ echo 1 | sudo tee /proc/sys/kernel/unprivileged_bpf_disabled
> 
> change this?
> 
> What does Debian's kconfig list for CONFIG_BPF_UNPRIV_DEFAULT_OFF?
> 
> Guix has it unset (which means default on) which means that
> unprivileged_bpf_disabled is 0 (which means enabled) because
> Linux is a hot mess and nobody cares.
> 
> Kind regards,
> 
> T G-R

In my CPU (i7-10510U) I had the same problem and that fixes it.

Cheers,
Ekaitz

Disabling unprivileged BPF by default in our kernels

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 445 bytes --]

Ekaitz Zarraga 写道：
> What does Debian's kconfig list for 
> CONFIG_BPF_UNPRIV_DEFAULT_OFF?

I've always had this option set to Y in my own kernels, and it has 
never so much as inconvenienced me.  However, I'm not a BPF power 
user.

Does anyone know any serious and concrete drawbacks to setting 
this option in all Guix kernels, to increase default security & 
better align with other major distros?

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Disabling unprivileged BPF by default in our kernels

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

On Wed, Feb 01, 2023 at 08:43:42PM +0100, Tobias Geerinckx-Rice wrote:
> Ekaitz Zarraga 写道：
> > What does Debian's kconfig list for CONFIG_BPF_UNPRIV_DEFAULT_OFF?
> 
> I've always had this option set to Y in my own kernels, and it has never so
> much as inconvenienced me.  However, I'm not a BPF power user.
> 
> Does anyone know any serious and concrete drawbacks to setting this option
> in all Guix kernels, to increase default security & better align with other
> major distros?

I have no opinion either way.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Disabling unprivileged BPF by default in our kernels

[Remco van 't Veer]

2023/02/01 20:43, Tobias Geerinckx-Rice:

>> What does Debian's kconfig list for CONFIG_BPF_UNPRIV_DEFAULT_OFF?
>
> I've always had this option set to Y in my own kernels, and it has
> never so much as inconvenienced me.  However, I'm not a BPF power
> user.
>
> Does anyone know any serious and concrete drawbacks to setting this
> option in all Guix kernels, to increase default security & better
> align with other major distros?

There is a linux-libre-bpf package so I'd expect BPF power users to use
that.  So I guess adding it to the default-extra-linux-options should be
fine.

R.

Re: Disabling unprivileged BPF by default in our kernels

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 53 bytes --]

Thanks both!  I'll do so soon.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Intel i7-1165G7 vulnerable to Spectre v2

[Christian Gelinek]

Hi Felix,

Thanks for your quick response.

On 1/2/23 14:20, Felix Lechner wrote:
> 
> Could you please check the output of 'lscpu' after running the
> following command in a Bourne-compatible shell:
> 
>      echo 1 > /proc/sys/kernel/ibrs_enabled

Unfortunately, /proc/sys/kernel/ibrs_enabled does not exist on my 
configuration.

Kind regards,
Christian

Re: Intel i7-1165G7 vulnerable to Spectre v2

[Christian Gelinek]

On 1/2/23 15:58, Tobias Geerinckx-Rice wrote:
> Christian Gelinek 写道：
>> Spectre v2: Vulnerable: eIBRS with unprivileged eBPF
> […]
>> Spectre v2: Mitigation; Enhanced IBRS, IBPB conditional, RSB filling, 
>> PBRSB-eIBRS SW sequence
> 
> Does
> 
>   $ echo 1 | sudo tee /proc/sys/kernel/unprivileged_bpf_disabled
> 
> change this?

It does, thank you! This is the updated output line of `lscpu`:

Spectre v2: Mitigation; Enhanced IBRS, IBPB conditional, RSB filling, 
PBRSB-eIBRS SW sequence

which matches the output I saw when I was running Debian 11.

How can I make this change permanent, ideally surviving both reboots as 
well as `guix system reconfigure` invocations?

Or do we think this will be soon compiled into the kernel, if I 
understood Remco's message [0] and your response [1] to that correctly, 
and therefore coming "for free" (for me, anyway) by `reconfigure`ing?

Kinde regards,
Christian

[0]: https://lists.gnu.org/archive/html/help-guix/2023-02/msg00008.html
[1]: https://lists.gnu.org/archive/html/help-guix/2023-02/msg00009.html