linux-kernel - Re: [PATCH 9/9] ARM: add uprobes support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20121021185908.GD4840@ubuntu>
Date:	Sun, 21 Oct 2012 20:59:08 +0200
From:	Rabin Vincent <rabin@....in>
To:	Dave Martin <dave.martin@...aro.org>
Cc:	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Peter Zijlstra <peterz@...radead.org>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>, oleg@...hat.com,
	Tixy <tixy@...aro.org>
Subject: Re: [PATCH 9/9] ARM: add uprobes support

On Mon, Oct 15, 2012 at 06:44:50PM +0100, Dave Martin wrote:
> On Mon, Oct 15, 2012 at 01:44:55PM +0200, Rabin Vincent wrote:
> > Why?  It currently works for ARM userspace even if the kernel is
> > Thumb-2.
> 
> My bad, I misread what was happening in the Makefile changes.
> 
> My concern is about whether we can build the ARM and Thumb-2 kprobes
> code into the same kernel.  If so, no problem, but I believe this is
> not a tested configuration for kprobes itself.
> 
> If you've not already done so, it should be possible to test this
> by adding CONFIG_THUMB2_KERNEL=y to your config, providing your
> hardware is Thumb-2 capable.

I've tested this before.  With a Thumb-2 kernel, both the kprobes test
(Thumb) and the uprobes test (ARM) run fine.

> General question which I'm not sure I understand yet: is is possible
> to combine uprobes/kprobes decode more completely?  It's not obvious
> to me whether the uprobes-specific decoding only relates to features
> which architecturally execute differently in user mode versus
> privileged mode.  Some explanation somewhere could be helpful.

What we change is not the decoding itself but the handling of the
instructions:

  (1) Load and stores are executed from the xol area by user space so
  the instructions need to be rewritten when they touch the PC.  Kprobes
  code rewrites the instructions directly and executes them or in some
  cases simulates them.

  (2) All other non-simulated instructions are also executed from the
  XOL area in userspace.  Because of this, the ALU instructions which
  use the PC also need to be rewritten to not use the PC.  Perhaps we
  can actually get rid of this and just execute these instruction from
  kernel space like it is done for uprobes.

  So the uprobes code is uses the decoding tables just to know if the
  instruction is using the PC or not, but if we make the ALU
  instructions execute from kernel space we could actually use the
  emulate_*() functions like kprobes does.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/