[mit 6.S081]Lecture 3 OS Organization and System Calls笔记

OS 同时被 2 个专栏收录
3 篇文章 0 订阅
12 篇文章 0 订阅

Lecture 3 OS Organization and System Calls

  • UNIX interface

  • abstract the hardware resources

    • process: instead CPU
    • exec: instead of memory
    • file: instead of disk block
  • OS should be defensive

    • app cannot crash the OS
    • app cannot break out of its isolation
  • strong isolation between apps and os

    • typical: hardware support
      • user/kernel mode
      • virtual memory
  • user/kernel mode

    • kernel: privileged instructions(setting up page table register, disabling clock interrupt… )
    • user: unprivileged instructions(add, sub, jr, branch…)
  • CPUs provide virtual memory

    • page table: virtual address -> physical address
    • process has own page table
    • memory isolation
  • Entry Kernel

    • ecall <n> (n mean system call number that the application wants to invoke)
      • (user)fork() -> (user)ecall sys_fork() -> (kernel)syscall() -> (kernel)fork()
      • (user)write() -> (user)ecall sys_write() -> (kernel)syscall() -> (kernel)write()
  • kernel = trusted computing base(TCB)

    • kernel must have no bug
    • kernel must treat processes as malicious
    • security
  • monolithic kernel design(stick the whole operating system in kernel mode)

    • no good for os bugs
    • tight integration -> performence
  • micro kernel design(focuses on reducing the amount of code in the kernel)

    • kernel is small -> few bugs
    • difficult to get high performance
  • kernel

    • proc.c -(gcc)-> proc.S(RISC-V) -(assembler)-> proc.o
  • QEMU emulate RISC-V

for(; ;){
	read instruction;
	decode instruction;
	executes instruction;

kernel: privileged instructions(setting up page table register, disabling clock interrupt… )

user: unprivileged instructions(add, sub, jr, branch…)

Do more complex kernels try to reschedule process on the same core to reduce cache misses?

Yes, there’s something called cache affinity, you know this conversion in a modern operating systems are very sophisticated and indeed you know trying to avoid cache misses and things like that and to optimise the performance.

Who is running the code and checking if it’s kernel mode and how do they know if it’s in kernel mode?

So basically flag in the processor, literally there’s a bit in the processor, that’s just you know user mode you know one is saying, typically one is usual mode, zero is kernel mode. And so when the processor decodes an instruction, looks at the opcode, if the opcode is privilege instruction and the bit is set to one and will deny executing the instruction.

If all user code does go through the kernel, the intent is that things are secure, but is there a way for a user of the computer to completely go around the operating system?

No, at least if done carefully not, and if possible, that might be the case that some programs have additional privileges that the operating system will respect, but those privileges are not given to every user, only root user has certain privileges that allow you to do security sensitive operations.

What about BIOS, does BIOS happened before os or after?

The BIOS is a piece of software that basically comes with the computer, and that 's booted first and the BIOS basically boots the operating system, so the BIOS is a trusted piece of code, and better be correct and better be not malicious.

Where does the kernel basically decide whether this application should be able to invoke this particular kernel syscall?

In principle, on the kernel size correct when we actually fork and runs, it can implement any secure check it wants, you could look at the arguments in the system call and decide whether actually the application should be allowed to execute the system call fork. Now in user in UNIX, any application can actually call fork, but let’s say take write, you know write, you need to check whether, the implementation of write needs to check whether the address that is actually passed into write actually is part of the user applications, and so that you know the kernel is not correct to writing a data from somewhere else it actually doesn’t belong to the application,

How did the kernel seize back control from a user application, in the case where the user application is acting maliciously or in an infinite loop?

The kernel actually programs the hardware to set a timer, and after the timer goes off, that will cause a transfer from user space to kernel mode, at that point the kernel is back in control and then the kernel can reschedule the CPU to another process.

What drives the designers of an operating systems implementation to use a language like C?

C give you a lot of control over hardware and so for example, you know you need to program the time chip and in C that is actually easy to do, because you can get a lot of low-level control over any hardware resource and partly because you can cast anything to anything, so C is basically very convenient programming language, if you have to move very low-level programming particularly interacting with hardware.

Lecture1 Introduction And Example

  • 1
  • 0
  • 1
  • 打赏
  • 扫一扫,分享海报

©️2022 CSDN 皮肤主题:深蓝海洋 设计师:CSDN官方博客 返回首页




¥2 ¥4 ¥6 ¥10 ¥20
余额支付 (余额:-- )



钱包余额 0