Re: [Simulavr-devel] modification of AVR simulator for SCA

[Thomas K]

Hi Jörg,

attiny2313 is tricky, the "old" ones initialized the SP to 0 (datasheet 
04/06), the attiny2313a (and attiny4313 also) initialized to RAMEND! 
(datasheet 11/09)


I've implemented it now for tiny2313 with RAMEND.

cu, Thomas


Am 18.02.2016 um 09:12 schrieb Joerg Wunsch:

As Albrecht Frenzel wrote:


Chapter 7.5.1 "SPH and SPL – Stack Pointer High and Stack Pointer
Low Register" of the atmega 48/88/168/328 says, that the initial
value of SP is RAMEND.

That's the case on all newer AVRs.

The distinction between the architectures that initialize SP in
hardware and those that don't is about the same where the three RC
oscillators have been replaced by a single one, plus a prescaler (and
the CKDIV8 fuse).  ATmega8, ATmega128, ATmega16, ATtiny2313,
AT90CAN128 start with SP = 0, ATmega1281, ATmega88, ATmega164,
ATtiny25 start with SP = RAMEND.

I think SimulAVR should correctly simulate this different behaviour.
Since the datasheet describes it, the user is allowed to rely on it.


Testing for 0 != SP_value only makes sense on instructions, that use
the content of SP.

I agree.



___
Simulavr-devel mailing list
Simulavr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/simulavr-devel

Re: [Simulavr-devel] modification of AVR simulator for SCA

[Thomas K]

Hi @list,

I've provided Albrecht with a mini patch to test it. (ok, that's just 
one parameter more in one call for instantiating stack, all other was 
already implemented) I assume, that this will solve it.


Regarding to the former discussions about new release: I'll create 
branch for release 1.1 __starting before__ changes for USI. Bugfix for 
SP will be made on master branch and taken over for release branch. 
Reason is, that I'll check some more for the problem with control reset 
address by fuses (and implement some tests from devel-tomk branch, which 
I'll remove after this + implement interrupt) and also for USI. (maybe 
Graziano will send me his changes, then I can inspect this)


If there is no another problem, then release 1.1.0 could be made in march.

cu, Thomas


Am 18.02.2016 um 09:12 schrieb Joerg Wunsch:

As Albrecht Frenzel wrote:


Chapter 7.5.1 "SPH and SPL – Stack Pointer High and Stack Pointer
Low Register" of the atmega 48/88/168/328 says, that the initial
value of SP is RAMEND.

That's the case on all newer AVRs.

The distinction between the architectures that initialize SP in
hardware and those that don't is about the same where the three RC
oscillators have been replaced by a single one, plus a prescaler (and
the CKDIV8 fuse).  ATmega8, ATmega128, ATmega16, ATtiny2313,
AT90CAN128 start with SP = 0, ATmega1281, ATmega88, ATmega164,
ATtiny25 start with SP = RAMEND.

I think SimulAVR should correctly simulate this different behaviour.
Since the datasheet describes it, the user is allowed to rely on it.


Testing for 0 != SP_value only makes sense on instructions, that use
the content of SP.

I agree.



___
Simulavr-devel mailing list
Simulavr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/simulavr-devel

Re: [Simulavr-devel] modification of AVR simulator for SCA

[Joerg Wunsch]

As Albrecht Frenzel wrote:

> Chapter 7.5.1 "SPH and SPL – Stack Pointer High and Stack Pointer 
> Low Register" of the atmega 48/88/168/328 says, that the initial 
> value of SP is RAMEND.

That's the case on all newer AVRs.

The distinction between the architectures that initialize SP in 
hardware and those that don't is about the same where the three RC 
oscillators have been replaced by a single one, plus a prescaler (and 
the CKDIV8 fuse).  ATmega8, ATmega128, ATmega16, ATtiny2313, 
AT90CAN128 start with SP = 0, ATmega1281, ATmega88, ATmega164, 
ATtiny25 start with SP = RAMEND.

I think SimulAVR should correctly simulate this different behaviour. 
Since the datasheet describes it, the user is allowed to rely on it.

> Testing for 0 != SP_value only makes sense on instructions, that use 
> the content of SP.

I agree.
-- 
cheers, Joerg   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

___
Simulavr-devel mailing list
Simulavr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/simulavr-devel

Re: [Simulavr-devel] modification of AVR simulator for SCA

[Albrecht Frenzel]

Chapter 7.5.1 "SPH and SPL – Stack Pointer High and Stack Pointer 
Low Register" of the atmega 48/88/168/328 says, that the initial 
value of SP is RAMEND.


simulavr terminates with assert(0 != SP_value), if SP==0, no matter, 
which instruction is executed. That means, that programmaticaly 
loading SP is impossible, if SP==0 at start of the simulator.


Testing for 0 != SP_value only makes sense on instructions, that use 
the content of SP.



---


Regarding the assertion: assert(0 != SP_value)

Startup code in CRT (a C runtime) is expected initialize SPH:SPL to a
sane value - a value that points to RAM. Having SPH:SPL point to 0 (or
anywhere but RAM) indicates problem in simulated AVR code - not a
problem in simulavr iself.

That's not true.

Optiboot as delivered by the arduino IDE does not load SP, except 
the target is ATMEGA 8/16/32 and a comment states that SP gets 
loaded with RAMEND via reset.


A disassembly of the optiboot_atmega328.hex does not contain 
instructions to load SP but call instructions.


Simulavr terminates with assert(0 != SP_value) if I try to simulate 
that code - that means, that reset for 328p is incomplete.



On 12.02.2016 21:45, Petr Hluzín wrote:

On 10 February 2016 at 17:50, Klaus Rudolph  wrote:


The problem with the thread I can't explain. I never looked in that code and I 
have no idea what the tread is good for while accessing registers. Maybe this 
stuff can also be removed...

Maybe someone else can give some hints especially for this "mystery" threading 
things?


The ThreadList class watches writes to SPH and SPL and maintains a
simple state machine that allows it to distinguish:
(a) writes that grow or shrink a stack
(b) writes that initialize stack pointer in libc's startup code
(c) writes that switch stack to a different thread when the simulated
application uses an RTOS.

Simulavr then reports the detected call stacks as threads to GDB and
you can type "thread apply all backtrace" to see call-stacks of the
non-running threads.

Unfortunately GDB's code for unwinding stack is weaker than I
anticipated and the RTOSes I investigated do nonsensical stuff to SP
(in addition to switching threads) confusing the state machine, so the
feature is mostly useless right now. I guess you can rip it of from
the sources.


Regarding the assertion: assert(0 != SP_value)

Startup code in CRT (a C runtime) is expected initialize SPH:SPL to a
sane value - a value that points to RAM. Having SPH:SPL point to 0 (or
anywhere but RAM) indicates problem in simulated AVR code - not a
problem in simulavr iself. Therefore the line should not be an
assertion, it should print a message and pause simulation to allow
user to investigate using GDB. However, as you can see from the
backtrace, the situation is detected quite deep in simulavr and we
have no mechanism to report breakpoints from such depth.

(Also we do not have a mechanism to report multiple
breakpoints/problems triggering on the same instruction, imagine e.g.
an instruction execution accesses memory watched by gdb, a peripheral
detects something wrong at the same time and the next instruction has
an ordinary gdb breakpoint, etc. It is a nice capability to have,
would solve the problem of reporting a problem from the depth.)




___
Simulavr-devel mailing list
Simulavr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/simulavr-devel

Re: [Simulavr-devel] modification of AVR simulator for SCA

[Albrecht Frenzel]

Regarding the assertion: assert(0 != SP_value)

Startup code in CRT (a C runtime) is expected initialize SPH:SPL to a
sane value - a value that points to RAM. Having SPH:SPL point to 0 (or
anywhere but RAM) indicates problem in simulated AVR code - not a
problem in simulavr iself.

That's not true.

Optiboot as delivered by the arduino IDE does not load SP, except 
the target is ATMEGA 8/16/32 and a comment states that SP gets 
loaded with RAMEND via reset.


A disassembly of the optiboot_atmega328.hex does not contain 
instructions to load SP but call instructions.


Simulavr terminates with assert(0 != SP_value) if I try to simulate 
that code - that means, that reset for 328p is incomplete.



On 12.02.2016 21:45, Petr Hluzín wrote:

On 10 February 2016 at 17:50, Klaus Rudolph  wrote:


The problem with the thread I can't explain. I never looked in that code and I 
have no idea what the tread is good for while accessing registers. Maybe this 
stuff can also be removed...

Maybe someone else can give some hints especially for this "mystery" threading 
things?


The ThreadList class watches writes to SPH and SPL and maintains a
simple state machine that allows it to distinguish:
(a) writes that grow or shrink a stack
(b) writes that initialize stack pointer in libc's startup code
(c) writes that switch stack to a different thread when the simulated
application uses an RTOS.

Simulavr then reports the detected call stacks as threads to GDB and
you can type "thread apply all backtrace" to see call-stacks of the
non-running threads.

Unfortunately GDB's code for unwinding stack is weaker than I
anticipated and the RTOSes I investigated do nonsensical stuff to SP
(in addition to switching threads) confusing the state machine, so the
feature is mostly useless right now. I guess you can rip it of from
the sources.


Regarding the assertion: assert(0 != SP_value)

Startup code in CRT (a C runtime) is expected initialize SPH:SPL to a
sane value - a value that points to RAM. Having SPH:SPL point to 0 (or
anywhere but RAM) indicates problem in simulated AVR code - not a
problem in simulavr iself. Therefore the line should not be an
assertion, it should print a message and pause simulation to allow
user to investigate using GDB. However, as you can see from the
backtrace, the situation is detected quite deep in simulavr and we
have no mechanism to report breakpoints from such depth.

(Also we do not have a mechanism to report multiple
breakpoints/problems triggering on the same instruction, imagine e.g.
an instruction execution accesses memory watched by gdb, a peripheral
detects something wrong at the same time and the next instruction has
an ordinary gdb breakpoint, etc. It is a nice capability to have,
would solve the problem of reporting a problem from the depth.)




___
Simulavr-devel mailing list
Simulavr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/simulavr-devel

Re: [Simulavr-devel] modification of AVR simulator for SCA

[Petr Hluzín]

On 10 February 2016 at 17:50, Klaus Rudolph  wrote:

> The problem with the thread I can't explain. I never looked in that code and 
> I have no idea what the tread is good for while accessing registers. Maybe 
> this stuff can also be removed...
>
> Maybe someone else can give some hints especially for this "mystery" 
> threading things?
>

The ThreadList class watches writes to SPH and SPL and maintains a
simple state machine that allows it to distinguish:
(a) writes that grow or shrink a stack
(b) writes that initialize stack pointer in libc's startup code
(c) writes that switch stack to a different thread when the simulated
application uses an RTOS.

Simulavr then reports the detected call stacks as threads to GDB and
you can type "thread apply all backtrace" to see call-stacks of the
non-running threads.

Unfortunately GDB's code for unwinding stack is weaker than I
anticipated and the RTOSes I investigated do nonsensical stuff to SP
(in addition to switching threads) confusing the state machine, so the
feature is mostly useless right now. I guess you can rip it of from
the sources.


Regarding the assertion: assert(0 != SP_value)

Startup code in CRT (a C runtime) is expected initialize SPH:SPL to a
sane value - a value that points to RAM. Having SPH:SPL point to 0 (or
anywhere but RAM) indicates problem in simulated AVR code - not a
problem in simulavr iself. Therefore the line should not be an
assertion, it should print a message and pause simulation to allow
user to investigate using GDB. However, as you can see from the
backtrace, the situation is detected quite deep in simulavr and we
have no mechanism to report breakpoints from such depth.

(Also we do not have a mechanism to report multiple
breakpoints/problems triggering on the same instruction, imagine e.g.
an instruction execution accesses memory watched by gdb, a peripheral
detects something wrong at the same time and the next instruction has
an ordinary gdb breakpoint, etc. It is a nice capability to have,
would solve the problem of reporting a problem from the depth.)


Nikita wrote:
> If I do something like that on AvrDevice::GetIOReg it changes the
> behaviour of the program when I test it:
> only each 2nd character entered by the used is actually handled by the
> program
> (I am testing it on examples/simple_ex1 that is also on the website).
> I found a hack to me it work for AvrDevice::GetIOReg by just reading the
> value once in a tmp variable and then using it
> in my leakValue funciton and in the return, like that:

This is because calling RWMemoryMember::operator unsigned char() has a
side-effect of removing a byte from UART peripheral.

IMHO simulavr over-uses operator overloading. The code would be easier
to read if the various operators were changed to a named function. (I
am not against operator overloading in general. They do have a place -
when they are used often enough and when their semantics is obvious
enough.)

Also src/cmd/gdbserver.cpp need to read memory without causing
side-effects (or prevent reading the byte). This is not fixed.

___
Simulavr-devel mailing list
Simulavr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/simulavr-devel

Re: [Simulavr-devel] modification of AVR simulator for SCA

[Klaus Rudolph]

Hi,

at first: Please use latest git master content. The version 1.0.0 contains so 
many bugs that I can not answer any question to that outdated version. As you 
can see in the bug tracker all known bugs are fixed in the current head of the 
master branch. So please download latest sources from git and retest again.

Sorry for the inconvenience!

For accessing functions which read and write direct to the core registers:

If a register is not only plain ram/flash every access to it can change the 
state of internal hardware. For example if you read from UartDataRegister the 
read will eat the value and clear the flags in the status register for the 
uart. The result is, that the access from the avr program will receive only 
every second byte because the other bytes are already read by your additional 
access.

I think there was a backdoor read function in earlier versions. But I can't 
find it??

The problem with the thread I can't explain. I never looked in that code and I 
have no idea what the tread is good for while accessing registers. Maybe this 
stuff can also be removed...

Maybe someone else can give some hints especially for this "mystery" threading 
things?



Regards
 Klaus


> Gesendet: Mittwoch, 10. Februar 2016 um 11:49 Uhr
> Von: Nikita 
> An: simulavr-devel@nongnu.org
> Betreff: [Simulavr-devel] modification of AVR simulator for SCA
>
> Hello,
> 
> My name is Nikita, I am a researcher at a university in Brussels and I
> am currently trying to modify simulavr
> to produce data for side-channel analysis (SCA) ofr security &
> cryptography research purposes.
> I am very happy with the way this simulator works and I figured out how
> to modify it in order to
> make something that I need for my research.
> However I have a small problem that I can not figure out and I hope that
> you can help me with it.
> 
> I took the latest version of your code on the official website (1.0.0).
> I am modifiyng avrdevice.cpp in the following way:
> there are several Get and Set reg methods in the class AvrDevice
> What I need is to output the value beeing read and/or written at each
> memory access, so for example:
> 
> unsigned char AvrDevice::GetCoreReg(unsigned addr) {
> assert(addr < registerSpaceSize);
> return *(rw[addr]);
> }
> 
> Became:
> unsigned char AvrDevice::GetCoreReg(unsigned addr) {
> assert(addr < registerSpaceSize);
> leakValue( *(rw[addr]) ); // funciton that actually appends the
> value into a file "trace.txt"
> return *(rw[addr]);
> }
> 
> These modifications work ok on all these Get and Set functions except
> the ons that work with IOReg:
>  - AvrDevice::GetIOReg
>  - AvrDevice::SetIOReg
>  - AvrDevice::SetIORegBit
> 
> If I do something like that on AvrDevice::GetIOReg it changes the
> behaviour of the program when I test it:
> only each 2nd character entered by the used is actually handled by the
> program
> (I am testing it on examples/simple_ex1 that is also on the website).
> I found a hack to me it work for AvrDevice::GetIOReg by just reading the
> value once in a tmp variable and then using it
> in my leakValue funciton and in the return, like that:
> 
> unsigned char AvrDevice::GetIOReg(unsigned addr) {
> assert(addr < ioSpaceSize);  // callers do use 0x00 base, not 0x20
> unsigned char tmp = *(rw[addr + registerSpaceSize]);
> leakOnRead( tmp );
> return tmp;
> }
> 
> However as soon as I try to do something similar on AvrDevice::SetIOReg
> I get the following error during the execution:
> 
> simulavr: hwstack.cpp:282: void ThreadList::OnSPRead(int): Assertion `0
> != SP_value' failed.
> Aborted (core dumped)
> 
> This is the command that I am using:
> ./simulavr -d atmega128 -f ../examples/simple_ex1/simple_atmega128.elf
> -W 0x20,- -R 0x22,- -T exit
> 
> For the Set command what I would like to have it the previous value
> stored in
> the memory and the new one beeing written, something like that (which
> works perfectly for CoreReg):
> 
> bool AvrDevice::SetCoreReg(unsigned addr, unsigned char val) {
> assert(addr < registerSpaceSize);
> leakOnWrite(*(rw[addr]), val); // this is my only addition to the
> original code
> *(rw[addr]) = val;
> return true;
> }
> 
> And here is the gdb execution trace:
> 
> ___
> simulavr: hwstack.cpp:282: void ThreadList::OnSPRead(int): Assertion `0
> != SP_value' failed.
> 
> Program received signal SIGABRT, Aborted.
> 0x7720ecc9 in __GI_raise (sig=sig@entry=6)
> at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> 56../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x7720ecc9 in __GI_raise (sig=sig@entry=6)
> at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> #1  0x772120d8 in __GI_abort () at abort.c:89
> #2  0x77207b86 in __assert_fail_base (
> fmt=0x77358830 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
> 

Re: [Simulavr-devel] modification of AVR simulator for SCA

[Thomas K]

Hi Nikita,

nice problem ... :-) I can reproduce it. Problem here is, that method 
ThreadList::OnSPRead in hwstack.cpp check, if stack pointer points to 0 
(as after reset), line is:


assert(0 != SP_value);  // SP must not point to register area

Your access in AvrDevice::SetIOReg acts like a read access and so jumps 
into trap. But there is no
easy way to get the value of this IO register without acting as normal 
read access. This happens normally only one time, if stackpointer will 
be initialized with a valid pointer.


You could now as a quick fix comment out the line above. Just to 
deactivate this assertion in this case! But you should hold in mind, 
that your change acts as a implicit read-before write! For normal 
registers, which do not change a value by reading a register it's not a 
problem. But for some peripherals, where this behaviour (to change/react 
by reading register) is as wanted, this could run in very strange problems!


cu, Thomas


Am 10.02.2016 um 11:49 schrieb Nikita:

Hello,

My name is Nikita, I am a researcher at a university in Brussels and I
am currently trying to modify simulavr
to produce data for side-channel analysis (SCA) ofr security &
cryptography research purposes.
I am very happy with the way this simulator works and I figured out how
to modify it in order to
make something that I need for my research.
However I have a small problem that I can not figure out and I hope that
you can help me with it.

I took the latest version of your code on the official website (1.0.0).
I am modifiyng avrdevice.cpp in the following way:
there are several Get and Set reg methods in the class AvrDevice
What I need is to output the value beeing read and/or written at each
memory access, so for example:

unsigned char AvrDevice::GetCoreReg(unsigned addr) {
 assert(addr < registerSpaceSize);
 return *(rw[addr]);
}

Became:
unsigned char AvrDevice::GetCoreReg(unsigned addr) {
 assert(addr < registerSpaceSize);
 leakValue( *(rw[addr]) ); // funciton that actually appends the
value into a file "trace.txt"
 return *(rw[addr]);
}

These modifications work ok on all these Get and Set functions except
the ons that work with IOReg:
  - AvrDevice::GetIOReg
  - AvrDevice::SetIOReg
  - AvrDevice::SetIORegBit

If I do something like that on AvrDevice::GetIOReg it changes the
behaviour of the program when I test it:
only each 2nd character entered by the used is actually handled by the
program
(I am testing it on examples/simple_ex1 that is also on the website).
I found a hack to me it work for AvrDevice::GetIOReg by just reading the
value once in a tmp variable and then using it
in my leakValue funciton and in the return, like that:

unsigned char AvrDevice::GetIOReg(unsigned addr) {
 assert(addr < ioSpaceSize);  // callers do use 0x00 base, not 0x20
 unsigned char tmp = *(rw[addr + registerSpaceSize]);
 leakOnRead( tmp );
 return tmp;
}

However as soon as I try to do something similar on AvrDevice::SetIOReg
I get the following error during the execution:

simulavr: hwstack.cpp:282: void ThreadList::OnSPRead(int): Assertion `0
!= SP_value' failed.
Aborted (core dumped)

This is the command that I am using:
./simulavr -d atmega128 -f ../examples/simple_ex1/simple_atmega128.elf
-W 0x20,- -R 0x22,- -T exit

For the Set command what I would like to have it the previous value
stored in
the memory and the new one beeing written, something like that (which
works perfectly for CoreReg):

bool AvrDevice::SetCoreReg(unsigned addr, unsigned char val) {
 assert(addr < registerSpaceSize);
 leakOnWrite(*(rw[addr]), val); // this is my only addition to the
original code
 *(rw[addr]) = val;
 return true;
}

And here is the gdb execution trace:

___
simulavr: hwstack.cpp:282: void ThreadList::OnSPRead(int): Assertion `0
!= SP_value' failed.

Program received signal SIGABRT, Aborted.
0x7720ecc9 in __GI_raise (sig=sig@entry=6)
 at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x7720ecc9 in __GI_raise (sig=sig@entry=6)
 at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x772120d8 in __GI_abort () at abort.c:89
#2  0x77207b86 in __assert_fail_base (
 fmt=0x77358830 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
 assertion=assertion@entry=0x47d28c "0 != SP_value",
 file=file@entry=0x47d24a "hwstack.cpp", line=line@entry=282,
 function=function@entry=0x47d3a0
 "void
ThreadList::OnSPRead(int)") at assert.c:92
#3  0x77207c32 in __GI___assert_fail (
 assertion=0x47d28c "0 != SP_value", file=0x47d24a "hwstack.cpp",
line=282,
 function=0x47d3a0 
"void ThreadList::OnSPRead(int)") at assert.c:101
#4  0x0044a30d in ThreadList::OnSPRead 

Re: [Simulavr-devel] modification of AVR simulator for SCA

[Albrecht Frenzel]

at first: Please use latest git master content. The version 1.0.0 contains so 
many bugs that I can not answer any question to that outdated version.
Wouldn't it be a good idea, to remove this version and put a better 
one onto the project home page?




On 10.02.2016 17:50, Klaus Rudolph wrote:

Hi,

at first: Please use latest git master content. The version 1.0.0 contains so 
many bugs that I can not answer any question to that outdated version. As you 
can see in the bug tracker all known bugs are fixed in the current head of the 
master branch. So please download latest sources from git and retest again.

Sorry for the inconvenience!

For accessing functions which read and write direct to the core registers:

If a register is not only plain ram/flash every access to it can change the 
state of internal hardware. For example if you read from UartDataRegister the 
read will eat the value and clear the flags in the status register for the 
uart. The result is, that the access from the avr program will receive only 
every second byte because the other bytes are already read by your additional 
access.

I think there was a backdoor read function in earlier versions. But I can't 
find it??

The problem with the thread I can't explain. I never looked in that code and I 
have no idea what the tread is good for while accessing registers. Maybe this 
stuff can also be removed...

Maybe someone else can give some hints especially for this "mystery" threading 
things?



Regards
  Klaus



Gesendet: Mittwoch, 10. Februar 2016 um 11:49 Uhr
Von: Nikita 
An: simulavr-devel@nongnu.org
Betreff: [Simulavr-devel] modification of AVR simulator for SCA

Hello,

My name is Nikita, I am a researcher at a university in Brussels and I
am currently trying to modify simulavr
to produce data for side-channel analysis (SCA) ofr security &
cryptography research purposes.
I am very happy with the way this simulator works and I figured out how
to modify it in order to
make something that I need for my research.
However I have a small problem that I can not figure out and I hope that
you can help me with it.

I took the latest version of your code on the official website (1.0.0).
I am modifiyng avrdevice.cpp in the following way:
there are several Get and Set reg methods in the class AvrDevice
What I need is to output the value beeing read and/or written at each
memory access, so for example:

unsigned char AvrDevice::GetCoreReg(unsigned addr) {
 assert(addr < registerSpaceSize);
 return *(rw[addr]);
}

Became:
unsigned char AvrDevice::GetCoreReg(unsigned addr) {
 assert(addr < registerSpaceSize);
 leakValue( *(rw[addr]) ); // funciton that actually appends the
value into a file "trace.txt"
 return *(rw[addr]);
}

These modifications work ok on all these Get and Set functions except
the ons that work with IOReg:
  - AvrDevice::GetIOReg
  - AvrDevice::SetIOReg
  - AvrDevice::SetIORegBit

If I do something like that on AvrDevice::GetIOReg it changes the
behaviour of the program when I test it:
only each 2nd character entered by the used is actually handled by the
program
(I am testing it on examples/simple_ex1 that is also on the website).
I found a hack to me it work for AvrDevice::GetIOReg by just reading the
value once in a tmp variable and then using it
in my leakValue funciton and in the return, like that:

unsigned char AvrDevice::GetIOReg(unsigned addr) {
 assert(addr < ioSpaceSize);  // callers do use 0x00 base, not 0x20
 unsigned char tmp = *(rw[addr + registerSpaceSize]);
 leakOnRead( tmp );
 return tmp;
}

However as soon as I try to do something similar on AvrDevice::SetIOReg
I get the following error during the execution:

simulavr: hwstack.cpp:282: void ThreadList::OnSPRead(int): Assertion `0
!= SP_value' failed.
Aborted (core dumped)

This is the command that I am using:
./simulavr -d atmega128 -f ../examples/simple_ex1/simple_atmega128.elf
-W 0x20,- -R 0x22,- -T exit

For the Set command what I would like to have it the previous value
stored in
the memory and the new one beeing written, something like that (which
works perfectly for CoreReg):

bool AvrDevice::SetCoreReg(unsigned addr, unsigned char val) {
 assert(addr < registerSpaceSize);
 leakOnWrite(*(rw[addr]), val); // this is my only addition to the
original code
 *(rw[addr]) = val;
 return true;
}

And here is the gdb execution trace:

___
simulavr: hwstack.cpp:282: void ThreadList::OnSPRead(int): Assertion `0
!= SP_value' failed.

Program received signal SIGABRT, Aborted.
0x7720ecc9 in __GI_raise (sig=sig@entry=6)
 at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x7720ecc9 in __GI_raise (sig=sig@entry=6)
 at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x772120d8 in __GI_abort () at