Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Retbleed?
New on LowEndTalk? Please Register and read our Community Rules.

Retbleed?

Any opinions on this? Linux kernel 5.15 has the latest fix, and Almalinux 8.6 is on kernel 4.x. Are some lowend CPUs going to be badly affected by the new mitigations? Just cross your fingers, or...?

Comments

  • PulsedMediaPulsedMedia Member, Patron Provider

    Older distros still get security patches typically, as long as they are not EOL status.

  • eva2000eva2000 Member
    edited September 14

    Don't think RHEL has a Kernel fix for this as yet only posted a mitigation for RHEL8 according to https://access.redhat.com/solutions/retbleed

    Red Hat Enterprise Linux 7 uses the existing IBRS mitigations for Intel processors.

    Red Hat Enterprise Linux 8 can mitigate the flaw in affected Intel CPUs if booted with the kernel parameter: spectre_v2=ibrs

    Initial fixes to close this attack vector have been queued in upstream. Red Hat Engineering has these patches currently in testing and will deliver them to the relevant streams.

    Thanked by 1FatGrizzly
  • If you are a provider, you can set mitigations=off on the HV and let your customers set their own
    IBRS mitigations. No reason why a node should suffer from the patches, assuming you don't have
    shared guests on the hypervisor, in most cases (unless OpenVZ) you won't. Some people run OpenBSD, which won't affect them as guest because of other mitigations. So no need to slow them
    down because of HV patches. IMO.

  • @luckypenguin said:
    If you are a provider, you can set mitigations=off on the HV and let your customers set their own
    IBRS mitigations. No reason why a node should suffer from the patches, assuming you don't have
    shared guests on the hypervisor, in most cases (unless OpenVZ) you won't. Some people run OpenBSD, which won't affect them as guest because of other mitigations. So no need to slow them
    down because of HV patches. IMO.

    This sounds like an interesting way to get involucrated

    Thanked by 1stevewatson301
  • @darkimmortal said: This sounds like an interesting way to get involucrated

    Care to explain? Or at least a way to show how guests will be affected.

  • darkimmortaldarkimmortal Member
    edited September 14

    @luckypenguin said:

    @darkimmortal said: This sounds like an interesting way to get involucrated

    Care to explain? Or at least a way to show how guests will be affected.

    Virtualisation is not a boundary without these mitigations in place. If the node has no mitigations, an unscrupulous customer can escape their VM and gain root access on the host node

  • dirtminerdirtminer Member
    edited September 14

    @darkimmortal said:

    Virtualisation is not a boundary without these mitigations in place. If the node has no mitigations, an unscrupulous customer can escape their VM and gain root access on the host node

    KVM is a distinct boundary for retbleed, and I haven't seen any research that shows being able to leak data across hypervisor exit and reentry.

    OpenVZ / LXC isn't a boundary.
    However, any attempt to exploit retbleed requires hours of sustained high CPU activity - which would already be disruptive.

    And none of the speculative execution bugs will give 'root access' to the hostnode.

    Speculative Execution only allows reading data through careful timing measurements.
    SSH Private Keys are generally not in kernel memory, so retbleed can't directly get at it.

  • darkimmortaldarkimmortal Member
    edited September 14

    @dirtminer said:
    KVM is a distinct boundary for retbleed, and I haven't seen any research that shows being able to leak data across hypervisor exit and reentry.

    Agree but my point was in relation to mitigations=off

    @dirtminer said:
    And none of the speculative execution bugs will give 'root access' to the hostnode.

    Speculative Execution only allows reading data through careful timing measurements.
    SSH Private Keys are generally not in kernel memory, so retbleed can't directly get at it.

    That's fair, the speculative execution bug would be just one part of a chain to get to the point of root access on the host or another guest. Being able to read arbitrary memory is already bad enough

    Thanked by 1stevewatson301
Sign In or Register to comment.