JOS LAB3 Partial User program analysis

JOS LAB3 Partial User program analysis

In Lab 4 's branch, there will be a variety of fun user programs. As follows:

I think it is necessary to make a brief analysis of it one by one. Top-down understanding of the OS mechanism

Analyze the user program order arbitrarily, not according to the difficulty sort

BADSEGMENT.C:

The only line here is that the embedded assembly tries to assign the 0x28 number to the data segment register DS

See here Global describe table-GDT,

0x28 is the choice of the TSS0 segment for CPU0.

It is illegal to move the TSS0 selector into the DS data register, which will trigger the exception protection T_gpflt

The modification of various segment registers satisfies the conditions of CPL and DPL relations. System calls must be triggered to enter the kernel state to be modified.

The current user state of the segment CPL is 3, then you can only modify the DPL is 3 of the permission segment, can not be higher than this permission, we are here to try to modify the original test badsegment.c

As follows: I should be the 0x20, the user's data segment descriptor.

Operating conditions, as follows:

There's no panic .... Yes. Go on

BREAKPOINT.C:

int $ $ Attempts to invoke interrupt 3rd.

Below is the trap frame that was hung off after running

BUGGYHELLO.C:

Here is an attempt to print a character through the system call to the address 0x1. After the system has been started, the contents below 0x200000 are empty memory.

It's too obvious here, to go to a pointer without a map, to be hung up by the assertions in the Mem_check that we lab4 written before.

BUGGYHELLO2.C:

Here the attempt is made to output a string at the address of the Hello tag, from which the author's intention is to destroy the process directly, but here, because we wrote the assertion in Sys_cputs, it is here to comment out the assertion that you can see the expected output

The output is as follows:

DIVEZERO.C:

One-step debugging follow-up to see:

is to trigger divide_error when the command ldiv.

EVILHELLO.C:

Wicked Hello, what a wicked law.

This attempts to use the system call to output the 100 characters from the 0xf010000c address.

We know that the virtual address 0xf010000c corresponds to the physical address is 0x10000c, this is the first time the kernel's entry address

Because the part of the error check was done before. The comment section needs to be commented out, otherwise there is no way to access the kernel high address.

You need to comment out all two detections here, because, for the user, not only the kernel high address is not pte_u and there is no pte_p,

The output will find the beginning or try to explain the address of some data, interpreted as characters, but are garbled. Thereafter the process is obligated to release.

FAULTREAD.C:

Here we beginner C language, when the pointer did not learn, or vigilance is not high when the non-empty check, it is possible to null pointer dereference. This is illegal.

The above test program will directly trigger the exception and then hang the system off. Here we are not in Lab 4, and there is no exception handling mechanism for user-space-triggered page fault. Follow-up to Lab 4 I'll give you a special analysis of the example here.

FAULTREADKERNEL.C:

The following is an example of an attempt to read a kernel area data that is not allowed to be accessed by the user program.

Can be compared with the above faultread.c, above is the visit 0x00 this address is not mapped, so the problem is really pte_p

The kernel address here is pte_p, but this is not allowed to be accessed by the user.　Protection. With page fault, there is a slight difference between them.

The analysis of faultwrite.c faultwritekernel.c and the above FAULTREAD.C faultreadkernel.c the same. Don't dwell on it.

HELLO.C:

Deep weakness, feel nothing to say, here is the access thisenv this global variable, the struct env that points to the current process

Print thisenv->env_id. Equivalent to the output process PID inside Linux:)

Worth to say is the output information here, first from the kernel state through the trap into the user state print output Hello, world

Then, because the thisenv points to the structure is from the beginning of the allocation of memory Envs point to a series of structures stored in the kernel address, so here need to access the kernel, will trigger trap, enter the kernel state, access and print the thisenv pointer to the structure of the body members env_id

TESTBSS.C:

We know that uninitialized global variables are put into the BSS segment of the executable program.

The Bigarray here is an example. It allocates a lot of space. This is the global variable that is initialized

The program tests the validation first, and the globally uninitialized variable has the default initial value of 0.

And then assign values. Detection is no problem. The first three for loops are normal

Attempting to write data outside the requested array range triggers page fault. Therefore we do not see the panic output information in the back. (This is also based on LAB3 analysis, because there is no user-state page fault handler, if it is Lab 4, the system will not hang like this, but if the normal processing mechanism should not let the program continue to run:)

Lab 3 analysis is over ~

JOS LAB3 Partial User program analysis