Hi, thanks again for the responses and bearing with me
> I believe that all of the lists and structures that you are concerned
> with are already allocated from kernel space memory, but I have not
The lists do exist in user memory, although I agree that they should not.
> verified that it all cases. Certainly, they are things that would
> never be accessed from user space
Absolutely correct, the user does not need them nor should they be
accessed/accessible by the user. However, they can be accessed, either
intentionally, or by accident (e.g. via memcpy, memset, etc). Which means
the user really can mess the lists up, causing the kernel to crash.
> I would say that, as a rule, nothing in user space should have any
> knowledge or access to the internals of a sem_t. Looking at
> libs/libc/semaphore, I don't believe that there is any,.
You are correct, the API does not access or provide access to those kernel
fields, but when a user instantiates sem_t, those kernel control fields
also go to user space. They are also accessible to the user process via the
named struct fields e.g. sem->waitlist.
The following stupid user space example will compile and run just fine as
the full composition of sem_t is visible to the user. The worker thread can
access sem->waitlist and completely mess up the doubly linked queue, from
user space.
#include <semaphore.h>
sem_t sem;
void worker(void *arg)
{
sem.waitlist = (void *)0xDEADBEEF;
sem_post(&sem);
}
int main(int argc, char *argv[])
{
sem_init(&sem, 0, 0);
...
spawn the worker thread here!
...
sem_wait(&sem);
return 0;
}
The hhead objects are an exception, they are allocated from kernel space.
But struct semholder_s holder[2]; is defined inside sem_t, thus if
CONFIG_SEM_PREALLOCHOLDERS == 0, whenever sem_t is instantiated those go to
user space too.
hhead is not safe either, the user can mess up the priority inheritance
list as well, by setting sem.hhead = (void *)0x592959;
If there is something I'm missing I apologize for the spam, but I have
indeed verified that the lists are not accessible by the kernel unless the
correct process is running, which means the correct user mappings are
active and the user memory is visible to the kernel.
Br,
Ville Juven
On Wed, Apr 19, 2023 at 4:53 PM Gregory Nutt <spudan...@gmail.com> wrote:
>
> >> However, as I said, there are some things in the sem_t structure whose
> >> usage is ubiquitous and I don't know if the scalar access macros will be
> >> enough, i.e. I don't fully understand how they work / are supposed to
> >> work.
> >> ...
> >
> > I believe that all of the lists and structures that you are concerned
> > with are already allocated from kernel space memory, but I have not
> > verified that it all cases. Certainly, they are things that would
> > never be accessed from user space. The user memory sem_t "container"
> > just holds references to kernel space allocations.
> >
> > If I am correct, then you should not have any problems. But, as I
> > said, I did not verify all of that.
> I would say that, as a rule, nothing in user space should have any
> knowledge or access to the internals of a sem_t. Looking at
> libs/libc/semaphore, I don't believe that there is any,.
>
>
>
