* Ingo Molnar wrote:
> Ha! There's a neat alternatives debugging trick with perf that you
> might not know about: if you run 'perf top' as root then perf will
> use /proc/kcore to disassemble the live kernel image and if you look
> at the assembly output of hot functions then you'll see the r
* Borislav Petkov wrote:
> On Thu, Mar 05, 2015 at 01:32:49AM +0100, Ingo Molnar wrote:
> > We could also do a (limited) relink during early bootup, as part of
> > the alternatives patching pass in essence: for that we need to stick
> > the relocation info into a section and put that into the vm
On Thu, Mar 05, 2015 at 01:32:49AM +0100, Ingo Molnar wrote:
> We could also do a (limited) relink during early bootup, as part of
> the alternatives patching pass in essence: for that we need to stick
> the relocation info into a section and put that into the vmlinux.
Oh, you want us to do our ow
On Thu, Mar 05, 2015 at 01:34:17AM +0100, Ingo Molnar wrote:
> So I'd not patch in the large _orig variant, it's legacy mostly - but
> the two fast variants?
Yes, so the optimal thing would be to have the kernel generate the CALL
variant when building. Those are going to be the default
opcodes in
* Borislav Petkov wrote:
> On Wed, Mar 04, 2015 at 08:13:24AM +0100, Ingo Molnar wrote:
> > Btw., the x86 memset() variants are using this today, and I think this
> > is the most optimal jump-patching variant, even if it means a small
> > amount of code duplication between the copy_user varian
* Borislav Petkov wrote:
> > 2) in the future: we could actually do a (limited) re-link of the
> > kernel during bootup, and patch up the original copy_to_user call
> > sites directly to one of the three variants. Alternatives patching
> > done at the symbol level. Does current tool
On Wed, Mar 04, 2015 at 08:13:24AM +0100, Ingo Molnar wrote:
> Btw., the x86 memset() variants are using this today, and I think this
> is the most optimal jump-patching variant, even if it means a small
> amount of code duplication between the copy_user variants.
Yeah, the problem with that one
On Wed, Mar 04, 2015 at 07:25:52AM +0100, Ingo Molnar wrote:
> Btw., as a future optimization, wouldn't it be useful to patch this
> function at its first instruction, i.e. to have three fully functional
> copy_user_generic_ variants and choose to jmp to one of them in the
> first instruction of
* Ingo Molnar wrote:
>
> * Borislav Petkov wrote:
>
> > From: Borislav Petkov
> >
> > Use the asm macro and drop the locally grown version.
>
> > @@ -73,9 +49,11 @@ ENTRY(_copy_to_user)
> > jc bad_to_user
> > cmpq TI_addr_limit(%rax),%rcx
> > ja bad_to_user
> > + ALTERNATIVE_
* Borislav Petkov wrote:
> From: Borislav Petkov
>
> Use the asm macro and drop the locally grown version.
> @@ -73,9 +49,11 @@ ENTRY(_copy_to_user)
> jc bad_to_user
> cmpq TI_addr_limit(%rax),%rcx
> ja bad_to_user
> + ALTERNATIVE_2 "jmp copy_user_generic_unrolled",
From: Borislav Petkov
Use the asm macro and drop the locally grown version.
Signed-off-by: Borislav Petkov
---
arch/x86/lib/copy_user_64.S | 40 ++--
1 file changed, 10 insertions(+), 30 deletions(-)
diff --git a/arch/x86/lib/copy_user_64.S b/arch/x86/lib/c
11 matches
Mail list logo
