First page Back Continue Last page Summary Graphics
Honeypot quirks
STACK_TOP > TASK_SIZE
Filesystem assumes STACK_TOP==TASK_SIZE
Filenames checked in getname() without calling verify_area()
Stack must be prevented from expanding into kernel VM area
Notes:
Separating the process stack from the rest of the process address space and locating it above the kernel is untraditional, to say the least. And it causes problems. This arrangement causes the value of STACK_TOP, which defines the top address of process stacks, to be greater than the value of TASK_SIZE, which defines the end of the process address space.
Reasonably, the generic kernel expects that STACK_TOP will be less than or equal to TASK_SIZE. The fact that it isn't causes surprisingly few problems. This can mostly be papered over in the verify_area macro, which the architecture gets to define.
However, filename arguments are not checked for validity by verify_area. Instead, the filesystem checks the addresses itself by comparing them to TASK_SIZE. Since filenames that are on the stack will have address greater than that, they will fail the address check and the system call will return -EFAULT.
A second problem resulting from this arrangement is that the process stack will extend into the kernel VM area if it's allowed to grow too big. This is dealt with in the UML segfault handler.