load-store emulation with SIGSEGV

load-store emulation with SIGSEGV

[R. Lake]

I'm investigating a means of emulating causes of SEGV where they can be
isolated from genuine failure. For example, a rule stating a load from
address 0x100 "loads" the value 42 into the target register.

A simple test to decode the instruction, locate and modify the operand
register in the sigcontext or backing store, then increment sc_ip shows the
expected behaviour. But, for practical usage I'm not entirely confident I've
taken all the necessary steps to return to the kernel in a robust manner.
I've thus far taken insight from the unaligned handler albeit without
altering the psr.ri field. So, my question is... am I missing a vital stage
to this process, some piece of information the kernel expects to receive
when avoiding the faulting instruction?

Regards,
Richard.

load-store emulation with SIGSEGV

[R. Lake]

I'm investigating a means of emulating causes of SEGV where they can be
isolated from genuine failure. For example, a rule stating a load from
address 0x100 "loads" the value 42 into the target register.

A simple test to decode the instruction, locate and modify the operand
register in the sigcontext or backing store, then increment sc_ip shows the
expected behaviour. But, for practical usage I'm not entirely confident I've
taken all the necessary steps to return to the kernel in a robust manner.
I've thus far taken insight from the unaligned handler albeit without
altering the psr.ri field. So, my question is... am I missing a vital stage
to this process, some piece of information the kernel expects to receive
when avoiding the faulting instruction?

Regards,
Richard.

load-store emulation with SIGSEGV

[R. Lake]

I'm investigating a means of emulating causes of SEGV where they can be
isolated from genuine failure. For example, a rule stating a load from
address 0x100 "loads" the value 42 into the target register.

A simple test to decode the instruction, locate and modify the operand
register in the sigcontext or backing store, then increment sc_ip shows the
expected behaviour. But, for practical usage I'm not entirely confident I've
taken all the necessary steps to return to the kernel in a robust manner.
I've thus far taken insight from the unaligned handler albeit without
altering the psr.ri field. So, my question is... am I missing a vital stage
to this process, some piece of information the kernel expects to receive
when avoiding the faulting instruction?

Regards,
Richard.

load-store emulation with SIGSEGV

[R. Lake]

I'm investigating a means of emulating causes of SEGV where they can be
isolated from genuine failure. For example, a rule stating a load from
address 0x100 "loads" the value 42 into the target register.

A simple test to decode the instruction, locate and modify the operand
register in the sigcontext or backing store, then increment sc_ip shows the
expected behaviour. But, for practical usage I'm not entirely confident I've
taken all the necessary steps to return to the kernel in a robust manner.
I've thus far taken insight from the unaligned handler albeit without
altering the psr.ri field. So, my question is... am I missing a vital stage
to this process, some piece of information the kernel expects to receive
when avoiding the faulting instruction?

Regards,
Richard.

load-store emulation with SIGSEGV

[R. Lake]

I'm investigating a means of emulating causes of SEGV where they can be
isolated from genuine failure. For example, a rule stating a load from
address 0x100 "loads" the value 42 into the target register.

A simple test to decode the instruction, locate and modify the operand
register in the sigcontext or backing store, then increment sc_ip shows the
expected behaviour. But, for practical usage I'm not entirely confident I've
taken all the necessary steps to return to the kernel in a robust manner.
I've thus far taken insight from the unaligned handler albeit without
altering the psr.ri field. So, my question is... am I missing a vital stage
to this process, some piece of information the kernel expects to receive
when avoiding the faulting instruction?

Regards,
Richard.

Re: load-store emulation with SIGSEGV

[David Mosberger]

>>>>> On Thu, 16 Oct 2003 23:49:20 +0100, "R. Lake" <rich@lakes.plus.com> said:

  Rich> I'm investigating a means of emulating causes of SEGV where
  Rich> they can be isolated from genuine failure. For example, a rule
  Rich> stating a load from address 0x100 "loads" the value 42 into
  Rich> the target register.

  Rich> A simple test to decode the instruction, locate and modify the
  Rich> operand register in the sigcontext or backing store, then
  Rich> increment sc_ip shows the expected behaviour. But, for
  Rich> practical usage I'm not entirely confident I've taken all the
  Rich> necessary steps to return to the kernel in a robust manner.
  Rich> I've thus far taken insight from the unaligned handler albeit
  Rich> without altering the psr.ri field. So, my question is... am I
  Rich> missing a vital stage to this process, some piece of
  Rich> information the kernel expects to receive when avoiding the
  Rich> faulting instruction?

I'm not entirely sure I understand what you're trying to do and
whether you're doing it in the kernel or user (signal-handler).  If
the latter, adjusting the sc_ip should be sufficient (the slot number
is encoded in bits 0 and 1 of sc_ip).

	--david

Re: load-store emulation with SIGSEGV

[R. Lake]

>   Rich> I'm investigating a means of emulating causes of SEGV where
>   Rich> they can be isolated from genuine failure. For example, a rule
>   Rich> stating a load from address 0x100 "loads" the value 42 into
>   Rich> the target register.
>
> I'm not entirely sure I understand what you're trying to do and
> whether you're doing it in the kernel or user (signal-handler).  If
> the latter, adjusting the sc_ip should be sufficient (the slot number
> is encoded in bits 0 and 1 of sc_ip).
>
> --david

The current implementation is a user mode signal handler, so as you say
adjusting sc_ip ought to be okay. I'll run some more thorough asm tests to
check my usage of rse_skip_regs and make certain subsequent instructions are
executed from the faulting bundle. Thanks for your help.

Regards,
Richard.

Re: load-store emulation with SIGSEGV

[Matt Chapman]

On Thu, Oct 16, 2003 at 11:51:16PM +0100, R. Lake wrote:
> 
> A simple test to decode the instruction, locate and modify the operand
> register in the sigcontext or backing store, then increment sc_ip shows the
> expected behaviour.

Yep, I do similar things in a virtual machine that I wrote.  Here are some
notes in case you've overlooked some of the finer details (and perhaps I've
overlooked some of the finer details as well :)).

Incrementing the IP:
sc->sc_ip += ((sc->sc_ip & 0xf) = 2) ? 0xe : 1;

Register 0:
Read returns 0, write faults. When reading don't rely on sc_gr[0] being 0.

Register 1-3,8-31:
Simply read/write sc_gr[n].
Upon read check NaT bit, upon write clear NaT bit through sc_nat.

Register 4-7:
Preserved registers - read/write live value at entry to signal handler
(really would need to unwind to do this completely safely, but just using
the live value should do).  gcc rarely uses these registers so I just
assert here :)

Register 32-127:
If using sigaltstack, bsp = sc->sc_rbs_base + (sc->sc_loadrs >> 16),
else bsp = sc->sc_ar_bsp.
Read: ;;flushrs;; to write back
      read address = ia64_rse_skip_regs(bsp, -(sc->sc_cfm & 0x7f) + (regno - 32));
Write: ;;mov ar.rsc=0;;flushrs;;loadrs;; to go lazy, write back, invalidate
       write address as before
       ;;mov ar.rsc=3;; to allow eager loads again
       Strictly should check/clear the NaT bits as well (more fun working out
       the addresses), I haven't bothered to do this yet.

Also beware that old kernels (pre about 2.5.60?) report the wrong si_addr for
accesses to the NULL page (the instruction address instead of the fault address).
I'm not sure when this was fixed in the 2.4 tree.

Matt

RE: load-store emulation with SIGSEGV

[Jim Hull]

Matt Chapman wrote:

> Yep, I do similar things in a virtual machine that I wrote.  
> Here are some notes in case you've overlooked some of the finer
details 
> (and perhaps I've overlooked some of the finer details as well :)).
> 
> Incrementing the IP:
> sc->sc_ip += ((sc->sc_ip & 0xf) = 2) ? 0xe : 1;

I think there's one scenario where this won't work.  If it's possible
for your signal handler to be invoked in cases where the instruction
you're trying to skip over is a two-slot "L+X" instruction from an MLX
bundle (e.g., movl or brl), then the "slot" bits of sc_ip will be 1,
you'll increment them to 2, and when you return to slot 2 of the MLX
bundle you'll immediately take an Illegal Instruction fault.

Probably most "skip an instruction" signal handlers don't need to worry
about this case, because they'll always be pointing at an ordinary
single-slot instruction, but it's something to be aware of.

 -- Jim Hull
    HP Itanium Processor Architect

RE: load-store emulation with SIGSEGV

[David Mosberger]

>>>>> On Fri, 17 Oct 2003 11:16:41 -0700, "Jim Hull" <jim.hull@hp.com> said:

  Jim> Matt Chapman wrote:
  >> Yep, I do similar things in a virtual machine that I wrote.
  >> Here are some notes in case you've overlooked some of the finer
  Jim> details
  >> (and perhaps I've overlooked some of the finer details as well :)).

  >> Incrementing the IP:
  sc-> sc_ip += ((sc->sc_ip & 0xf) = 2) ? 0xe : 1;

  Jim> I think there's one scenario where this won't work.  If it's possible
  Jim> for your signal handler to be invoked in cases where the instruction
  Jim> you're trying to skip over is a two-slot "L+X" instruction from an MLX
  Jim> bundle (e.g., movl or brl), then the "slot" bits of sc_ip will be 1,
  Jim> you'll increment them to 2, and when you return to slot 2 of the MLX
  Jim> bundle you'll immediately take an Illegal Instruction fault.

  Jim> Probably most "skip an instruction" signal handlers don't need to worry
  Jim> about this case, because they'll always be pointing at an ordinary
  Jim> single-slot instruction, but it's something to be aware of.

The kernel's ia64_increment_ip() function in arch/ia64/kernel/ptrace.c
could be used as a template here.  Of course, you do need to read the
bundle in order to determine whether it's an MLX template.

	--david