On Thu, Apr 27, 2023 at 2:18 AM Ville Juven <ville.ju...@gmail.com> wrote:
> Hi, > > Yes exactly, this is the basic idea. Like I said, the waitlist/holder > structure is needed only when sem_wait needs to block / wait for the > semaphore to become available. > > How to protect the integrity of the stack allocated structure is still a > bit open but one option is to use kheap as well. Semantics to be figured > out, the solution should be feasible. > But, why need involve kheap here? If the security is your concern, you should enable per-thread kernel stack in the first place. It's safe to allocate waitlist/holder from this stack directly, since userspace code can't touch this area too. > My idea was to put the handle to this data into the user semaphore, however > a pointer must not be used, a handle / integer id is needed, which then > holds the pointer (much like files etc). As the user can spoof / destroy > the pointer it is unsafe to do that. Spoofing the id can cause the user > process to crash, but the kernel integrity remains. > > But, which scenario needs to access kernel struct through user semaphore? > Br, > Ville Juven > > On Wed, Apr 26, 2023 at 9:09 PM Xiang Xiao <xiaoxiang781...@gmail.com> > wrote: > > > But why not allocate list entry and holder temporally inside the kernel > > thread stack? Both data is just used when the calling thread can't hold, > > but wait the semphare, this trick is widely used inside Linux kernel. > > > > On Thu, Apr 27, 2023 at 1:32 AM Ville Juven <ville.ju...@gmail.com> > wrote: > > > > > Hi, > > > > > > Thanks for the explanation, it makes sense. I had an idea to move > struct > > > sem_s entirely to kernel and make the user use it via a handle (in > KERNEL > > > build) but due to the ubiquitous init macros, that is not a feasible > > > solution. > > > > > > I will explore allocating the kernel structures on-demand next. > > > > > > What does this mean ? The kernel side structures (dq_waitlist and > > priority > > > inheritance holders) are only needed when the semaphore is locked and > > > someone is actually waiting for it to be released. This means that when > > > sem_wait() results in the thread getting blocked, the kernel part can > be > > > allocated here and a reference placed into the user sem_t structure. > When > > > the semaphore unlocks, the kernel parts can be freed. > > > > > > This should be completely regression free for FLAT/PROTECTED, which is > > very > > > important for me because I don't want to be responsible for breaking > > such a > > > fundamental OS API for current users ;) > > > > > > Br, > > > Ville > > > > > > On Wed, Apr 26, 2023 at 5:26 PM Gregory Nutt <spudan...@gmail.com> > > wrote: > > > > > > > > > > > > I have a question about using mutex_t / struct mutex_s inside > > > > > libs/libc. The mutex_t definition is kernel internal but some > modules > > > > > inside the libs folder use it directly. My question is, is this > > > > > intentional ? I don't think such modules should be using mutex_t. > > > > > > > > > > ... > > > > > > > > > > My question ? Should these be sem_t or perhaps pthread_mutex_t ? > Both > > > > > of which are valid user APIs. > > > > > > > > It was sem_t before it was changed to the non-standard mutex_t. See > > > > commit d1d46335df6: > > > > > > > > commit d1d46335df6cc1bc63f1cd7e7bffe3735b8c275d > > > > Author: anjiahao <anjia...@xiaomi.com> > > > > Date: Tue Sep 6 14:18:45 2022 +0800 > > > > > > > > Replace nxsem API when used as a lock with nxmutex API > > > > > > > > Signed-off-by: anjiahao <anjia...@xiaomi.com> > > > > Signed-off-by: Xiang Xiao <xiaoxi...@xiaomi.com> > > > > > > > > Parts of the above which introduce inappropriate use of mutex_t could > > be > > > > reverted back to sem_t. Any use of any non-standard OS function or > > > > structure should be prohibited in application code. > > > > > > > > However, nuttx/libs is a special creature. It is not confined by the > > > > rules of POSIX interface because user-space libraries are a > > > > non-privileged extension of the operating system. They have intimate > > > > knowledge of OS internals and can do non-standard things to > accomplish > > > > what they need to do. So although I think it is wrong > architecturally > > > > for applications to use OS internals, I don't think it is wrong for > > > > nuttx/libs to do so. It is a friend of the OS. > > > > > > > > But it is should not break the KERNEL build either. > > > > > > > > Perhaps we will need a user-space function to allocate (and > initialize) > > > > kernel memory. Use of such functions should not performed outside of > > > > nuttx/libs, although we have no way to prohibit that use: Such an > API > > > > would be a security hole. user-space code cannot access kernel > memory, > > > > but it can use the kernel memory address like a "handle" to interact > > > > with the OS. > > > > > > > > > > > > > > > > > >
