On Thu, May 30, 2019 at 9:26 PM Tycho Andersen <tycho@xxxxxxxx> wrote: > > Hi Andrew, > > On Thu, May 30, 2019 at 10:09:44AM -0700, Andrew Pinski wrote: > > On Thu, May 30, 2019 at 10:01 AM Tycho Andersen <tycho@xxxxxxxx> wrote: > > > > > > Hi all, > > > > > > I've been trying to implement an idea Andy suggested recently for > > > preventing some kinds of ROP attacks. The discussion of the idea is > > > here: > > > https://lore.kernel.org/linux-mm/DFA69954-3F0F-4B79-A9B5-893D33D87E51@xxxxxxxxxxxxxx/ > > > Hi Tycho, I realise this is maybe not relevant to the topic of fixing the plugin; but I'm struggling to understand what this is intending to protect against. The idea seems to be to make sure that restored rbp, rsp values are "close" to the current rbp, rsp values? The only scenario I can see this providing any benefit is if an attacker can only corrupt a saved stack/frame pointer, which seems like such an unlikely situation that it's not really worth adding any complexity to defend against. An attacker who has control of rip can surely get a controlled value into rsp in various ways; a quick scan of the current Ubuntu 18.04 kernel image offers the following sequence (which shows up everywhere): lea rsp, qword ptr [r10 - 8] ret I'd assume that it's not tremendously difficult for an attacker to chain to this without needing to previously pivot out the stack pointer, assuming that at the point at which they gain control of rip they have control over some state somewhere. If you could explain the exact attack scenario that you have in mind then perhaps I could provide a better explanation of how one might bypass it. Regards, Mark
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
