[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200802115600.GB1162@bug>
Date: Sun, 2 Aug 2020 13:56:01 +0200
From: Pavel Machek <pavel@....cz>
To: David Laight <David.Laight@...LAB.COM>
Cc: 'Andy Lutomirski' <luto@...nel.org>,
"madvenka@...ux.microsoft.com" <madvenka@...ux.microsoft.com>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
Linux API <linux-api@...r.kernel.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
Linux FS Devel <linux-fsdevel@...r.kernel.org>,
linux-integrity <linux-integrity@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
LSM List <linux-security-module@...r.kernel.org>,
Oleg Nesterov <oleg@...hat.com>, X86 ML <x86@...nel.org>
Subject: Re: [PATCH v1 0/4] [RFC] Implement Trampoline File Descriptor
Hi!
> > This is quite clever, but now I???m wondering just how much kernel help
> > is really needed. In your series, the trampoline is an non-executable
> > page. I can think of at least two alternative approaches, and I'd
> > like to know the pros and cons.
> >
> > 1. Entirely userspace: a return trampoline would be something like:
> >
> > 1:
> > pushq %rax
> > pushq %rbc
> > pushq %rcx
> > ...
> > pushq %r15
> > movq %rsp, %rdi # pointer to saved regs
> > leaq 1b(%rip), %rsi # pointer to the trampoline itself
> > callq trampoline_handler # see below
>
> For nested calls (where the trampoline needs to pass the
> original stack frame to the nested function) I think you
> just need a page full of:
> mov $0, scratch_reg; jmp trampoline_handler
I believe you could do with mov %pc, scratch_reg; jmp ...
That has advantage of being able to share single physical page across multiple virtual pages...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
