Rand call and valid memory locations

(David Schuster) #1

Rand call is giving me memory addresses in the kseg1 range which is unmapped how are we supposed to handle this?

(Geoffrey Challen) #2

Like any other bogus address passed to a system call. You don’t need to care where they are. Just handle them appropriately and everything will be fine.

(Ryan Kody Taylor) #3

I’m struggling with the same issue. Brute-force address checking is not the answer. Did you ever find a way to properly check for invalid addresses?

(Zachary Scott Moore) #4

Your error checking within the syscall should be able to handle the error and return the correct error.

Check the man pages and all the errors and make sure they can be caught.

It is okay for some of the syscalls to return errors in rand call.

(Ryan Kody Taylor) #5

Yes, I understand that badcall tests and randcall tests often try to generate errors on purpose, and the syscalls should return errors to pass the tests.

My problem is trying to identify precisely when to throw the EFAULT error within syscalls that take pointers. How do I verify whether a passed in pointer is valid or not without, for instance, brute-force address checking for 0x40000000? copyin and copyinstr apparently are not covering this for me.

(Geoffrey Challen) #6

You need to use copyout to safely return the value through the pointer. If copyout returns an error, then fail the system call and return.

Note that this can happen late in the system call when you are copying out a value, so it may seem strange to (for example) successfully wait on a child process only to fail while copying out the exit code. But that can happen.

(Ryan Kody Taylor) #7

Well, I did in fact omit error checking on the copyouts in execv, so that could’ve been my problem.

Thank you for the help.