-
Notifications
You must be signed in to change notification settings - Fork 29
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
Differences between QEMU and FVP on Morello #151
Comments
I have been debugging the second part of this (the cheribsdtest-purecap cap). The first failure I got was that revocation logic seems to expect PAN, which was not enabled (and broken with respect to CHERI). Possibly CheriBSD wants to assert the feature is present, as it will make it more obvious why revocation cannot work. I have fixed PAN for QEMU/CHERI, and all the tests now run to completion. cheribsdtest_caprevoke_lightly succeeds, cheribsdtest_caprevoke_capdirty and cheribsdtest_caprevoke_loadside fail. Is this expected? |
Thanks, sounds like good progress. Last I ran the tests on the FVP all of
the caprevoke tests passed.
…On Wed, Jun 23, 2021 at 16:51 LawrenceEsswood ***@***.***> wrote:
I have been debugging the second part of this (the cheribsdtest-purecap
cap). The first failure I got was that revocation logic seems to expect
PAN, which was not enabled (and broken with respect to CHERI). Possibly
CheriBSD wants to assert the feature is present, as it will make it more
obvious why revocation cannot work. I have fixed PAN for QEMU/CHERI, and
all the tests now run to completion. cheribsdtest_caprevoke_lightly
succeeds, cheribsdtest_caprevoke_capdirty and
cheribsdtest_caprevoke_loadside fail. Is this expected?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#151 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA5I266NTKKOAKM2SV3BE5TTUH7HPANCNFSM463V4VFQ>
.
|
Looks like Morello is always treating SC as trapping. I assume revocation is using the dirty tracking? |
@brettferdosi @nwf Do either of you know if revocation is reliant on HAF + DS (the hardware implementation of dirty tracking)? Providing it in QEMU seems non-trivial. Jes has had a quick look, and apparently emulation of dirty tracking might need to grow a capability version as well. |
The issue is pmap_fault doesn't have handling for CDBM+SC like it does for DBM+ATTR_S1_AP. Without capdirty we just set SC on pages and do nothing with CDBM, but with the capdirty and thus caprevoke branches that has to change and so CDBM gets set with SC expected to be set when the page is capdirtied by the hardware, and there's no corresponding fallback in pmap_fault. |
Since QEMU doesn't currently implement hardware access+dirty tracking for baseline AArch64, as far as we can tell, it seems like the best course of action is to support software capdirty tracking in pmap_fault, even though it's technically not something that should be needed per the Morello spec (at least, if you attempt to turn on hardware dirty tracking, you can still opt to have it off even on systems that support it). |
It shouldn't (I think; @brettferdosi doubtless knows better) be a problem to support "hardware is ignoring CDBM", since we have to do that on RISC-V anyway (where the situation is backwards: the wind cores don't do the AMOs but qemu does). |
I've added support for software capability dirty tracking to CheriBSD and opened a PR for fixing the way faults are generated in the QEMU model: #167. With these changes, and using the branch in this PR - CTSRD-CHERI/cheribsd#1077 - cheribsdtest_cheri_revoke_capdirty now passes on QEMU. The following tests still fail on QEMU but pass on FVP: cheribsdtest_cheri_revoke_loadside, cheribsdtest_cheri_revoke_lib, cheribsdtest_cheri_revoke_lib_fork. Probably some additional QEMU work is needed on CLG stuff but I haven't looked into it. |
Could you try the https://github.com/CTSRD-CHERI/qemu/tree/qemu-morello-wip branch? Lots of MMU bugs have been fixed. It might also need your PR, I will go have a look. |
When I try to run on that branch init crashes with a SIGBUS. |
I have observed different behavior between QEMU and the FVP in two situations. In both cases the program runs to completion on the FVP but dies with a SIGILL on QEMU.
The first situation is running a PoC on the JSC JIT. Build the JIT like this:
cheribuild webkit-morello-purecap --webkit-morello-purecap/backend tier2asm
Then run the following JS file as
poc.js
:LD_LIBRARY_PATH=/opt/morello-purecap/webkit/lib/ /opt/morello-purecap/webkit/bin/jsc /path/to/poc.js
The second situation is running cheribsdtests for revocation. Build cheribsd from this branch:
https://github.com/brettferdosi/cheribsd/tree/dev-caprevoke
then run :
cheribsdtest-purecap cheribsdtest_caprevoke_lightly cheribsdtest_caprevoke_capdirty cheribsdtest_caprevoke_loadside
The text was updated successfully, but these errors were encountered: