Gem5 se mode is non-os mode, but i am able to execute row-hammer code on it which has commands with os dependencies.But if there is no os in se mode then how are they executed in se mode.
Most userland allowed instructions just do the usual thing, which is to change the state of the the CPU slightly: touch registers + cache + memory.
Then when a syscall instruction is reached, the syscall is forwarded to the host which actually takes action.
However, this also requires some extra bookkeeping by the OS, which is why every single syscall must be implemented separately.
If I wanted to learn this :-) I would look at the implementation of a simple syscall like brk:
https://github.com/gem5/gem5/blob/5d442571eff5116551609ee7a3b63a3b9d27ff45/src/arch/x86/linux/process.cc#L223
https://github.com/gem5/gem5/blob/5d442571eff5116551609ee7a3b63a3b9d27ff45/src/sim/syscall_emul.cc#L212
I would also look into QEMU user mode, I think it will be a similar concept there, but with potentially more material available.
Maybe someone with a better understanding can explain further in more detail, and annotate specific parts of the code further.
Related
I'm new to RISC-V and operating system developing, and I'm now trying to make a simple hypervisor-like interface in RISC-V. What stops me right now is that I have no idea about how to trigger a machine call (like RISC-SBI) which stands in firmware level and machine-mode for a user-mode applications? Since recently user-level applications communicate with kernel by system calls. However I may have to make the call skip the kernel and directly to the firmware. How to achieve this for a high-levl application?
I' really in a difficult time. So much thanks for your replies.
To make a system call, load register a0 with which call you want to make (and possibly arguments to the syscall in other registers), then execute an ecall instruction with 01 in func3, which specifies Supervisor mode. To return to user mode after executing the system call code, the OS kernel executes an sret instruction, which returns to User mode from Supervisor mode. This is documented in the Privileged Architecture specification, but I'll admit it requires a bit of knowledge ahead of time to figure out where to look.
My question is quite simple.
I encountered this sys_vm86old syscall (when reverse engineering) and I am trying to understand what it does.
I found two sources that could give me something but I'm still not sure that I fully understand; these sources are
The Source Code and this page which gives me this paragraph (but it's more readable directly on the link):
config GRKERNSEC_VM86
bool "Restrict VM86 mode"
depends on X86_32
help:
If you say Y here, only processes with CAP_SYS_RAWIO will be able to
make use of a special execution mode on 32bit x86 processors called
Virtual 8086 (VM86) mode. XFree86 may need vm86 mode for certain
video cards and will still work with this option enabled. The purpose
of the option is to prevent exploitation of emulation errors in
virtualization of vm86 mode like the one discovered in VMWare in 2009.
Nearly all users should be able to enable this option.
From what I understood, it would ensure that the calling process has cap_sys_rawio enabled. But this doesn't help me a lot...
Can anybody tell me ?
Thank you
The syscall is used to execute code in VM86 mode. This mode allows you to run old "real mode" 32bit code (like present in some BIOS) inside a protected mode OS.
See for example the Wikipedia article on it: https://en.wikipedia.org/wiki/Virtual_8086_mode
The setting you found means you need CAP_SYS_RAWIO to invoke the syscall.
I think X11 especially is using it to call BIOS methods for switching the video mode. There are two syscalls, the one with old suffix offers less operations but is retained for binary (ABI) compatibility.
possibly a really dumb question, but could someone explain why one could not write assembly code to trigger system functions or control hardware? For example, would it not be possible to write code to switch screen off/on or even the device's phone?
I am not talking about jailbreaking the device, nor making an app for the app store. Normal app with assembly to call system functions.
If indeed possible, anyone have a good reference or starting point of achieve such tasks?
Thanks
iPhones use a memory-protected operating system in which each user process is contained in its own virtual memory address space. The address space is protected by the memory management unit (MMU) hardware and trying to access memory outside of regions given to the process by the OS will result in an exception. The OS reserves hardware memory ranges to itself and does not make it available to user processes. As such, it is not possible to directly interface to the hardware from a user process.
It is certainly possible to call system functions from assembly code. And what do you think a C or C++ application does? It does exactly that. C/C++ and assembly code all ultimately convert (at compile time) into machine code that the CPU executes.
I'm not sure where the guide would be for doing things like this, but you can certainly run a C program in a debugger and see how it calls various system functions or you can disassemble this program and read the disassembly without running the program in the debugger.
In any event, you will not get more control over the device from a program written in assembly than from a program written in C. The OS should restrict direct access to certain I/O devices and memory areas at the CPU level, where there's no distinction between assembly and C, it's all the same to the CPU, just a bunch of instructions in machine code.
So I got a new computer for Christmas and it came with Windows 8 pre-installed. Now I've had MORE than enough trouble getting it to run both Linux Ubuntu and W8 on the same drive. Having 2 operating systems of a single hard drive requires that the drive be partitioned so that 2 OS's do not conflict with each other. Now there is a program called Mini Partition Tool Wizard which runs inside Windows 8(and there is a similar program for Linux called gparted) which allows you to created and resize hard disk partitions so long as you don't overwrite the operating system that you're currently using.
To make a long story short: I am wanting to write my very own mini operating system that is to be used exclusively for boot control and hard disk management. That is, once I get it written, debugged, and compiled into executable code I will put it on a USB memory stick that I can boot from in the BIOS menu and then directly set up hard drive partitions and even format my hard drive if necessary. I'm quite astonished that BIOS doesn't have the user options of doing it yourself.
So my question is: Can I do this exclusively using the tools of C/C++? Or do I need to have inline assembly code? Or perhaps write an assembly code module that is used in a C++ program. Pretty sure that Mini Partition Tool Wizard is not open source(neither is Windows). Never written and OS before so I'm a n00b to this but willing and able to take the time to learn how it's done.
Can I do this exclusively using the tools of C/C++? Or do I need to have inline assembly code?
You will need some assembly and not the inline kind. Your compiled C/C++ code expects a number things to be set up and configured already (e.g. the 32-bit protected mode of the CPU, the stack, values of the various CPU registers, device drivers, interrupts, the C/C++ memory manager, etc), while the BIOS simply loads one 512-byte-long sector from a disk and transfers control to it, without setting up anything, with the CPU still being in the 16-bit mode.
So, you'd need to write some assembly code to:
load more stuff from the disk, you don't suppose everything will fit into 512 bytes, do you?
switch the CPU into the 32-bit protected mode
reconfigure the interrupt controller so the interrupts do not map onto the same interrupt vectors as protected mode exceptions (well, this tiny part can be done in C)
write exception handlers
write interrupt handlers for the basic stuff like the timer and the keyboard (if designed carefully, you may only need to do a small part of this in assembly and the rest can be done in C)
And then you'll need to write 32-bit I/O device drivers for everything else since after the switch you can't use the BIOS's. Alternatively, you could implement a virtual 8086 machine (using the virtual 8086 mode) in order to delegate this stuff back to the BIOS and that's not a trivial thing either. Most of this can be done in C, but some knowledge or use of assembly code will still be necessary.
You'll also need to reimplement some parts of the standard library of C (C++), so malloc()/new, putch(), getchar(), fopen(), time() and so on use your low-level APIs instead of Windows' or Linux'.
Prepare to burn a couple of years to get from nothing and lack of knowledge and experience to something working.
And yeah, you can indeed start learning stuff at osdev.org. There are some useful newsgroups as well: comp.lang.asm.x86 and alt.os.development.
I was just wondering whether the switch between the kernel mode and the user mode in an operating system is done by the hardware or the os itself.
I understand that when a user process wants to get into kernel mode it can make a system call and execute some kernel code. When the system call is made, the process goes into the kernel mode and now all memory becomes accessible, etc. In order for this to happen, I would assume that the interrupt handler needs to switch or alter the page table. Is this true? If not, how does the CPU know, that it is running in the kernel mode and does not need to page fault when accessing restricted (unaccessible to the user process) memory?
Thanks!
The last answer is actually not true....
Changing to kernel mode doesn't go through 'Real mode'. Actually after finishing the boot process, the computer never goes back to real mode.
In normal x86 systems, changing to kernel mode involves calling 'sysenter' (after setting parameters in some registers), which causes jumping a predefined address (saved in the MISR register of the CPU), that was set when the computer booted, because it can be done only from kernel mode (it is a 'privileged' command).
So it basically involves executing a software command, that the hardware responds to, by the way it was set, when it was in kernel mode
This is kind of a broad question - each hardware platform is going to do things slightly differently, but I think the basic answer is that it's done w/ software that leverages hardware facilities for memory protection, etc.
When a user process wants to do a system call, it executes a special CPU instruction, and the CPU switches from virtual mode (for user processes, has page tables specific to processes) to real mode (for the kernel) and jumps to the OS syscall handler. The kernel can then do what it likes.
CPU support for this is required. The CPU keeps track of which mode it is in, where the page tables are located, jumping the instruction pointer, etc. It is triggered by the user software doing the syscall, and is dependent on the kernel providing support for whatever it is trying to do. As with all computation, it's always both hardware and software. I cannot be done solely with software however, because then there would be no way to prevent a process making a syscall from abusing the privelages it gains, e.g. it could start reading /etc/shadow.
Modern x86 computers have a special instruction just for doing system calls. Earlier x86 processors, and some current RISC ones, have an instruction to trigger an interrupt. Older architecures had other ways of switching control.