Hi Sam, this issue call my attention... if you are right you may have
potentially found some security issue, which is an area I am very
interested....
I'm curious... How are you "debugging"...? I guess you just set some check
points in your code and inspect the memory....? Have you tried to:
1) automate repeating the process causing the dirty memory many times
2) dumping the offending bytes in the memory
3) try to give some sense to those bytes (to try find where they come
from...)...
I know this may not directly help solve the issue but it may at some point
put some light on it...
Best,
El sáb, 11 mar 2023 a las 1:06, Sam Leffler via Devel (
On Fri, Mar 10, 2023 at 3:28 PM Kent Mcleod
wrote: On Sat, 11 Mar 2023, 09:40 Sam Leffler via Devel,
wrote: I'm chasing an issue that looks like retype'd memory has nonsense data.
If
I read the kernel code correctly it looks like the object returned by an seL4_UntypeRetype syscall should be zero'd (looks to happen when an untyped memory object is reset here https://github.com/seL4/seL4/blob/master/src/object/untyped.c#L254). Is that correct? I don't see anything called out in the manual
If the untyped isn't device untyped then it should be zeroed before it is typed into an object. Device untyped is not allowed to be accessed by the kernel and so is not written to.
When are you observing the odd behaviour?
I've got a stress test that forces lots of memory recycling by creating, running & tearing down applications. I repeatedly see a particular point in the test (after memory starts being recycled) where an app gets an instruction fault. Narrowing the issue has been challenging so I'm questioning everything (including cache handling). This is all anonymous memory.
-Sam _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems
_______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems