When do we jump into kernel part of our process virtual memory other than when we use system calls? (In Linux)
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
This is a follow up question from my previous question.
Based on the answer, a system call is an example of when we jump into kernel part of virtual memory of our process.
What are other examples of a normal process (non kernel) using this part of virtual memory other than system calls? like is there any function call that directly jumps into this kernel part or..?
When we jump into this section of memory, does the processor automatically set the kernel mode bit to 1 in order for our process to access this part or there is no need to set this bit?
Does all of the execution inside of this kernel part happen without any need for context switching to a kernel process?
(I didn't want to ask these follow up questions on comments so I opened another thread.)
linux kernel memory virtual-memory
add a comment |Â
up vote
2
down vote
favorite
This is a follow up question from my previous question.
Based on the answer, a system call is an example of when we jump into kernel part of virtual memory of our process.
What are other examples of a normal process (non kernel) using this part of virtual memory other than system calls? like is there any function call that directly jumps into this kernel part or..?
When we jump into this section of memory, does the processor automatically set the kernel mode bit to 1 in order for our process to access this part or there is no need to set this bit?
Does all of the execution inside of this kernel part happen without any need for context switching to a kernel process?
(I didn't want to ask these follow up questions on comments so I opened another thread.)
linux kernel memory virtual-memory
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
This is a follow up question from my previous question.
Based on the answer, a system call is an example of when we jump into kernel part of virtual memory of our process.
What are other examples of a normal process (non kernel) using this part of virtual memory other than system calls? like is there any function call that directly jumps into this kernel part or..?
When we jump into this section of memory, does the processor automatically set the kernel mode bit to 1 in order for our process to access this part or there is no need to set this bit?
Does all of the execution inside of this kernel part happen without any need for context switching to a kernel process?
(I didn't want to ask these follow up questions on comments so I opened another thread.)
linux kernel memory virtual-memory
This is a follow up question from my previous question.
Based on the answer, a system call is an example of when we jump into kernel part of virtual memory of our process.
What are other examples of a normal process (non kernel) using this part of virtual memory other than system calls? like is there any function call that directly jumps into this kernel part or..?
When we jump into this section of memory, does the processor automatically set the kernel mode bit to 1 in order for our process to access this part or there is no need to set this bit?
Does all of the execution inside of this kernel part happen without any need for context switching to a kernel process?
(I didn't want to ask these follow up questions on comments so I opened another thread.)
linux kernel memory virtual-memory
linux kernel memory virtual-memory
edited 22 hours ago
Stephen Kitt
149k23332399
149k23332399
asked yesterday
John P
1608
1608
add a comment |Â
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
2
down vote
accepted
Processes running in user mode donâÂÂt have access to the kernelâÂÂs address space, at all. There are a number of ways for the processor to switch to kernel mode and run kernel code, but they are all set up by the kernel and happen in well-defined contexts: to run a system call, to respond to an interrupt, or to handle a fault. System calls donâÂÂt involve calling into kernel code directly; they involve an architecture-specific mechanism to ask the CPU to transfer control to the kernel, to run a specific system call, identified by its number, on behalf of the calling process. LWN has a series of articles explaining how this works: Anatomy of a system call part one, part two, and additional content.
If a process attempts to access memory in the kernelâÂÂs address space, it will switch to kernel mode, but as a result of a fault; the kernel will then kill the process with a segmentation violation (
SIGSEGV
).On 32-bit x86, there is a mechanism to switch to kernel mode using far calls, call gates; but Linux doesnâÂÂt use that. (And they rely on special code segment descriptors rather than calling into kernel addresses.)
See above: you canâÂÂt jump into kernel memory. In the circumstances described above, when transitioning to kernel mode, the CPU checks that the transition is allowed, and if so, switches to kernel mode using whichever mechanism is appropriate on the architecture being used. On x86 Linux, that means switching from ring 3 to ring 0.
Transitioning to kernel mode doesnâÂÂt involve a change of process, so yes, all this happens without a context switch (as counted by the kernel).
So overall cpu jumps into kernel space of a process for 3 things : 1.to run a system call 2. to respond to an interrupt 3. to handle a fault; correct? (just want to make sure i know all the situations were our CPU might need to jump into this section of our process virtual memory)
â John P
21 hours ago
1
Yes, thatâÂÂs exactly what I wrote ;-).
â Stephen Kitt
21 hours ago
1
On x86 you can see all the entry points in the kernel inarch/x86/entry
:entry_32.S
for 32-bit x86,entry_64_compat.S
for 32-bit compatibility on 64-bit x86, andentry_64.S
for 64-bit x86.
â Stephen Kitt
21 hours ago
add a comment |Â
up vote
0
down vote
1 & 2. No, a user program cannot simply use a jump instruction to enter kernel memory. It is not allowed to do so. The CPU does not automatically set the "kernel bit" to allow such a jump to succeed... (maybe some CPU has such a feature, but a secure Linux port would disable this feature)
...Actually, since you are accessing a page in a way you do not have permission to do, you will enter the kernel :-). It enters in a controlled fashion, it works very similar to a system call, but we call it a "page fault". The CPU will provide details of the access to the kernel. With the type of access you describe, the kernel will treat it as an error in your program :-). It will send a fatal signal to your program (SIGSEGV).
So what happens when a normal process wants to do a JMP into a function inside of kernel? or when it wants to jmp into the code of a system call? if it cannot access that part then what happens and how can it use that function?
â John P
yesterday
@JohnP lwn.net/Articles/604287
â sourcejedi
23 hours ago
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
Processes running in user mode donâÂÂt have access to the kernelâÂÂs address space, at all. There are a number of ways for the processor to switch to kernel mode and run kernel code, but they are all set up by the kernel and happen in well-defined contexts: to run a system call, to respond to an interrupt, or to handle a fault. System calls donâÂÂt involve calling into kernel code directly; they involve an architecture-specific mechanism to ask the CPU to transfer control to the kernel, to run a specific system call, identified by its number, on behalf of the calling process. LWN has a series of articles explaining how this works: Anatomy of a system call part one, part two, and additional content.
If a process attempts to access memory in the kernelâÂÂs address space, it will switch to kernel mode, but as a result of a fault; the kernel will then kill the process with a segmentation violation (
SIGSEGV
).On 32-bit x86, there is a mechanism to switch to kernel mode using far calls, call gates; but Linux doesnâÂÂt use that. (And they rely on special code segment descriptors rather than calling into kernel addresses.)
See above: you canâÂÂt jump into kernel memory. In the circumstances described above, when transitioning to kernel mode, the CPU checks that the transition is allowed, and if so, switches to kernel mode using whichever mechanism is appropriate on the architecture being used. On x86 Linux, that means switching from ring 3 to ring 0.
Transitioning to kernel mode doesnâÂÂt involve a change of process, so yes, all this happens without a context switch (as counted by the kernel).
So overall cpu jumps into kernel space of a process for 3 things : 1.to run a system call 2. to respond to an interrupt 3. to handle a fault; correct? (just want to make sure i know all the situations were our CPU might need to jump into this section of our process virtual memory)
â John P
21 hours ago
1
Yes, thatâÂÂs exactly what I wrote ;-).
â Stephen Kitt
21 hours ago
1
On x86 you can see all the entry points in the kernel inarch/x86/entry
:entry_32.S
for 32-bit x86,entry_64_compat.S
for 32-bit compatibility on 64-bit x86, andentry_64.S
for 64-bit x86.
â Stephen Kitt
21 hours ago
add a comment |Â
up vote
2
down vote
accepted
Processes running in user mode donâÂÂt have access to the kernelâÂÂs address space, at all. There are a number of ways for the processor to switch to kernel mode and run kernel code, but they are all set up by the kernel and happen in well-defined contexts: to run a system call, to respond to an interrupt, or to handle a fault. System calls donâÂÂt involve calling into kernel code directly; they involve an architecture-specific mechanism to ask the CPU to transfer control to the kernel, to run a specific system call, identified by its number, on behalf of the calling process. LWN has a series of articles explaining how this works: Anatomy of a system call part one, part two, and additional content.
If a process attempts to access memory in the kernelâÂÂs address space, it will switch to kernel mode, but as a result of a fault; the kernel will then kill the process with a segmentation violation (
SIGSEGV
).On 32-bit x86, there is a mechanism to switch to kernel mode using far calls, call gates; but Linux doesnâÂÂt use that. (And they rely on special code segment descriptors rather than calling into kernel addresses.)
See above: you canâÂÂt jump into kernel memory. In the circumstances described above, when transitioning to kernel mode, the CPU checks that the transition is allowed, and if so, switches to kernel mode using whichever mechanism is appropriate on the architecture being used. On x86 Linux, that means switching from ring 3 to ring 0.
Transitioning to kernel mode doesnâÂÂt involve a change of process, so yes, all this happens without a context switch (as counted by the kernel).
So overall cpu jumps into kernel space of a process for 3 things : 1.to run a system call 2. to respond to an interrupt 3. to handle a fault; correct? (just want to make sure i know all the situations were our CPU might need to jump into this section of our process virtual memory)
â John P
21 hours ago
1
Yes, thatâÂÂs exactly what I wrote ;-).
â Stephen Kitt
21 hours ago
1
On x86 you can see all the entry points in the kernel inarch/x86/entry
:entry_32.S
for 32-bit x86,entry_64_compat.S
for 32-bit compatibility on 64-bit x86, andentry_64.S
for 64-bit x86.
â Stephen Kitt
21 hours ago
add a comment |Â
up vote
2
down vote
accepted
up vote
2
down vote
accepted
Processes running in user mode donâÂÂt have access to the kernelâÂÂs address space, at all. There are a number of ways for the processor to switch to kernel mode and run kernel code, but they are all set up by the kernel and happen in well-defined contexts: to run a system call, to respond to an interrupt, or to handle a fault. System calls donâÂÂt involve calling into kernel code directly; they involve an architecture-specific mechanism to ask the CPU to transfer control to the kernel, to run a specific system call, identified by its number, on behalf of the calling process. LWN has a series of articles explaining how this works: Anatomy of a system call part one, part two, and additional content.
If a process attempts to access memory in the kernelâÂÂs address space, it will switch to kernel mode, but as a result of a fault; the kernel will then kill the process with a segmentation violation (
SIGSEGV
).On 32-bit x86, there is a mechanism to switch to kernel mode using far calls, call gates; but Linux doesnâÂÂt use that. (And they rely on special code segment descriptors rather than calling into kernel addresses.)
See above: you canâÂÂt jump into kernel memory. In the circumstances described above, when transitioning to kernel mode, the CPU checks that the transition is allowed, and if so, switches to kernel mode using whichever mechanism is appropriate on the architecture being used. On x86 Linux, that means switching from ring 3 to ring 0.
Transitioning to kernel mode doesnâÂÂt involve a change of process, so yes, all this happens without a context switch (as counted by the kernel).
Processes running in user mode donâÂÂt have access to the kernelâÂÂs address space, at all. There are a number of ways for the processor to switch to kernel mode and run kernel code, but they are all set up by the kernel and happen in well-defined contexts: to run a system call, to respond to an interrupt, or to handle a fault. System calls donâÂÂt involve calling into kernel code directly; they involve an architecture-specific mechanism to ask the CPU to transfer control to the kernel, to run a specific system call, identified by its number, on behalf of the calling process. LWN has a series of articles explaining how this works: Anatomy of a system call part one, part two, and additional content.
If a process attempts to access memory in the kernelâÂÂs address space, it will switch to kernel mode, but as a result of a fault; the kernel will then kill the process with a segmentation violation (
SIGSEGV
).On 32-bit x86, there is a mechanism to switch to kernel mode using far calls, call gates; but Linux doesnâÂÂt use that. (And they rely on special code segment descriptors rather than calling into kernel addresses.)
See above: you canâÂÂt jump into kernel memory. In the circumstances described above, when transitioning to kernel mode, the CPU checks that the transition is allowed, and if so, switches to kernel mode using whichever mechanism is appropriate on the architecture being used. On x86 Linux, that means switching from ring 3 to ring 0.
Transitioning to kernel mode doesnâÂÂt involve a change of process, so yes, all this happens without a context switch (as counted by the kernel).
edited 22 hours ago
answered 22 hours ago
Stephen Kitt
149k23332399
149k23332399
So overall cpu jumps into kernel space of a process for 3 things : 1.to run a system call 2. to respond to an interrupt 3. to handle a fault; correct? (just want to make sure i know all the situations were our CPU might need to jump into this section of our process virtual memory)
â John P
21 hours ago
1
Yes, thatâÂÂs exactly what I wrote ;-).
â Stephen Kitt
21 hours ago
1
On x86 you can see all the entry points in the kernel inarch/x86/entry
:entry_32.S
for 32-bit x86,entry_64_compat.S
for 32-bit compatibility on 64-bit x86, andentry_64.S
for 64-bit x86.
â Stephen Kitt
21 hours ago
add a comment |Â
So overall cpu jumps into kernel space of a process for 3 things : 1.to run a system call 2. to respond to an interrupt 3. to handle a fault; correct? (just want to make sure i know all the situations were our CPU might need to jump into this section of our process virtual memory)
â John P
21 hours ago
1
Yes, thatâÂÂs exactly what I wrote ;-).
â Stephen Kitt
21 hours ago
1
On x86 you can see all the entry points in the kernel inarch/x86/entry
:entry_32.S
for 32-bit x86,entry_64_compat.S
for 32-bit compatibility on 64-bit x86, andentry_64.S
for 64-bit x86.
â Stephen Kitt
21 hours ago
So overall cpu jumps into kernel space of a process for 3 things : 1.to run a system call 2. to respond to an interrupt 3. to handle a fault; correct? (just want to make sure i know all the situations were our CPU might need to jump into this section of our process virtual memory)
â John P
21 hours ago
So overall cpu jumps into kernel space of a process for 3 things : 1.to run a system call 2. to respond to an interrupt 3. to handle a fault; correct? (just want to make sure i know all the situations were our CPU might need to jump into this section of our process virtual memory)
â John P
21 hours ago
1
1
Yes, thatâÂÂs exactly what I wrote ;-).
â Stephen Kitt
21 hours ago
Yes, thatâÂÂs exactly what I wrote ;-).
â Stephen Kitt
21 hours ago
1
1
On x86 you can see all the entry points in the kernel in
arch/x86/entry
: entry_32.S
for 32-bit x86, entry_64_compat.S
for 32-bit compatibility on 64-bit x86, and entry_64.S
for 64-bit x86.â Stephen Kitt
21 hours ago
On x86 you can see all the entry points in the kernel in
arch/x86/entry
: entry_32.S
for 32-bit x86, entry_64_compat.S
for 32-bit compatibility on 64-bit x86, and entry_64.S
for 64-bit x86.â Stephen Kitt
21 hours ago
add a comment |Â
up vote
0
down vote
1 & 2. No, a user program cannot simply use a jump instruction to enter kernel memory. It is not allowed to do so. The CPU does not automatically set the "kernel bit" to allow such a jump to succeed... (maybe some CPU has such a feature, but a secure Linux port would disable this feature)
...Actually, since you are accessing a page in a way you do not have permission to do, you will enter the kernel :-). It enters in a controlled fashion, it works very similar to a system call, but we call it a "page fault". The CPU will provide details of the access to the kernel. With the type of access you describe, the kernel will treat it as an error in your program :-). It will send a fatal signal to your program (SIGSEGV).
So what happens when a normal process wants to do a JMP into a function inside of kernel? or when it wants to jmp into the code of a system call? if it cannot access that part then what happens and how can it use that function?
â John P
yesterday
@JohnP lwn.net/Articles/604287
â sourcejedi
23 hours ago
add a comment |Â
up vote
0
down vote
1 & 2. No, a user program cannot simply use a jump instruction to enter kernel memory. It is not allowed to do so. The CPU does not automatically set the "kernel bit" to allow such a jump to succeed... (maybe some CPU has such a feature, but a secure Linux port would disable this feature)
...Actually, since you are accessing a page in a way you do not have permission to do, you will enter the kernel :-). It enters in a controlled fashion, it works very similar to a system call, but we call it a "page fault". The CPU will provide details of the access to the kernel. With the type of access you describe, the kernel will treat it as an error in your program :-). It will send a fatal signal to your program (SIGSEGV).
So what happens when a normal process wants to do a JMP into a function inside of kernel? or when it wants to jmp into the code of a system call? if it cannot access that part then what happens and how can it use that function?
â John P
yesterday
@JohnP lwn.net/Articles/604287
â sourcejedi
23 hours ago
add a comment |Â
up vote
0
down vote
up vote
0
down vote
1 & 2. No, a user program cannot simply use a jump instruction to enter kernel memory. It is not allowed to do so. The CPU does not automatically set the "kernel bit" to allow such a jump to succeed... (maybe some CPU has such a feature, but a secure Linux port would disable this feature)
...Actually, since you are accessing a page in a way you do not have permission to do, you will enter the kernel :-). It enters in a controlled fashion, it works very similar to a system call, but we call it a "page fault". The CPU will provide details of the access to the kernel. With the type of access you describe, the kernel will treat it as an error in your program :-). It will send a fatal signal to your program (SIGSEGV).
1 & 2. No, a user program cannot simply use a jump instruction to enter kernel memory. It is not allowed to do so. The CPU does not automatically set the "kernel bit" to allow such a jump to succeed... (maybe some CPU has such a feature, but a secure Linux port would disable this feature)
...Actually, since you are accessing a page in a way you do not have permission to do, you will enter the kernel :-). It enters in a controlled fashion, it works very similar to a system call, but we call it a "page fault". The CPU will provide details of the access to the kernel. With the type of access you describe, the kernel will treat it as an error in your program :-). It will send a fatal signal to your program (SIGSEGV).
edited yesterday
answered yesterday
sourcejedi
20.6k42888
20.6k42888
So what happens when a normal process wants to do a JMP into a function inside of kernel? or when it wants to jmp into the code of a system call? if it cannot access that part then what happens and how can it use that function?
â John P
yesterday
@JohnP lwn.net/Articles/604287
â sourcejedi
23 hours ago
add a comment |Â
So what happens when a normal process wants to do a JMP into a function inside of kernel? or when it wants to jmp into the code of a system call? if it cannot access that part then what happens and how can it use that function?
â John P
yesterday
@JohnP lwn.net/Articles/604287
â sourcejedi
23 hours ago
So what happens when a normal process wants to do a JMP into a function inside of kernel? or when it wants to jmp into the code of a system call? if it cannot access that part then what happens and how can it use that function?
â John P
yesterday
So what happens when a normal process wants to do a JMP into a function inside of kernel? or when it wants to jmp into the code of a system call? if it cannot access that part then what happens and how can it use that function?
â John P
yesterday
@JohnP lwn.net/Articles/604287
â sourcejedi
23 hours ago
@JohnP lwn.net/Articles/604287
â sourcejedi
23 hours ago
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f473824%2fwhen-do-we-jump-into-kernel-part-of-our-process-virtual-memory-other-than-when-w%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password