On 4/27/2023 3:50 AM, Ville Juven wrote:
Hi,
I agree totally that the contents of the stack allocated wait object
(whatever) do not need validation, and the user of course cannot
access / destroy the contents.
What I did not understand before inspecting the Linux kernel code, is
how the wai
I think Xiang refers to how Linux does it. It simply creates a new
"waitobj" variable into the kernel stack by declaring it inside the
sem_wait()-equivalent function. The wait object is created into the
kernel stack, ...
Yep, I was not thinking of allocating as a local variable. So I had a
Hi,
I agree totally that the contents of the stack allocated wait object
(whatever) do not need validation, and the user of course cannot access
/ destroy the contents.
What I did not understand before inspecting the Linux kernel code, is
how the wait list integrity is ensured when the stack
Yes, this is what I said before. You don't need to validate the stack
allocated list since it comes from the kernel stack which can't be modified
or even read by the userspace code.
On Thu, Apr 27, 2023 at 3:43 PM Ville Juven wrote:
> Hi,
>
> I think Xiang refers to how Linux does it. It simply
Hi,
I think Xiang refers to how Linux does it. It simply creates a new
"waitobj" variable into the kernel stack by declaring it inside the
sem_wait()-equivalent function. The wait object is created into the
kernel stack, and a hash is calculated for the user semaphore address.
The hash is use
I didn't do a careful analysis, but glancing at the ARMv7-A code, it
looks to me that none of the things needed to create stack frames are
available for the kernel stack. It looks like the system call entry
logic just sets the SP to the top of the kernel stack and does very
little more. The a
Hi,
>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.
Not from a security perspective, and of course I
On Thu, Apr 27, 2023 at 2:18 AM Ville Juven 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 struct
On 4/26/2023 12:18 PM, Ville Juven wrote:
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.
My idea was to put the handle to this data into the user semaphore, how
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. S
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 wrote:
> Hi,
>
> Thanks for the expla
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.
Wh
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 the
On Wed, Apr 26, 2023 at 8:34 AM Ville Juven wrote:
> Hi,
>
> Thanks for pointing that out, basically the same issue I face.
>
> First I thought it would be simple to fix OR wrap around the usage of
> SEM_INITIALIZER/NXSEM_INITIALIZER/NXMUTEX_INITIALIZER. My assumption was
> that they are not used
Hi,
Thanks for pointing that out, basically the same issue I face.
First I thought it would be simple to fix OR wrap around the usage of
SEM_INITIALIZER/NXSEM_INITIALIZER/NXMUTEX_INITIALIZER. My assumption was
that they are not used in very many places in user space. For wrapping
one option w
Hi,
Some time ago I tried to fix this with
https://github.com/apache/nuttx/pull/6376 but it ended-up nowhere as I
didn't find time for a proper solution.
Best regards,
Petro
ср, 26 квіт. 2023 р. о 12:50 Ville JUven пише:
> Hi,
>
> I'm in the process of trying to fix this issue:
> https://githu
Hi,
I'm in the process of trying to fix this issue:
https://github.com/apache/nuttx/issues/8917
TL;DR semaphores are unusable when MMU is in use, because the kernel
private data of struct sem_s exists in user space and is not always
visible to the kernel when it needs it. So I'm trying to se
17 matches
Mail list logo
