What is CVE-2020-0543, also known as CrossTalk or SRBDS?

You can find a good explanation here. On a vulnerable Intel system, there is a risk that random number generator output from one CPU core could be leaked to another. For a host running VMs or containers, this could mean that different tenants are able to gain sensitive information about other workloads running on that host.

How can I defend against it?

You should update your systems with the latest Intel microcode and make sure you are running the most recent BIOS/UEFI version. This has a performance impact for code that uses the RDRAND and RDSEED processor instructions. It is also possible to disable the affected instructions for KVM virtual machines, such as those created by recent versions of LXD (for traditional system containers, you would need to disable the instructions on the host).

To do this with LXD, first create a new VM (the fix can also be applied to existing VMs if they are shut down first):

user@host:~$ lxd init --vm images:ubuntu/focal my-test-vm
Creating my-test-vm

Then you need to add some raw QEMU options to be applied to the underlying KVM virtualization. These can be set in the LXD configuration:

user@host:~$ echo -n "-cpu host,-rdrand,-rdseed" | lxc config set my-test-vm raw.qemu -

Now you’re ready to start the VM, then get a shell:

user@host:~$ lxc start my-test-vm
user@host:~$ lxc shell my-test-vm
root@my-test-vm:~#

From here you can check the output of the lscpu command to see which vulnerabilities are mitigated:

root@my-test-vm:~# lscpu
Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   40 bits physical, 48 bits virtual
CPU(s):                          1
On-line CPU(s) list:             0
Thread(s) per core:              1
Core(s) per socket:              1
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       GenuineIntel
...<snip>...
Hypervisor vendor:               KVM
Virtualization type:             full
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Mitigation; PTE Inversion; VMX flush not necessary, SMT disabled
Vulnerability Mds:               Mitigation; Clear CPU buffers; SMT Host state unknown
Vulnerability Meltdown:          Mitigation; PTI
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; Full generic retpoline, IBPB conditional, IBRS_FW, STIBP disabled, RSB filling
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected

You can see that on a fully-patched host with the QEMU flags added, the VM considers all the currently documented CPU vulnerabilities to be mitigated or not applicable. On LXD VMs without the extra configuration, you will see the line Vulnerability Srbds: Unknown: Dependent on hypervisor status instead.