talos icon indicating copy to clipboard operation
talos copied to clipboard

fix: bpf program failes due of linux LSM Lockdown

Open chifu1234 opened this issue 3 months ago • 12 comments

Pull Request

What? (description)

When secureboot images are used, talos by default sets lockdown to confidentiality (lockdown=confidentiality). This will prevent bfp based programs to run properly. BFP is used in many commonly used Kubernetes CNI like Cilium. Many other commonly used Linux distros are moving away from confidentiality mode and move to integrity mode.

More Discussion here https://github.com/iovisor/bcc/issues/2565.

Why? (reasoning)

Commonly used Kubernetes CNI not working properly.

Acceptance

Please use the following checklist:

  • [x] you linked an issue (if applicable)
  • [ ] you included tests (if applicable)
  • [ ] you ran conformance (make conformance)
  • [ ] you formatted your code (make fmt)
  • [ ] you linted your code (make lint)
  • [ ] you generated documentation (make docs)
  • [ ] you ran unit-tests (make unit-tests)

See make help for a description of the available targets.

I still have to test the change in my environment. Not sure if there is also change needed on the factory code?

chifu1234 avatar Apr 02 '24 20:04 chifu1234

There is no need to change the defaults, when generating an image -lockdown lockdown=integrity kernel args can be set to override the defaults. It's documented here https://www.talos.dev/v1.6/talos-guides/install/boot-assets/#imager and this is how existing users change lockdown mode

frezbo avatar Apr 03 '24 03:04 frezbo

@frezbo I'm not sure if you want your users in order to have a working Kubernetes Cluster using Cilium CNI and Secureboot to build and manage their own images. At least, I think the documentation should get an update on that. What do you think to edit to code to let the user overwrite kernel cmd via customization.extraKernelArgs? Currently they are prepended not overwritten: Command line: talos.platform=metal console=ttyS0 console=tty0 init_on_alloc=1 slab_nomerge pti=on consoleblank=0 nvme_core.io_timeout=4294967295 printk.devkmsg=on ima_template=ima-ng ima_appraise=fix ima_hash=sha512 lockdown=confidentiality lockdown=integrity

chifu1234 avatar Apr 03 '24 08:04 chifu1234

@frezbo I'm not sure if you want your users in order to have a working Kubernetes Cluster using Cilium CNI and Secureboot to build and manage their own images. At least, I think the documentation should get an update on that. What do you think to edit to code to let the user overwrite kernel cmd via customization.extraKernelArgs? Currently they are prepended not overwritten: Command line: talos.platform=metal console=ttyS0 console=tty0 init_on_alloc=1 slab_nomerge pti=on consoleblank=0 nvme_core.io_timeout=4294967295 printk.devkmsg=on ima_template=ima-ng ima_appraise=fix ima_hash=sha512 lockdown=confidentiality lockdown=integrity

I meant to add it to factory, or when using imager. If using customization.extraKernelArgs it needs an upgrade to take effect. There is no need to build your own if using Image Factory

Not every user uses Cilium with SecureBoot and making Talos less secure for one CNI is not ideal

frezbo avatar Apr 03 '24 08:04 frezbo

Currently, when I create an Installer Image with extraKernelArgs, it prepends the Args as expected. This results in Linux using the confidentiality Args. It may be because it's the first or most secure Args.

chifu1234 avatar Apr 03 '24 08:04 chifu1234

Currently, when I create an Installer Image with extraKernelArgs, it prepends the Args as expected. This results in Linux using the confidentiality Args. It may be because it's the first or most secure Args.

Could you post the steps used? If it's a bug we can fix it

frezbo avatar Apr 03 '24 08:04 frezbo

sure im using the following URL https://factory.talos.dev/?version=1.6.7&ext-siderolabs%2Fbnx2-bnx2x=&ext-siderolabs%2Fintel-ucode=&ext-siderolabs%2Fiscsi-tools=&extra-args=lockdown%3Dintegrity. Then Upgrade my cluster with talosctl --talosconfig ./talosconfig upgrade --nodes x.x.x.x --image factory.talos.dev/installer-secureboot/9dc6a04fb9666f1efadef7b941ec8bc4235ec76e12debf7fe2c739569de255d5:v1.6.7 --preserve $ talosctl --talosconfig ./talosconfig dmesg | less

x.x.x.x: kern:  notice: [2024-04-03T09:23:16.304993454Z]: Linux version 6.1.82-talos (@buildkitsandbox) (gcc (GCC) 13.2.0, GNU ld (GNU Binutils) 2.41) #1 SMP Tue Mar 19 17:48:01 UTC 2024
x.x.x.x: kern:    info: [2024-04-03T09:23:16.304993454Z]: Command line: talos.platform=metal console=ttyS0 console=tty0 init_on_alloc=1 slab_nomerge pti=on consoleblank=0 nvme_core.io_timeout=4294967295 printk.devkmsg=on ima_template=ima-ng ima_appraise=fix ima_hash=sha512 lockdown=confidentiality lockdown=integrity

chifu1234 avatar Apr 03 '24 09:04 chifu1234

sure im using the following URL https://factory.talos.dev/?version=1.6.7&ext-siderolabs%2Fbnx2-bnx2x=&ext-siderolabs%2Fintel-ucode=&ext-siderolabs%2Fiscsi-tools=&extra-args=lockdown%3Dintegrity. Then Upgrade my cluster with talosctl --talosconfig ./talosconfig upgrade --nodes x.x.x.x --image factory.talos.dev/installer-secureboot/9dc6a04fb9666f1efadef7b941ec8bc4235ec76e12debf7fe2c739569de255d5:v1.6.7 --preserve $ talosctl --talosconfig ./talosconfig dmesg | less

x.x.x.x: kern:  notice: [2024-04-03T09:23:16.304993454Z]: Linux version 6.1.82-talos (@buildkitsandbox) (gcc (GCC) 13.2.0, GNU ld (GNU Binutils) 2.41) #1 SMP Tue Mar 19 17:48:01 UTC 2024
x.x.x.x: kern:    info: [2024-04-03T09:23:16.304993454Z]: Command line: talos.platform=metal console=ttyS0 console=tty0 init_on_alloc=1 slab_nomerge pti=on consoleblank=0 nvme_core.io_timeout=4294967295 printk.devkmsg=on ima_template=ima-ng ima_appraise=fix ima_hash=sha512 lockdown=confidentiality lockdown=integrity

Could you try this schematic id: 7486cdb58bff0b7bf65f6f62d376542dff4c9bd97acb39ef59a76fcfacd76776

Seems it was missing -lockdown in the link you posted

frezbo avatar Apr 03 '24 09:04 frezbo

This is the input:

customization:
    extraKernelArgs:
        - -lockdown
        - lockdown=integrity
    systemExtensions:
        officialExtensions:
            - siderolabs/bnx2-bnx2x
            - siderolabs/intel-ucode
            - siderolabs/iscsi-tools

frezbo avatar Apr 03 '24 09:04 frezbo

I don't think there's a nice way to change lockdown flag via image factory, as installer will always try to write default, so you need to use machine config for that. We might consider changing the default for 1.8.

smira avatar Apr 03 '24 10:04 smira

@smira & @frezbo I was able to fix this issue by setting the args in the image factory

customization:
    extraKernelArgs:
        - -lockdown
        - lockdown=integrity

but not via machine config

machine:
      install:
        extraKernelArgs:
            - -lockdown
            - lockdown=integrity

OK then I will update my PR to update the documentation on Cilium CNI (https://www.talos.dev/v1.6/kubernetes-guides/network/deploying-cilium/). ?

chifu1234 avatar Apr 03 '24 11:04 chifu1234

Just to share our experience, we've been operating Talos with secureboot and utilizing Cilium for Kubernetes networking, enabling a wide range of BPF functionalities, for quite some time now—months, in fact—without encountering any significant issues tied to BPF's lockdown mode set to confidentiality.

Here are the specifics of our KubeProxyReplacement configuration:

KubeProxyReplacement Details:
  Status:                 True
  Socket LB:              Enabled
  Socket LB Tracing:      Enabled
  Socket LB Coverage:     Hostns-only
  Devices:                bond0 <snip> (Direct Routing)
  Mode:                   DSR
  Backend Selection:      Maglev (Table Size: 16381)
  Session Affinity:       Enabled
  Graceful Termination:   Enabled
  NAT46/64 Support:       Disabled
  XDP Acceleration:       Native
  Services:
  - ClusterIP:      Enabled
  - NodePort:       Enabled (Range: 30000-32767)
  - LoadBalancer:   Enabled
  - externalIPs:    Enabled
  - HostPort:       Enabled

The only minor issue we've noted involves occasional log messages upon Cilium startup, indicating:

lockdown_is_locked_down: 55 callbacks suppressed

and:

Lockdown: bpftool: use of bpf to read kernel RAM is restricted; see man kernel_lockdown.7

However, from our perspective, these don't present a significant concern.

nberlee avatar Apr 05 '24 06:04 nberlee