Bare-metal floating-point operations in lowRISC v0.3
by Imran Wali
Hi,
I need to use LowRISC v0.3 in bare-metal mode to run some programs that use floating-point operations for my research project. But all the floating-point variables seem to have zero value.
Following is a reduced example:
———————————————————————————————
#include <stdio.h>
#include <stdint.h>
#define NDecimas 1000 // printf3 decimal numbers in float
#define STM_TRACE(id, value) \
{ \
asm volatile ("mv a0,%0": :"r" ((uint64_t)value) : "a0"); \
asm volatile ("csrw 0x8ff, %0" :: "r"(id)); \
asm volatile ("nop"); \
}
void main() {
float a = 0.75;
int b = 10;
float c = a * b;
STM_TRACE(0x000a, (int)a);
STM_TRACE(0x00af, (int)(a*NDecimas)%NDecimas);
STM_TRACE(0x000b, b);
STM_TRACE(0x000c, (int)c);
STM_TRACE(0x00cf, (int)(c*NDecimas)%NDecimas);
}
———————————————————————————————
This example works fine on top of linux kernel, as can be seen in the following debug trace output:
———————————————————————————————
c3a81598 000a 0000000000000000
c3a815d4 00af 00000000000002ee
c3a815dd 000b 000000000000000a
c3a8161b 000c 0000000000000007
c3a8163b 00cf 00000000000001f4
———————————————————————————————
But when I run this code bare-metal the outcome is:
———————————————————————————————
4c493664 000a 0000000000000000
4c4936b4 00af 0000000000000000
4c4936cc 000b 000000000000000a
4c493704 000c 0000000000000000
4c49375a 00cf 0000000000000000
———————————————————————————————
I wonder if it is due to the risc-v compiler or floating-point operations are not supported in bare-metal mode at all.
Please share your ideas, how to resolve it without changing lowRISC version.
Kind regards,
Imran Wali
Postdoctoral Researcher
ARIES Research Center
Nebrija University
4 years, 8 months
Porting U-Boot to lowRISC
by Mark Corbin
Hello
I've just produced a set of patches that add RISC-V 64-bit support to
Buildroot[1]. This allows you to build a RISC-V toolchain, kernel and
rootfs (currently for a QEMU virtual target). My next plan was to
produce an image that would boot on the lowRISC using a Nexys4-DDR
board. Having looked at the differences between the riscv-pk version of
BBL and the lowRISC version of BBL, I decided that porting U-Boot to
lowRISC would be a good place to start. Hopefully this would eventually
provide some bootloader consistency between various target boards and
would also provide a method of passing a device tree to a lowRISC kernel.
I'd be interested in any work that has been done on this so far, and
would be keen to try and produce a suitable set of patches for posting
upstream.
I have a few initial questions in this area:
1) Does anybody have a suitable openocd configuration file for the
Nexys4-DDR board (and perhaps some instructions)? Ultimately I'd like to
program U-Boot to the QSPI flash, but initially I could use openocd to
download and run a copy in RAM.
2) Which files are used to generate the default boot.mem for the
Nexys4-DDR? I thought that it might be bare_metal/examples/boot.c, but
I'm not sure.
3) Where is the memory configuration done for the Nexys4-DDR? I can see
memory configuration for the KC705 in kc705/examples/boot.c, but I can't
find any equivalent for the Nexys4-DDR, and there is nothing in
bare_metal/examples/boot.c.
Thanks
Mark
[1] https://buildroot.org/
--
Mark Corbin
Embecosm Ltd.
https://www.embecosm.com
4 years, 8 months
Re: encrypted pointers, encrypted code and encrypted memory.
by Alex Bradbury
On 18 September 2018 at 21:43, Michael Clark <michaeljclark(a)mac.com> wrote:
> Hi Folks,
>
> I guess this is probably appropriate for the security or crypto working
> groups but I thought it might be worthwhile to promote some public
> discussion on “encrypting the computer” vs “computing encryption”, the
> rationale being to add to the pool of methods, whether in formal academic
> papers or methods and ideas published on mailing lists or short essays.
>
> Background: My particular interest that led me to RISC-V was piqued by the
> lowRISC project, particularly the work on tagged pointers, as part of
> self-study investigating security vulnerabilities and mitigations, combined
> with some cryptography research.
>
> I’m emailing today because of the recent release of arm authenticated
> pointers which are now in production on iOS 12 devices. I believe the
> lowRISC work, and a general body of work in this area predates arm’s
> authenticated pointers. There are several papers that publish well known
> schemes for in-memory permutations of binary images, control flow integrity
> via keys in landing pads and many other techniques to thwart modern attacks
> such as ROP.
>
> I wrote a short essay, possibly inspired in part by the lowRISC project, and
> previous experiences, reading in cryptography. The essay if high-level,
> mentions storing keys in the unused address bits of canonical pointers which
> we all know are presently all zeros or all ones in the conventional
> canonical pointer scheme. The essay is titled Crypto Binary Translation:
>
> https://github.com/michaeljclark/rv8/blob/master/doc/src/bintrans.md
Hi Michael, thanks for starting this discussion and sharing your thoughts.
Regarding obfuscating binaries, it would be worth looking at prior
work on "software diversification". This paper seems to provide a good
overview of work in this area
<https://www.ics.uci.edu/~perl/automated_software_diversity.pdf>. As
work like blind ROP shows
<http://www.scs.stanford.edu/brop/bittau-brop.pdf>, attackers may
still be able to extract sufficient information about the binary to
craft a successful exploit even without access to the target
executable. You might also be interested in looking up work on
instruction set randomisation, which attacks the same problem from a
slightly different angle.
For encrypted pointers I think you'd be interested in reading
Cryptographically Enforced Control Flow Integrity
<https://arxiv.org/pdf/1408.1451.pdf>. It notes that with a 48-bit
address space, the remaining 16-bits of a 64-bit pointer could be used
for other metadata. Though I think it only actually uses a single bit
to differentiate function pointers vs return address.
Obviously embedding metadata within pointers isn't a new idea. A
128-bit capability representation was proposed in an MIT tech report
in 2000 (co-authored by Andrew 'bunnie' Huang)
<http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-05.pdf>.
It observed that a 64-bit encoding would be practical, using 48-bits
for the address and the other 16-bits to encode bounds information.
This idea was revisited much later with "low-fat pointers"
<http://www.crash-safe.org/assets/fatptr_ccs2013.pdf>. The CHERI
project of course also explores various capability representations.
Dynamic language runtimes also like to exploit unused address bits. As
this bug report shows
<https://bugzilla.mozilla.org/show_bug.cgi?id=1143022> this can lead
to portability issues if there is no kernel co-operation. For a long
time, I've thought it would be neat to have a configurable mask to
control which bits of a virtual address are ignored, and we discussed
this a bit on isa-dev a couple of years ago
<https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/Pm9mso-urM8/nR...>.
Cesar Eduardo Barros suggested a modification of the idea that has
less flexibility in hardware, but provides the same interface to the
process by having the kernel set up extra page mappings
<https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/Pm9mso-urM8/Ji...>.
I think such a mechanism alongside 1 or more tag bits to mark
integrity of the embedded pointer metadata is an interesting and
potentially powerful combination.
Best,
Alex
4 years, 8 months