Re: unrecognizable insn generated in plugin?

["Mark Brand via gcc" <gcc@gcc.gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 1664 bytes --]

On Thu, May 30, 2019 at 9:26 PM Tycho Andersen <tycho@tycho.ws> 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@tycho.ws> 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@amacapital.net/
> > >


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 #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4849 bytes --]