"During system calls, the user mode thread’s access to the system call and
the *passed-in parameters are all validated*.
I think this is a fine thing to do and would welcome such checks into
the OS. We would have to be careful. In the case of read(), for example:
ssize_t read(int
But stub call into the real and complex implementation and then the
kernel stack will contain many return address point, the hack can
command kernel write what he want into this region and modify some
return address point to that region, then the kernel will jump to the
code eventually.
That
On Wed, Feb 26, 2020 at 12:34 AM Gregory Nutt wrote:
>
> On 2/25/2020 10:26 AM, Xiang Xiao wrote:
> > On Tue, Feb 25, 2020 at 11:59 PM Gregory Nutt wrote:
> >> Hi,
> > i meant that, if userspace wants to read some kernel memory, it can pass
> > the kernel pointer to eg. write system call
On Tue, Feb 25, 2020 at 5:27 PM Gregory Nutt wrote:
>
> > ... How are syscalls dealt in other RTOS using MPU?
>
> For the case of the MPU, there is no general answer to that. I don't
> think that there is any standard model for the use of the MPU in a
> Unix-like system.
>
> NuttX uses the MPU
On 2/25/2020 10:26 AM, Xiang Xiao wrote:
On Tue, Feb 25, 2020 at 11:59 PM Gregory Nutt wrote:
Hi,
i meant that, if userspace wants to read some kernel memory, it can pass
the kernel pointer to eg. write system call as the buffer argument,
and then read the contents of the file.
I guess I
... How are syscalls dealt in other RTOS using MPU?
For the case of the MPU, there is no general answer to that. I don't
think that there is any standard model for the use of the MPU in a
Unix-like system.
NuttX uses the MPU to create a Kernel space with the OS and critical
board logic
On Tue, Feb 25, 2020 at 11:59 PM Gregory Nutt wrote:
>
> Hi,
> >>
> >>> i meant that, if userspace wants to read some kernel memory, it can pass
> >>> the kernel pointer to eg. write system call as the buffer argument,
> >>> and then read the contents of the file.
> >> I guess I still don't
On Tue, Feb 25, 2020 at 10:59 AM Gregory Nutt wrote:
I think that most syscall which contain pointer has the security issue
in PROTECTED/KERNEL mode.
Certainly if high security is need, they all should be reviewed. Linux
goes to a lot of trouble to access data pointed to by user-provided
On Tue, Feb 25, 2020 at 5:08 PM Nathan Hartman
wrote:
> ...
>
If you need the sort of "security" that makes it possible to run
> totally untrusted code, then maybe you need a full blown operating
> system, which also comes with a full blown computer and not an
> embedded microcontroller.
>
Hello,
I dont agree. A fundamental feature to avoid widespread developement of
the so-called Internet of Shit is basic embedded security.
Some thoughts:
An embedded system can have a minimal security. Of course security has
several levels from non-existent to ideal.
Not having a full PKI
On Tue, Feb 25, 2020 at 10:59 AM Gregory Nutt wrote:
> > I think that most syscall which contain pointer has the security issue
> > in PROTECTED/KERNEL mode.
>
> Certainly if high security is need, they all should be reviewed. Linux
> goes to a lot of trouble to access data pointed to by
Hi,
i meant that, if userspace wants to read some kernel memory, it can pass
the kernel pointer to eg. write system call as the buffer argument,
and then read the contents of the file.
I guess I still don't understand. Access is still via file descriptor.
You could certainly clobber kernel
On Tue, Feb 25, 2020 at 10:08 PM Gregory Nutt wrote:
>
>
> > i meant that, if userspace wants to read some kernel memory, it can pass
> > the kernel pointer to eg. write system call as the buffer argument,
> > and then read the contents of the file.
> I guess I still don't understand. Access is
i meant that, if userspace wants to read some kernel memory, it can pass
the kernel pointer to eg. write system call as the buffer argument,
and then read the contents of the file.
I guess I still don't understand. Access is still via file descriptor.
You could certainly clobber kernel
On Fri, Feb 21, 2020 at 10:29 PM Gregory Nutt wrote:
>
>
> > while looking at PROTECTED build,
> > i noticed that it was trivial for userspace code to bypass the
> > protection and access kernel memory.
> > eg. by passing kernel pointer to system calls.
> > and it seems that it isn't the only way
while looking at PROTECTED build,
i noticed that it was trivial for userspace code to bypass the
protection and access kernel memory.
eg. by passing kernel pointer to system calls.
and it seems that it isn't the only way for userspace to trick the kernel.
I am not clear how that would work.
hi,
while looking at PROTECTED build,
i noticed that it was trivial for userspace code to bypass the
protection and access kernel memory.
eg. by passing kernel pointer to system calls.
and it seems that it isn't the only way for userspace to trick the kernel.
are these by design? eg. not a
17 matches
Mail list logo