Assembly SD mnemonic

[Adrian Mcmenamin]

Spike has given me this output:

sd      ra, 56(sp)

I want to check my understanding of this is correct: namely store the contents of (full width of) ra (ie the return address) at the address pointed to by the stack pointer (sp) plus 56.

From the context this looks close to obvious - setting up a stack frame - but I want to check before I bet the farm on this as the manual isn't very clear (at least to me).

Adrian

[Stefan O'Rear]

On Sun, Sep 18, 2016 at 7:11 AM, Adrian Mcmenamin <acm...@york.ac.uk> wrote:
> Spike has given me this output:
>
> sd ra, 56(sp)
>
>
> I want to check my understanding of this is correct: namely store the
> contents of (full width of) ra (ie the return address) at the address
> pointed to by the stack pointer (sp) plus 56.

Close, it means store a "doubleword" (which means 64 bits when talking
about RISC-V) from the ra register into the address pointed at by
sp+56.

If (and this is by far the most likely) you are looking at RV64 code,
then a 64-bit store will indeed save the full width of ra.

If you are looking at RV128 code, then a 64-bit store will only store
half of ra; to store the whole 128 bits use "sq".

If you are looking at RV32 code, then the "sd" instruction is illegal
and you should use "sw" to save the full 32 bits.

Or were you asking about the memory reference syntax? Your
interpretation of 56(sp) as the memory location addressed by sp + 56
is correct; this is the standard notation in GNU assemblers ("AT&T
syntax"). (If you're confused by some construction in RISC-V
assembly, something else you can do is look up how to do it in MIPS,
the ABI and assembler syntax is quite similar.)

-s

[Michael Clark]

On 19 Sep 2016, at 7:20 AM, Stefan O'Rear <sor...@gmail.com> wrote:

On Sun, Sep 18, 2016 at 7:11 AM, Adrian Mcmenamin <acm...@york.ac.uk> wrote:

Spike has given me this output:

sd      ra, 56(sp)

I noticed you are storing control flow information on the stack. You might want to enable SafeStack. We don’t any want C strings overwriting return addresses do we.

http://clang.llvm.org/docs/SafeStack.html

With dynamic register randomisation there will be 32 × 31 combinations of return address and stack pointer. ~10 bits of entropy, a far cry from our 112 bit target. We can squish another 56-bits of entropy into bits[63:8] of the 64-bit syscall selector in ‘a0’, as only 8 bits are required to select the syscall, ‘a0’ holding the syscall number will also be randomised, and so will the first register parameter ‘a1’, so we’re now at Log2[32 × 31 × 30  × 29] + 56 = ~76 bits. We just need to find 36 more bits of entropy. ASLR on the stack pointer will give us ~19 bits. Now we’re at ~95 bits.

Only 17 bits more entropy and it is a quantum problem, and we can defer fixing unbounded array accesses in C.

Your one line ROP RCE is now a mere DOS attack.

I want to check my understanding of this is correct: namely store the
contents of (full width of) ra (ie the return address) at the address
pointed to by the stack pointer (sp) plus 56.

Close, it means store a "doubleword" (which means 64 bits when talking
about RISC-V) from the ra register into the address pointed at by
sp+56.

If (and this is by far the most likely) you are looking at RV64 code,
then a 64-bit store will indeed save the full width of ra.

If you are looking at RV128 code, then a 64-bit store will only store
half of ra; to store the whole 128 bits use "sq".

If you are looking at RV32 code, then the "sd" instruction is illegal
and you should use "sw" to save the full 32 bits.

Or were you asking about the memory reference syntax?  Your
interpretation of 56(sp) as the memory location addressed by sp + 56
is correct; this is the standard notation in GNU assemblers ("AT&T
syntax").  (If you're confused by some construction in RISC-V
assembly, something else you can do is look up how to do it in MIPS,
the ABI and assembler syntax is quite similar.)

On a more serious note, I made a comment about lu,l aliasing d in fcvt and it is apparent there will be some aliasing of q with 128-bit integers and floating point. Has anyone assigned a type nick? e.g. fcvt.q.cu, fcvt.cu.q, fcvt.q.c and fcvt.c.q (reserving a and au for 256-bit, rationale is in the commit message):

https://github.com/michaeljclark/riscv-meta/commit/42edf69d607ed4289b15a97ef08bc26887ec5d18

https://github.com/michaeljclark/riscv-meta/blob/master/meta/glossary

We could probably make an assembly reference table using some derivatives of these. This version of the table has operands and the other files have the rd, rs1 + imm notation (or offset as the case may be). We could perhaps generate random exemplars of each instruction with actual register names and values.

https://github.com/michaeljclark/riscv-meta/blob/master/doc/pdf/riscv-instructions.pdf

https://github.com/michaeljclark/riscv-meta/blob/master/meta/opcode-pseudocode-c

https://github.com/michaeljclark/riscv-meta/blob/master/meta/opcode-pseudocode-alt

~mc

[Adrian Mcmenamin]

On 18 September 2016 at 21:34, Michael Clark <michae...@mac.com> wrote:

On 19 Sep 2016, at 7:20 AM, Stefan O'Rear <sor...@gmail.com> wrote:

On Sun, Sep 18, 2016 at 7:11 AM, Adrian Mcmenamin <acm...@york.ac.uk> wrote:

Spike has given me this output:

sd      ra, 56(sp)

I noticed you are storing control flow information on the stack. You might want to enable SafeStack. We don’t any want C strings overwriting return addresses do we.

What I'm actually doing is looking at the memory reference patterns in a given set of embedded benchmarks (Tacle) - so I'm afraid I don't want to mess about with the source at this point.

Thanks

Adrian