On Wed, May 15, 2024 at 11:33 AM Borislav Petkov <bp@xxxxxxxxx> wrote: > > On Wed, May 15, 2024 at 10:33:03AM -0700, Axel Rasmussen wrote: > > Right, the goal is to still have the process get a SIGBUS, but to > > avoid the "MCE error" log message. The basic issue is, unprivileged > > users can set these markers up, and thereby completely spam up the > > log. > > What is the real attack scenario you want to protect against? > > Or is this something hypothetical? An unprivileged process can allocate a VMA, use the userfaultfd API to install one of these PTE markers, and then register a no-op SIGBUS handler. Now it can access that address in a tight loop, generating a huge number of kernel log messages. This can e.g. bog down the system, or at least drown out other important log messages. For example the userfaultfd selftest does something similar to this to test that the API works properly. :) Even in a non-contrived / non-malicious case, use of this API could have similar effects. If nothing else, the log message can be confusing to administrators: they state that an MCE occurred, whereas with the simulated poison API, this is not the case; it isn't a "real" MCE / hardware error. > > > That said, one thing I'm not sure about is whether or not > > VM_FAULT_SIGBUS is a viable alternative (returned for a new PTE marker > > type specific to simulated poison). The goal of the simulated poison > > feature is to "closely simulate" a real hardware poison event. If you > > live migrate a VM from a host with real poisoned memory, to a new > > host: you'd want to keep the same behavior if the guest accessed those > > addresses again, so as not to confuse the guest about why it suddenly > > became "un-poisoned". > > Well, the recovery action is to poison the page and the process should > be resilient enough and allocate a new, clean page which doesn't trigger > hw poison hopefully, if possible. > > It doesn't make a whole lotta sense if poison "remains". Hardware poison > you don't want to touch a second time either - otherwise you might > consume that poison and die. In the KVM use case, the host can't just allocate a new page, because it doesn't know what the guest might have had stored there. Best we can do is propagate the poison into the guest, and let the guest OS deal with it as it sees fit, and mark the page poisoned on the host. I don't disagree the guest *shouldn't* reaccess it in this case. :) But if it did, it should get another poison event just as you say. And, live migration between physical hosts should be transparent to the guest. So if the guest gets a poison, and then we live migrate it, and then it accesses that address again, it should likewise get another poison event, just as before. Even though the underlying physical memory is *not* poisoned on the new host machine. So the use case is, after live migration, we install one of these PTE markers to simulate a poison event in case the address is accessed again. But since it isn't *really* a hardware error on the new host, no reason to spam the host kernel log when / if this occurs. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette
