This is the emulation function for the instruction format used by the
ARM bit-field manipulation instructions.
Various other instruction forms can also make use of this and it is used
to replace use of prep_emulate_rd12{rm0}{_modify}
Signed-off-by: Jon Medhurst <tixy@yxit.co.uk>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
This is the emulation function for the instruction format used by the
ARM multiply-accumulate instructions. These don't allow use of PC so we
don't have to add special cases for this.
This function is used to replace use of prep_emulate_rd16rs8rm0_wflags
and prep_emulate_rd16rn12rs8rm0_wflags.
Signed-off-by: Jon Medhurst <tixy@yxit.co.uk>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
This is the emulation function for the instruction format used by the
ARM media instructions.
Signed-off-by: Jon Medhurst <tixy@yxit.co.uk>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
This is an emulation function for the LDRD and STRD instructions.
Signed-off-by: Jon Medhurst <tixy@yxit.co.uk>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
This is the emulation function for the instruction format used by the
ARM data-processing instructions.
Signed-off-by: Jon Medhurst <tixy@yxit.co.uk>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
This is for use by inline assembler which will be added to kprobes-arm.c
It saves memory when used on newer ARM architectures and also provides
correct interworking should ARM probes be required on Thumb kernels in
the future.
Signed-off-by: Jon Medhurst <tixy@yxit.co.uk>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
This writes a new value to PC which was obtained as the result of an ARM
ALU instruction. For ARMv7 and later this performs interworking.
On ARM kernels we shouldn't encounter any ALU instructions trying to
switch to Thumb mode so support for this isn't strictly necessary.
However, the approach taken in all other instruction decoding is for us
to avoid unpredictable modification of the PC for security reasons. This
is usually achieved by rejecting insertion of probes on problematic
instruction, but for ALU instructions we can't do this as it depends on
the contents of the CPU registers at the time the probe is hit. So, as
we require some form of run-time checking to trap undesirable PC
modification, we may as well simulate the instructions correctly, i.e.
in the way they would behave in the absence of a probe.
Signed-off-by: Jon Medhurst <tixy@yxit.co.uk>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
We will reject probing of unprivileged load and store instructions.
These rarely occur and writing test cases for them is difficult.
Signed-off-by: Jon Medhurst <tixy@yxit.co.uk>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
We'll treat the preload instructions as nops as they are just
performance hints.
Signed-off-by: Jon Medhurst <tixy@yxit.co.uk>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
The kernel doesn't currently support VFP or Neon code, and probing of
code with CP15 operations is fraught with bad consequences. So we will
just reject probing these instructions.
Signed-off-by: Jon Medhurst <tixy@yxit.co.uk>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Jon Medhurst