Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PMP address range bug in QEMU #25

Open
dayeol opened this issue Jan 9, 2019 · 5 comments
Assignees
Labels

Comments

@dayeol
Copy link
Contributor

@dayeol dayeol commented Jan 9, 2019

SM region is accessible even there is the first PMP entry holding a right NAPOT-decoded address range covering the entire SM.
I suspect QEMU because this didn't happen before bumping QEMU to the latest version.
But the security monitor could be wrong, so we need more inspection.

@dayeol dayeol added the Bug label Jan 9, 2019
@dayeol dayeol changed the title PMP address range bug PMP address range bug in QEMU Jan 9, 2019
@dayeol

This comment has been minimized.

Copy link
Contributor Author

@dayeol dayeol commented Jan 9, 2019

Tested in older version of QEMU and SiFive Unleashed.
Results when I try to access 0x80000000:
(1) Older QEMU - hangs

root@ucbva:~# busybox devmem 0x80000000
[hangs]

(2) SiFive Unleashed - kernel fault (works good)

# devmem 0x801ffff0
[   26.586560] devmem[147]: unhandled signal 11 code 0x2 at 0x000000000001be9c in busybox[10000+94000]
[   26.594843] CPU: 1 PID: 147 Comm: devmem Tainted: G        W        4.15.0-00082-g49ec1028b07c #31
[   26.603782] sepc: 000000000001be9c ra : 000000000001bdde sp : 0000003fffb8bb40
[   26.610984]  gp : 00000000000a64b0 tp : 0000002000157710 t0 : 000000000000013a
[   26.618192]  t1 : 00000020000d68fe t2 : ffffffffffffffff s0 : 0000000000000020
[   26.625391]  s1 : 0000000000000ff0 a0 : 0000002000159000 a1 : 0000000000002000
[   26.632603]  a2 : 0000000000000001 a3 : 0000000000000001 a4 : 0000000000000020
[   26.639808]  a5 : 0000002000159ff0 a6 : 0000000000000000 a7 : 00000000000000de
[   26.647009]  s2 : 0000000000000002 s3 : 0000003fffb8bd90 s4 : 0000000000000003
[   26.654222]  s5 : 0000000000002000 s6 : 0000002000159000 s7 : 0000000000000014
[   26.661426]  s8 : 0000002000157720 s9 : 00000000000a8000 s10: 0000000000000000
[   26.668634]  s11: 00000000000ac6d5 t3 : 000000000009e8fe t4 : 0000000000000002
[   26.675833]  t5 : 0000002000039eec t6 : 0000000000000000
[   26.681138] sstatus: 8000000200006020 sbadaddr: 0000002000159ff0 scause: 0000000000000005
Segmentation fault
@dayeol

This comment has been minimized.

Copy link
Contributor Author

@dayeol dayeol commented Jan 9, 2019

Obviously QEMU

@dayeol

This comment has been minimized.

Copy link
Contributor Author

@dayeol dayeol commented Jan 23, 2019

@dayeol dayeol added Duplicate Bug and removed Bug Duplicate labels Jan 23, 2019
@dayeol

This comment has been minimized.

Copy link
Contributor Author

@dayeol dayeol commented Apr 1, 2019

So far, those issues are not being handled by QEMU folks.
We might need to fix them ourselves

@dayeol dayeol added QEMU bug and removed Bug labels Apr 2, 2019
@silviuk

This comment has been minimized.

Copy link

@silviuk silviuk commented Aug 7, 2019

Has this qemu bug been fixed in upstream so that can keystone be tested correctly in qemu now?
The riscv-qemu fork page linked in the documentation says "The RISC-V QEMU Port is Upstream".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.