2025-01-22

了解到大家对于程序如何启动抱有极大的兴趣，尽管我们了解elf的组成原理，但是和程序的启动还是不太一致的，本文通过一个最简单的程序，来浅析一下一个程序的启动过程。便于大家更加深入的了解linux中一个程序的启动过程

一、最简单的C程序举例

我们在聊到C程序的时候，我相信所有人都或多或少了解过谭浩强的C语言书籍，我以第一节为例，如下：

其中的代码内容如下：


#include <stdio.h>
 
int main()
{
        printf("This is a C program.\n");
        return 0;
}

我们编译后运行如下：


# gcc first_c.c -g -o c && ./c
This is a C program.

二、探究程序的调用过程

2.1 谁调用的main

根据上面的代码，我们获取了第一个c程序，我们./c就能运行。但是这里还远远不够，我们压根还不知道这个程序是如何被运行的。所以我们需要开始调试它


# gdb ./c
Reading symbols from ./c...
(gdb)

我们先断点在main上然后运行


(gdb) b main
Breakpoint 1 at 0x40059c: file first_c.c, line 5.
(gdb) r
Starting program: /root/c/c
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main () at first_c.c:5
5 printf("This is a C program.\n");

此时我们查看一下x30寄存器，这是arm的lr寄存器，保存函数返回地址的


(gdb) x $x30
0x7ff7e3bd90 <__libc_start_main+232>: 0x940055c8

这里gdb友善的提供了提示__libc_start_main+232，我们可以发现是在__libc_start_main的sp指针的+232的位置，根据这个信息，我们拿到了main的上一个调用函数__libc_start_main

2.2 谁调用的__libc_start_main

此时我们将断点放在__libc_start_main上，重新运行，如下：


(gdb) b __libc_start_main
Breakpoint 2 at 0x7ff7e3bca8: file ../csu/libc-start.c, line 141.
(gdb) d 1
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /root/c/c
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Breakpoint 2, __libc_start_main (main=0x4004d8 <__wrap_main>, argc=1, argv=0x7ffffff1d8, init=0x4005b8 <__libc_csu_init>, fini=0x400638 <__libc_csu_fini>, rtld_fini=0x7ff7fdac90,
 stack_end=0x7ffffff1d0) at ../csu/libc-start.c:141
141 ../csu/libc-start.c: 没有那个文件或目录.

然后我们继续查看x30的值


(gdb) x $x30
0x4004d4 <_start+52>: 0x97ffffeb

这里可以发现是_start函数调用了__libc_start_main

2.3 谁调用了_start

我们继续跟踪，如下：


(gdb) b _start
Breakpoint 3 at 0x4004ac
(gdb) d 2
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /root/c/c
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Breakpoint 3, 0x00000000004004ac in _start ()

此时我们查看x30，发现了一个现象如下：


(gdb) x $x30
0x0: Cannot access memory at address 0x0

这里可以发现，_start没有满足调用约定了。

对于一个函数，如果不遵守调用约定了，那么我们可以知道，这个函数一定是第一个执行的函数，没有比它更早的函数调用。

我们可以通过readelf能够看到，如下：


# readelf -h c
ELF 头：
 Magic： 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
 类别: ELF64
 数据: 2 补码，小端序 (little endian)
 Version: 1 (current)
 OS/ABI: UNIX - System V
 ABI 版本: 0
 类型: EXEC (可执行文件)
 系统架构: AArch64
 版本: 0x1
 入口点地址： 0x4004ac
 程序头起点： 64 (bytes into file)
 Start of section headers: 7256 (bytes into file)
 标志： 0x0
 Size of this header: 64 (bytes)
 Size of program headers: 56 (bytes)
 Number of program headers: 9
 Size of section headers: 64 (bytes)
 Number of section headers: 29
 Section header string table index: 28
这里我们看到入口点地址是：0x4004ac

可以发现，我们的elf文件c程序，默认的ld的入口地址是0x4004ac，这个地址就是_start函数。这个_start函数最终会调用到main上。

三、程序启动后做了哪些事

3.1 _start函数做的事

根据上面我们知道，程序第一个函数入口是_start，我们可以对这个函数反汇编，如下：


(gdb) disassemble
Dump of assembler code for function _start:
 0x00000000004004a0 <+0>: mov x29, #0x0 // #0
 0x00000000004004a4 <+4>: mov x30, #0x0 // #0
 0x00000000004004a8 <+8>: mov x5, x0
=> 0x00000000004004ac <+12>: ldr x1, [sp]
 0x00000000004004b0 <+16>: add x2, sp, #0x8
 0x00000000004004b4 <+20>: mov x6, sp
 0x00000000004004b8 <+24>: adrp x0, 0x400000
 0x00000000004004bc <+28>: add x0, x0, #0x4d8
 0x00000000004004c0 <+32>: adrp x3, 0x400000
 0x00000000004004c4 <+36>: add x3, x3, #0x5b8
 0x00000000004004c8 <+40>: adrp x4, 0x400000
 0x00000000004004cc <+44>: add x4, x4, #0x638
 0x00000000004004d0 <+48>: bl 0x400460 <__libc_start_main@plt>
 0x00000000004004d4 <+52>: bl 0x400480 <abort@plt>
End of assembler dump.

可以发现，这里默认设置x29和x30为0，然后跳转到0x400460 <__libc_start_main@plt>上，我们随机跟到代码中，如下：

这里以glibc-2.31为例，glibc-2.31/sysdeps/aarch64/start.S这里_start函数如下


        .text
        .globl _start
        .type _start,#function
_start:
        /* Create an initial frame with 0 LR and FP */
        mov     x29, #0
        mov     x30, #0
 
        /* Setup rtld_fini in argument register */
        mov     x5, x0
 
        /* Load argc and a pointer to argv */
        ldr     PTR_REG (1), [sp, #0]
        add     x2, sp, #PTR_SIZE
 
        /* Setup stack limit in argument register */
        mov     x6, sp
 
#ifdef PIC
# ifdef SHARED
        adrp    x0, :got:main
        ldr     PTR_REG (0), [x0, #:got_lo12:main]
 
        adrp    x3, :got:__libc_csu_init
        ldr     PTR_REG (3), [x3, #:got_lo12:__libc_csu_init]
 
        adrp    x4, :got:__libc_csu_fini
        ldr     PTR_REG (4), [x4, #:got_lo12:__libc_csu_fini]
# else
        adrp    x0, __wrap_main
        add     x0, x0, :lo12:__wrap_main
        adrp    x3, __libc_csu_init
        add     x3, x3, :lo12:__libc_csu_init
        adrp    x4, __libc_csu_fini
        add     x4, x4, :lo12:__libc_csu_fini
# endif
#else
        /* Set up the other arguments in registers */
        MOVL (0, main)
        MOVL (3, __libc_csu_init)
        MOVL (4, __libc_csu_fini)
#endif
 
        /* __libc_start_main (main, argc, argv, init, fini, rtld_fini,
                              stack_end) */
 
        /* Let the libc call main and exit with its return code.  */
        bl      __libc_start_main
 
        /* should never get here....*/
        bl      abort
 
#if defined PIC && !defined SHARED
        /* When main is not defined in the executable but in a shared library
           then a wrapper is needed in crt1.o of the static-pie enabled libc,
           because crt1.o and rcrt1.o share code and the later must avoid the
           use of GOT relocations before __libc_start_main is called.  */
__wrap_main:
        b       main
#endif
 
        /* Define a symbol for the first piece of initialized data.  */
        .data
        .globl __data_start
__data_start:
        .long 0
        .weak data_start
        data_start = __data_start

这里很明显做了如下：

初始化LR和FP寄存器
将第一个参数rtld_fini给到x4
将参数加载到$sp
跳转到__libc_start_main

3.2 __libc_start_main函数做的事

我们可以翻阅glibc的代码，在csu/libc-start.c有函数的定义，如下：


#ifdef LIBC_START_MAIN
# ifdef LIBC_START_DISABLE_INLINE
#  define STATIC static
# else
#  define STATIC static inline __attribute__ ((always_inline))
# endif
#else
# define STATIC
# define LIBC_START_MAIN __libc_start_main
#endif
 
STATIC int
LIBC_START_MAIN (int (*main) (int, char **, char ** MAIN_AUXVEC_DECL),
                 int argc, char **argv,
#ifdef LIBC_START_MAIN_AUXVEC_ARG
                 ElfW(auxv_t) *auxvec,
#endif
                 __typeof (main) init,
                 void (*fini) (void),
                 void (*rtld_fini) (void), void *stack_end)
{
    ........
    exit (result);
}

这里我们留意参数可以知道需要调用如下：


 __typeof (main) init
void (*fini) (void)
void (*rtld_fini) (void), void *stack_end)
exit (result);

这里可以知道，__libc_start_main会调用.init，.fini ,mian和exit以及rtld_fini。

这里.init 和.fini 是用作代码运行时构造和析构的默认回调接口

这里rtld_fini 是ld的清理函数。接下来注意解析：

3.2.1 rtld_fini

此函数是x5寄存器


(gdb) x $x5
0x7ff7fdac90: 0xa9b87bfd

我们可以gdb内部设置断点如下：


(gdb) b *0x7ff7fdac90
Breakpoint 4 at 0x7ff7fdac90

然后继续运行


(gdb) c
Continuing.
This is a C program.
Breakpoint 4, 0x0000007ff7fdac90 in ?? () from /lib/ld-linux-aarch64.so.1

可以发现程序正常运行推出后，会断点停在/lib/ld-linux-aarch64.so.1内部。

但是我们进行反汇编却看不到代码调用，说明实际上是一个栈区地址而已，并不是完整的函数


(gdb) disassemble
No function contains program counter for selected frame.

3.2.2 init

我们知道.init函数是x3，所以可以根据如下汇编计算


 0x00000000004004c0 <+32>: adrp x3, 0x400000
 0x00000000004004c4 <+36>: add x3, x3, #0x5b8

我们加上断点后运行如下：


(gdb) b *0x4005b8
Breakpoint 5 at 0x4005b8
(gdb) c
Continuing.
Breakpoint 5, 0x00000000004005b8 in __libc_csu_init ()

可以发现函数是__libc_csu_init，我们反汇编


(gdb) disassemble
Dump of assembler code for function __libc_csu_init:
=> 0x00000000004005b8 <+0>: stp x29, x30, [sp, #-64]!
 0x00000000004005bc <+4>: mov x29, sp
 0x00000000004005c0 <+8>: stp x19, x20, [sp, #16]
 0x00000000004005c4 <+12>: adrp x20, 0x410000
 0x00000000004005c8 <+16>: add x20, x20, #0xdf0
 0x00000000004005cc <+20>: stp x21, x22, [sp, #32]
 0x00000000004005d0 <+24>: adrp x21, 0x410000
 0x00000000004005d4 <+28>: add x21, x21, #0xde8
 0x00000000004005d8 <+32>: sub x20, x20, x21
 0x00000000004005dc <+36>: mov w22, w0
 0x00000000004005e0 <+40>: stp x23, x24, [sp, #48]
 0x00000000004005e4 <+44>: mov x23, x1
 0x00000000004005e8 <+48>: mov x24, x2
 0x00000000004005ec <+52>: bl 0x400420 <_init>
 0x00000000004005f0 <+56>: cmp xzr, x20, asr #3
 0x00000000004005f4 <+60>: b.eq 0x400620 <__libc_csu_init+104> // b.none
 0x00000000004005f8 <+64>: asr x20, x20, #3
 0x00000000004005fc <+68>: mov x19, #0x0 // #0
 0x0000000000400600 <+72>: ldr x3, [x21, x19, lsl #3]
 0x0000000000400604 <+76>: mov x2, x24
 0x0000000000400608 <+80>: add x19, x19, #0x1
 0x000000000040060c <+84>: mov x1, x23
 0x0000000000400610 <+88>: mov w0, w22
 0x0000000000400614 <+92>: blr x3
 0x0000000000400618 <+96>: cmp x20, x19
 0x000000000040061c <+100>: b.ne 0x400600 <__libc_csu_init+72> // b.any
 0x0000000000400620 <+104>: ldp x19, x20, [sp, #16]
 0x0000000000400624 <+108>: ldp x21, x22, [sp, #32]
 0x0000000000400628 <+112>: ldp x23, x24, [sp, #48]
 0x000000000040062c <+116>: ldp x29, x30, [sp], #64
 0x0000000000400630 <+120>: ret
End of assembler dump.

这里可以看到会跳转到_init函数，我们继续断点


(gdb) b *_init
Breakpoint 6 at 0x7ff7e3bc08: file init-first.c, line 55.

运行如下：


(gdb) r
Starting program: /root/c/c
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Breakpoint 6, _init (argc=1, argv=0x7ffffff1d8, envp=0x7ffffff1e8) at init-first.c:55
55 init-first.c: 没有那个文件或目录.

此时进入_init函数内部


(gdb) c
Continuing.
Breakpoint 18, 0x0000000000400420 in _init ()
(gdb) disassemble
Dump of assembler code for function _init:
=> 0x0000000000400420 <+0>: stp x29, x30, [sp, #-16]!
 0x0000000000400424 <+4>: mov x29, sp
 0x0000000000400428 <+8>: bl 0x4004dc <call_weak_fn>
 0x000000000040042c <+12>: ldp x29, x30, [sp], #16
 0x0000000000400430 <+16>: ret
End of assembler dump.

可以发现，其就是运行的默认的init回调，我们可以objdump查看如下：


objdump -d c.o
Disassembly of section .init:
0000000000400420 <_init>:
 400420: a9bf7bfd stp x29, x30, [sp, #-16]!
 400424: 910003fd mov x29, sp
 400428: 9400002d bl 4004dc <call_weak_fn>
 40042c: a8c17bfd ldp x29, x30, [sp], #16
 400430: d65f03c0 ret

3.2.3 fini

我们知道fini是保存在x4，所以如下：


 0x00000000004004c8 <+40>: adrp x4, 0x400000
 0x00000000004004cc <+44>: add x4, x4, #0x638

此时我们计算出函数如下：


(gdb) x 0x400638
0x400638 <__libc_csu_fini>: 0xd65f03c0

我们直接反汇编如下：


(gdb) disassemble __libc_csu_fini
Dump of assembler code for function __libc_csu_fini:
 0x0000000000400638 <+0>: ret
End of assembler dump.

可以看到此函数直接是一个返回

我们通过objdump如下：


Disassembly of section .fini:
000000000040063c <_fini>:
 40063c: a9bf7bfd stp x29, x30, [sp, #-16]!
 400640: 910003fd mov x29, sp
 400644: a8c17bfd ldp x29, x30, [sp], #16
 400648: d65f03c0 ret

可以发现一致。

3.2.4 main

我们知道main函数是__libc_start_main中直接调用的我们反汇编后，注意这个语句


 0x0000007ff7e3bd88 <+224>: ldr x3, [sp, #104]
 0x0000007ff7e3bd8c <+228>: blr x3

代码运行如下：


(gdb) b *0x0000007ff7e3bd8c
Breakpoint 31 at 0x7ff7e3bd8c: file ../csu/libc-start.c, line 308.
(gdb) c
Continuing.
Breakpoint 31, 0x0000007ff7e3bd8c in __libc_start_main (main=0x4004d8 <__wrap_main>, argc=1, argv=0x7ffffff1d8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
 stack_end=<optimized out>) at ../csu/libc-start.c:308
308 in ../csu/libc-start.c

可以发现其跳转了x3，然后以0x0000007ff7e3bd90作为lr，我们计算sp+104的值，如下：


(gdb) x $sp+104
0x7ffffff0e8: 0x004004d8

可以发现blr会跳转到0x004004d8，我们解释这个地址


(gdb) x 0x004004d8
0x4004d8 <__wrap_main>: 0x1400002f

然后打上断点


(gdb) b *0x004004d8
Breakpoint 1 at 0x4004d8
(gdb) r
Breakpoint 1, 0x00000000004004d8 in __wrap_main ()

然后反汇编


(gdb) disassemble
Dump of assembler code for function __wrap_main:
=> 0x00000000004004d8 <+0>: b 0x400594 <main>
End of assembler dump.

这里会直接跳转到mian，我们继续运行


(gdb) r
Breakpoint 3, 0x0000000000400594 in main ()

然后再反汇编main函数，如下


(gdb) disassemble
Dump of assembler code for function main:
=> 0x0000000000400594 <+0>: stp x29, x30, [sp, #-16]!
 0x0000000000400598 <+4>: mov x29, sp
 0x000000000040059c <+8>: adrp x0, 0x400000
 0x00000000004005a0 <+12>: add x0, x0, #0x668
 0x00000000004005a4 <+16>: bl 0x400490 <puts@plt>
 0x00000000004005a8 <+20>: mov w0, #0x0 // #0
 0x00000000004005ac <+24>: ldp x29, x30, [sp], #16
 0x00000000004005b0 <+28>: ret
End of assembler dump.

然后我们将c程序直接objdump，如下


0000000000400594 <main>:
 400594: a9bf7bfd stp x29, x30, [sp, #-16]!
 400598: 910003fd mov x29, sp
 40059c: 90000000 adrp x0, 400000 <_init-0x420>
 4005a0: 9119a000 add x0, x0, #0x668
 4005a4: 97ffffbb bl 400490 <puts@plt>
 4005a8: 52800000 mov w0, #0x0 // #0
 4005ac: a8c17bfd ldp x29, x30, [sp], #16
 4005b0: d65f03c0 ret
 4005b4: d503201f nop

可以发现是完全一样的。这里我们正常跟踪到了main函数

四、总结

通过此程序，我们可以知道一个程序的启动过程，从elf作为开始，ld加载了entrypoint后，是通过启动了_start的text label后，然后再逐渐调用到main函数的。

相当于从程序的最开头，进行了简单的了解了一个程序的启动过程。

2025-01-22

随着人员逐渐多，并且处理的事情越来越多，导致服务经常出现io占用高，cpu占用高，内存占用高三种情况。本文通过crontab的方式定时进行查询和设置，来实现定期对服务的资源限制，从而确保服务不会突然卡死的情况出现

一、问题描述

在一个服务器上，多人进行编辑，编译时，通常情况下，编译的时候会把cpu，memery，io占满，三者只要有其一出现满负载，则打开的vim程序会出现，卡顿，杀掉，卡死。

对于cpu满负载而言，通常是vim程序得不到该有的调度，主要原因是vim的PRI和NI是80和0，而常规程序的优先级也是80和0，此时vim程序卡顿

对于memory满负载而言，通常是系统内存不足时，不得已情况下，通过out_of_memory函数选择一个oom score最低的程序进行杀掉，vim通常会是得分较低的进程。主要原因是vim的score是0，而常规程序的score也是0。此时vim可能被杀死

对于io负载而言，通常是io状态是陷入并且阻塞的，如果io负载高，则短时间内所有进程无法都被block住，无法被调度，此时vim出现卡死

所以，为了解决编译和编辑时的服务器负载问题，需要通过一个脚本来实现对cpu，io，memory的控制，从而使得编辑程序vim得到该有的调度，而编译程序也能正常运行。

二、工具

为了实现上述的功能，需要借助cpulimit，cgroup， ionice三个工具

2.1 cpulimit

cpulimit是一个限制cpu使用率的工具，我们可以通过-p参数指定进程的pid，通过-l参数设置使用率百分比，从而限制进程使用率。介绍如下：


-p, --pid=N        pid of the process
-l, --limit=N percentage of cpu allowed from 1 up.
 Usually 1 - 4800, but can be higher
 on multi-core CPUs (mandatory)

所以，对于cpu满负载的情况，通过cpulimit限制当前最高使用率的进程，从而对突出的程序进行有效控制。让系统有办法调度到其他的程序

2.2 cgroup

cgroup是用作资源管理的内核框架，它作为文件系统存放于linux系统中，我们可以通过cgroup设置某个进程的内存使用情况，具体如下：


/sys/fs/cgroup/memory/kylin_limit/memory.limit_in_bytes

所以，对于io满负载的情况，通过cgroups设置memory.limit_in_bytes来限制高占用进程的内存占用率，从而对高内存占用程序进行有效控制，让系统其他进程能够正常申请到内存。

不过值得注意的是，对于进程的内存使用限制可能导致进程运行失败，所以通常我们在服务器上设置单个进程使用不超过总内存的10%，通常服务器的总内存为64G，则单个进程使用内存不应该超过6.4G。通常来说，单个进程的内存使用量如果超过6.4G已经存在异常。所以没有问题。

但是如果是小内存的设备，通过memory.limit_in_bytes来限制指定进程的内存使用率并不可取，假设在内存4G的机器上，我们限制进程的内存使用率仍是10%，则单个进程使用内存不超过400M，又由于很多程序可能使用内存大于400M（属于正常现象），这会导致进程的oom，所以我们应该做的是通过增大swap来将内存压力转换为io压力。

通过swap来转换内存压力为io压力的方法如下：


mkswap /dev/sda1
swapon /dev/sda1

如果我们不是真实的设备，可以将swap开启在img文件上，如下


dd if=/dev/zero of=/tmp/swap bs=512 count=20480000
mkswap /tmp/swap
swapon /tmp/swap

2.3 ionice

ionice是用作调整进程的io优先级的命令，通过ionice命令，可以设置指定进程作为实时的io调度，从而加速系统对某些进程的io行为。主要如下：


ionice -c 2 -n 7 -p ${pid}  # 设置pid进程的调度为尽力，并优先级设置为7
ionice -c 1 -p ${pid}                   # 设置pid进程的调度为实时

这里-c可以设置优先级，-n设置优先级，-p设置pid，介绍如下


用法：
 ionice [选项] -p <pid>...
 ionice [选项] -P <pgid>...
 ionice [选项] -u <uid>...
 ionice [选项] <命令>
设置或更改进程的 IO 调度类别和优先级。
选项：
 -c, --class <类别> 调度类别的名称或数值
 0: 无, 1: 实时, 2: 尽力, 3: 空闲
 -n, --classdata <数字> 指定调度类别的优先级(0..7)，只针对
 “实时”和“尽力”类别
 -p, --pid <pid>... 对这些已运行的进程操作
 -P, --pgid <pgrp>... 对这些组中已运行的进程操作
 -t, --ignore 忽略失败
 -u, --uid <uid>... 对属于这些用户的已运行进程操作
-h, --help 显示此帮助
 -V, --version 显示版本

所以，对于满io负载的情况，可以通过ionice命令对io刷盘进程如flush进行实时调度，对io使用率高的程序使用优先级最低为7的尽力调度，从而可以使得vim的写操作可以正常的flush，并且可能从普通进程上抢到io的调度。

三、具体操作

根据上述的介绍，我们可以通过三个工具完成对应的功能，现在介绍如何实施

3.1 限制最高cpu占用率的进程

为了限制高占用的进程，我们需要在系统长时间占用高的情况下找到占用高的进程，因为某些短时进程会占用很高（例如top后一直按enter来一直刷新），这些我们应该忽略。所以需要先获取平均负载，如下：


load=`cat /proc/loadavg | cut -f1 -d' '`

上面可以获取1分钟内的平均负载，如果平均负载大于100，则认为1分钟内，进程占用高，可能在后台执行编译动作


declare -i loadavg=`echo "${load} * 100" | bc | awk -F. '{print $1}'`
 if (( ${loadavg} >= ${LOAD_CPU_THRESHOLD} ))

此时我们可以通过ps命令找出最高占用的那个进程


high_exe=`ps -eo user,pid,pcpu,pmem,args --sort=-pcpu  |sed -n 2p | xargs`

根据ps的结果，可以获取进程的pid和name，如下


pid=`echo ${high_exe} | awk '{print $2}'`
pid_name=`echo ${high_exe} | awk '{print $5}'`

根据pid值，我们可以知道是谁连接的ssh客户端，找到ip如下


who=`cat /proc/${pid}/environ  | tr '\0' '\n' | grep SSH_CONNECTION | cut -d= -f2 | awk '{print $1":" $2}'`

同时通过cpulimit设置此进程的占用率不超过100%


cpulimit -p ${pid} -l 100 > /dev/null 2>&1 &

至此，如果crontab每一10分钟轮询一次，系统将查询最近1分钟内是否负载高，如果负载高，则找出当前占用最高的进程，设置其占用率不超过100%

3.2 限制程序使用最高内存

为了限制高内存占用的程序，我们需要在系统剩余内存不足时找出内存占用最高的进程，然后将其设置为总内存的10%，从而让其他程序有可能申请到内存。

基于此思路，我们需要判断当前内存剩余量，如下


declare -i free=`free -m | sed -n 2p | xargs | cut -f7 -d' '`

上面可以获取到剩余内存，当然，同样通过free命令，我们也可以获取到总共内存，我们需要判断一下剩余内存是否小于总共内存的比例即可，具体比例可以自行设置，建议10%

如果剩余内存小于总共内存的10%，我们需要找到高内存的进程，如下


high_mem_exe=`ps -eo pid,pcpu,pmem,args --sort=-pmem |sed -n 2p | xargs`

同样的，通过上面可以知道高内存占用进程的pid和name，以及谁ssh登录的，如下


pid=`echo ${high_mem_exe} | awk '{print $1}'`
pid_name=`echo ${high_mem_exe} | awk '{print $4}'`
who=`cat /proc/${pid}/environ | tr '\0' '\n' | grep SSH_CONNECTION | cut -d= -f2 | awk '{print $1":" $2}'`

我们知道pid之后，便可以通过cgroup设置进程的最大内存使用量


[ ! -d /sys/fs/cgroup/memory/kylin_limit ] && mkdir /sys/fs/cgroup/memory/kylin_limit
 echo ${pid} > /sys/fs/cgroup/memory/kylin_limit/tasks
 echo $(expr $total \/ 10 \* 1024) > /sys/fs/cgroup/memory/kylin_limit/memory.limit_in_bytes

这里total是总内存大小，可以通过free命令获取，我们可以设置cgroup下的kylin_limit组的内存使用率不能超过总内存的10%

至此，如果crontab每10分钟轮询一次，系统将查询当前剩余内存，如果剩余内存不足总内存的某个比例，则可以通过cgroups设置最高内存占用率的进程其最大内存使用量不超过总内存的10%

3.3 限制程序io的政策

程序的io都是block的，因为谁也不知道陷入io处理需要多久时间，所以通常如果io存在瓶颈，大部分情况下都是cpu在等io，从而导致vim卡死的情况

通常来说，对于磁盘来说，刷盘是由内核线程[kworker/uxx:x+flush-x:xxx]实现，如果是文件系统write，也可能是mount进程中实现。本文只讨论常出现的flush

首先我们需要找到io占用率高的进程，如下


io_message=`iotop -n 1 -b -o | grep -v WRITE | xargs`

从上述的信息获取到io占用率和pid以及name


 percent=`echo ${io_message} | awk '{print $10}'`
 name=`echo ${io_message} | awk '{print $12}'`
 pid=`echo ${io_message} | awk '{print $1}'`

如果进程是flush，则当前io压力最大的是刷盘线程


if [[ ${pid_name} =~ "kworker" ]]
 then
 if [[ ${pid_name} =~ "flush" ]]
 then

此时我们可以通过ionice命令设置flush线程为实时io调度，如下


ionice -c 1 -p ${pid}

如果io占用率超过99%了，则说明有io占用很高的进程，如下


echo ${percent} | egrep "^99.**" > /dev/null

此时我们可以将此进程设置为尽力，优先级放最低为7，此时程序能够正常跑即可，相当于以时间换内存空间


ionice -c 2 -n 7 -p ${pid}

至此，如果crontab每10分钟轮询一次，系统将找到io占用高的进程，先判断是否为flush，如果是flush则调整为实时，如果不是，则是其他进程io占用高，此时将其他进程调整为尽力，优先级最低为7

当然，如果io密集型的任务多，我们可以让其1分钟运行一次，在不改变crontab的前提下，可以做个循环如下：


for((i=0;i<10;i++)); do
 io_policy
 ret=$?
 if [ "${ret}"x == "1" ]
 then
 sleep 60
 fi
done

3.4 crontab定时

对于上述的策略，我们可以10分钟运行一次，首先将其脚本命名为kylin-server-status.sh，通过crontab -e编写如下：


*/10 * * * * /usr/local/bin/kylin-server-status.sh

至此，服务器会每10分钟轮询一次

阅读全文

如何防止系统通过ld preload来劫持核心库的调用

编辑

2025-01-22

工作知识

对于系统，我们可以针对一个库的函数调用进行ld preload来hack，这样我们只要知道核心库的函数名和相关信息，就能通过hook的方式来伪造系统核心信息

一、跟踪函数

为了跟踪函数的调用，可以通过ltrace，如下：


ltrace -p `pidof activation-daemon`

这样我们可以找到关键函数：license_should_escape

二、创建hook

我们知道了关键函数，则可以编写一个简单的c如下：


#include <syslog.h>
 
int license_should_escape()
{
        syslog(LOG_ERR, "%s kylin hacked\n", __func__);
        return 1;
}

此时我们通过gcc可以将其编译成动态库so，如下：


gcc kylin_hack.c -o libkylin_hack.so --shared

此时我们生成了库 libkylin_hack.so 。接下来需要进行ld preload如下：


echo /usr/lib/aarch64-linux-gnu/libkylin_hack.so >> /etc/ld.so.preload

进行如上的命令之后，我们可以直接重启

三、验证

此时我们发送dbus，可以看到激活已经被破解，如下：


root@kylin:~# dbus-send --system --print-reply --dest=org.freedesktop.activation /org/freedesktop/activation org.freedesktop.activation.interface.date
method return time=1723801648.866529 sender=:1.124 -> destination=:1.125 serial=9 reply_serial=2
   string "2099-12-31"
   int32 0

我们查看设置界面的信息，可以看到已激活

阅读全文

如何防止系统通过dbus hack来劫持核心信息

编辑

2025-01-22

工作知识

我们知道linux都是基于dbus来进行通信的，dbus分为server和client，也就是说，如果应用程序作为client发送消息，我们只需要劫持这条dbus即可将错误的dbus信息返回给client，这样就能修改核心信息，

一、找出dbus的调用

对于我们感兴趣的调用，我们可以通过监听的方式找到调用，如下：


dbus-monitor --system "destination=org.freedesktop.activation"

此时我们可以抓到某个method call如下：


method call time=1723771942.107726 sender=:1.4302 -> destination=org.freedesktop.activation serial=26 path=/org/freedesktop/activation; interface=org.freedesktop.activation.interface; member=date

二、复刻method

我们编写pro如activation-daemon.pro文件如下：


QT += dbus
 
TARGET = activation-daemon
 
SOURCES += activation-daemon.cpp
HEADERS += activation-daemon.h
然后编写dbus interface class为activation-daemon.h如下：

#include <QCoreApplication>
#include <QtDBus>
 
// https://doc.qt.io/qt-5/qdbusabstractadaptor.html
class ActivationDaemon : public QDBusAbstractAdaptor {
    Q_OBJECT
    Q_CLASSINFO("D-Bus Interface", "org.freedesktop.activation.interface")
 
public:
    ActivationDaemon(QObject *parent = nullptr) : QDBusAbstractAdaptor(parent) {}
 
public slots:
    QString date() {
        return "kylin hack";
    }
};

最后实施这个类activation-daemon.cpp 如下：


#include "activation-daemon.h"
 
int main(int argc, char *argv[]) {
    QObject object;
    QCoreApplication app(argc, argv);
    QDBusConnection connection = QDBusConnection::systemBus();
 
    ActivationDaemon ac(&object);
    connection.registerObject("/org/freedesktop/activation", &object);
    connection.registerService("org.freedesktop.activation");
 
    qDebug() << "Kylin Hacking...";
    return app.exec();
}

编译后生成如下：


qmake && make

此时我们生成二进制为activation-daemon，将其替换到系统如下：


mv activation-daemon /usr/sbin/activation-daemon

三、验证

此时我们通过dbus-send验证这条dbus即可，如下


root@kylin:~# dbus-send --system --print-reply --dest=org.freedesktop.activation /org/freedesktop/activation org.freedesktop.activation.interface.date
method return time=1723772343.990579 sender=:1.4205 -> destination=:1.4309 serial=115 reply_serial=2
 string "kylin hack"

可以看到这条dbus的响应已经变成我们自己写的dbus服务了。大功告成

四、如何防止

针对上述这种手段，我们可以知道，基于篡改二进制导致的劫持可以导致dbus的响应被篡改，为了保障核心相关二进制不被篡改，我们可以通过加密解密的方式完成，详情请查看如下：

激活防破解方案-使用非对称加密和数字签名

阅读全文

在Peony中为系统新增系统盘和应用盘(C/D盘)

编辑

2025-01-22

工作知识

根据之前的讨论，我们CD盘的短期目标是基于overlayfs来实现系统数据和应用数据的隔离（形式上）。长期目标是将应用数据和系统数据完全隔离开来。本文主要讨论peony上显示应用盘的基本改造流程

一、简述overlayfs

根据上图我们可以知道，对于overlayfs，区分lower和upper两层。我们可以将lower设置为sysroot，将upper设置为appfs。这样，我们发行操作系统的时候，默认情况下lower是发行的原始操作系统，而upper是除了原始发行的操作系统之外的所有改动。

我们将发行操作系统之外的所有改动都认为是应用的改动，所以直接认为upper就是应用盘。

二、peony的改造

对于peony，我们需要修改sidebar上的显示，显示系统盘和应用盘。效果如下：

这里我们文件系统盘是默认的overlay，如下：


kylinoverlay     19G  8.3G  9.5G   47% /

这里应用盘是appfs目录，如下：


/dev/mmcblk0p5   19G  8.3G  9.5G   47% /appfs

这里系统盘是sysroot目录，如下：


root@kylin:~# ls /sysroot/
bin boot data dev etc home lib media mnt opt proc root run sbin srv sys tmp usr var work

对于代码，主要如下：

2.1 应用盘新增


From 79f4bfabfde8d8d2deaaf2908933c1be36a1d198 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=94=90=E5=B3=B0?= <tangfeng@kylinos.cn>
Date: Wed, 15 Jan 2025 17:36:13 +0800
Subject: [PATCH] changelog: 3.14.4.5-0k3.0tablet18rk3.egf1.3
 
---
 .../model/side-bar-file-system-item.cpp       | 22 ++++++++++++++-----
 translations/libpeony-qt/libpeony-qt_zh_CN.ts |  4 ++++
 3 files changed, 31 insertions(+), 5 deletions(-)
 
diff --git a/libpeony-qt/model/side-bar-file-system-item.cpp b/libpeony-qt/model/side-bar-file-system-item.cpp
index 6268ddfb6..0b6664966 100644
--- a/libpeony-qt/model/side-bar-file-system-item.cpp
+++ b/libpeony-qt/model/side-bar-file-system-item.cpp
@@ -169,6 +169,11 @@ void SideBarFileSystemItem::initDirInfo(const QString &uri)
        m_displayName = tr("Data");
        m_iconName = "drive-harddisk";
    }
+
+   if (uri == "file:///appfs") {
+       m_displayName = tr("Appfs");
+       m_iconName = "drive-harddisk";
+   }
 }
  
 void SideBarFileSystemItem::initComputerInfo()
@@ -259,6 +264,7 @@ void SideBarFileSystemItem::initVolumeInfo(const Experimental_Peony::Volume &vol
     }else{
         m_uri = "file://" + m_uri;
     }
+
     /* 文件系统项特殊处理 */
     if("file:///" == m_uri){
         m_unmountable = m_mountable = m_ejectable = m_stopable = false;
@@ -270,11 +276,11 @@ void SideBarFileSystemItem::initVolumeInfo(const Experimental_Peony::Volume &vol
         m_mounted = true;
         m_displayName = QObject::tr("Data");
         m_iconName = "drive-harddisk";
-    }
-
-    /* 隐藏指定的挂载点 */
-    if(m_device == getDeviceMount("/media/root-rw") || m_device == getDeviceMount("/media/root-ro")){
-   m_hidden = true;
+    }else if("file:///appfs" == m_uri){
+        m_unmountable = m_mountable = m_ejectable = m_stopable = false;
+        m_mounted = true;
+        m_displayName = QObject::tr("Appfs");
+        m_iconName = "drive-harddisk";
     }
  
     // kydrive特殊处理
@@ -612,6 +618,12 @@ void SideBarFileSystemItem::findChildren()
             m_model->endInsertRows();
         }
  
+        if (FileUtils::isFileDirectory("file:///appfs")) {
+            m_model->beginInsertRows(this->firstColumnIndex(), m_children->count(), m_children->count());
+            SideBarFileSystemItem* item = new SideBarFileSystemItem("file:///appfs", nullptr, this, m_model);
+            m_children->append(item);
+            m_model->endInsertRows();
+        }
     }else{
         //对挂载点进行已存在文件的枚举操作
         QString enumdir = m_uri;
diff --git a/translations/libpeony-qt/libpeony-qt_zh_CN.ts b/translations/libpeony-qt/libpeony-qt_zh_CN.ts
index d8de5ad92..68bdf8f4b 100644
--- a/translations/libpeony-qt/libpeony-qt_zh_CN.ts
+++ b/translations/libpeony-qt/libpeony-qt_zh_CN.ts
@@ -3792,6 +3792,10 @@ Do you want to delete the link file?</source>
         <source>Data</source>
         <translation>数据盘</translation>
     </message>
+    <message>
+        <source>Appfs</source>
+        <translation>应用盘</translation>
+    </message>
 </context>
 <context>
     <name>Peony::SideBarMenu</name>
--
2.25.1

这里完成了应用盘的新增工作，识别/appfs的目录，将其作为单独的硬盘显示在peony的侧边栏

2.2 系统盘新增


diff --git a/libpeony-qt/model/side-bar-file-system-item.cpp b/libpeony-qt/model/side-bar-file-system-item.cpp
index 0b6664966..f38d678e7 100644
--- a/libpeony-qt/model/side-bar-file-system-item.cpp
+++ b/libpeony-qt/model/side-bar-file-system-item.cpp
@@ -174,6 +174,11 @@ void SideBarFileSystemItem::initDirInfo(const QString &uri)
        m_displayName = tr("Appfs");
        m_iconName = "drive-harddisk";
    }
+
+   if (uri == "file:///sysroot") {
+       m_displayName = tr("Sysroot");
+       m_iconName = "drive-harddisk";
+   }
 }
  
 void SideBarFileSystemItem::initComputerInfo()
@@ -281,6 +286,11 @@ void SideBarFileSystemItem::initVolumeInfo(const Experimental_Peony::Volume &vol
         m_mounted = true;
         m_displayName = QObject::tr("Appfs");
         m_iconName = "drive-harddisk";
+    }else if("file:///sysroot" == m_uri){
+        m_unmountable = m_mountable = m_ejectable = m_stopable = false;
+        m_mounted = true;
+        m_displayName = QObject::tr("Sysroot");
+        m_iconName = "drive-harddisk";
     }
  
     // kydrive特殊处理
@@ -618,6 +628,13 @@ void SideBarFileSystemItem::findChildren()
             m_model->endInsertRows();
         }
  
+        if (FileUtils::isFileDirectory("file:///sysroot")) {
+            m_model->beginInsertRows(this->firstColumnIndex(), m_children->count(), m_children->count());
+            SideBarFileSystemItem* item = new SideBarFileSystemItem("file:///sysroot", nullptr, this, m_model);
+            m_children->append(item);
+            m_model->endInsertRows();
+        }
+
         if (FileUtils::isFileDirectory("file:///appfs")) {
             m_model->beginInsertRows(this->firstColumnIndex(), m_children->count(), m_children->count());
             SideBarFileSystemItem* item = new SideBarFileSystemItem("file:///appfs", nullptr, this, m_model);
diff --git a/translations/libpeony-qt/libpeony-qt_zh_CN.ts b/translations/libpeony-qt/libpeony-qt_zh_CN.ts
index 68bdf8f4b..3c0814fc8 100644
--- a/translations/libpeony-qt/libpeony-qt_zh_CN.ts
+++ b/translations/libpeony-qt/libpeony-qt_zh_CN.ts
@@ -3792,6 +3792,10 @@ Do you want to delete the link file?</source>
         <source>Data</source>
         <translation>数据盘</translation>
     </message>
+    <message>
+        <source>Sysroot</source>
+        <translation>系统盘</translation>
+    </message>
     <message>
         <source>Appfs</source>
         <translation>应用盘</translation>

这里新增了系统盘的显示，指向了sysroot目录。

三、总结

通过上述操作，我们可以在文件管理器中正常的导航到/appfs和/sysroot两个目录。这两个目录实际上就是overlay的lower和upper。至此，在当前阶段，系统的文件存放在sysroot，而应用的文件存放在appfs。我们完成了应用程序和操作系统的分离。

阅读全文