💠 Caelum

fread源码解析

Caelum — Thu, 09 Apr 2026 00:00:00 GMT

前置知识

在分析fread函数时，应该先明确一下输入缓冲区是怎么来的。

首先fread函数会先将数据读到输入缓冲区中，然后从输入缓冲区中执行memcpy函数，拷贝一定字节的数据到我们指定的内存地址上。而这个输入缓冲区是从哪到哪呢？由两个指针分别声明了这片区域的开始和结束，他们分别叫做**_IO_read_base和_IO_read_end，他们之间的区域就是输入缓冲区**。这样看起来似乎还需要一个输出缓冲区，难道需要malloc申请两个堆块来分别表示输入缓冲区和输出缓冲区么？非也，其实malloc函数自始至终只申请了一个堆块，这个堆块的区域也叫做reserve area，而_IO_buf_base和_IO_buf_end两个指针则分别声明了这个reserve area的始末。然后将 _IO_read_ptr; _IO_read_end; _IO_read_base; _IO_write_base; _IO_write_ptr; _IO_write_end;这六个指针全部初始化为了_IO_buf_base的值，现在的输入缓冲区和输出缓冲区还不存在(因为现在 _IO_read_end和 _IO_read_base的值相同)，以输入缓冲区为例，读入数据时是执行了系统调用read，而此时的数据是在reserve area中，紧接着 _IO_read_end就会加上刚刚读入的数据的个数，那么此时 _IO_read_end和 _IO_read_base的值变的不同了。而现在这二者之间的区域就成为输入缓冲区

再提一下_IO_FILE结构体中的一些指针(如下)

char* _IO_read_ptr;	/* Current read pointer */   
char* _IO_read_end;	/* End of get area. */  
char* _IO_read_base;	/* Start of putback+get area. */  
char* _IO_write_base;	/* Start of put area. */  
char* _IO_write_ptr;	/* Current put pointer. */  
char* _IO_write_end;	/* End of put area. */  
char* _IO_buf_base;	/* Start of reserve area. */  
char* _IO_buf_end;	/* End of reserve area. */

其中_IO_buf_base 和 _IO_buf_end两个指针的作用分别是标明reserve area的始末。_IO_read_base 和 _IO_read_end两个指针的作用分别是标明输入缓冲区的始末(write那两个指针同理)，现在假设有一个30字节的flag文件，然后我连续执行两次fread函数，每次从文件中只读10字节，那么第二次执行fread函数是从哪开始读呢，很明显并不是文件的开始来读取了，而是接着上回fread函数读到的位置，继续读10字节数据。但我们怎么去记录上回fread函数读到哪了呢，这就需要用到**_IO_read_ptr指针了，它是来记录下一次数据应该从输入缓冲区的哪里开始读了。也就是说_IO_read_base 和 _IO_read_ptr 之间的区域是已经使用了的输入缓冲区，而 _IO_read_ptr 和 _IO_read_end之间的区域是输入缓冲区的剩余部分(也就是还未使用部分)**。

通过上面这两段文字，应该可以对刚学习IO的师傅对_IO_FILE结构体中表示缓冲区位置的指针有一些了解了。

同时这次还要提到vtable，它是_IO_FILE_plus结构体中的一个字段，也是一个虚表指针。它指向了_IO_jump_t结构体

struct _IO_FILE_plus  
{  
  _IO_FILE file;  
  const struct _IO_jump_t *vtable;  
};

对于_IO_jump_t结构体，我目前的理解它就是一个跳转表，这里放的都是函数指针。通过不同的偏移获取不同的函数指针，然后将其调用。

struct _IO_jump_t  
{  
    JUMP_FIELD(size_t, __dummy);  
    JUMP_FIELD(size_t, __dummy2);  
    JUMP_FIELD(_IO_finish_t, __finish);  
    JUMP_FIELD(_IO_overflow_t, __overflow);  
    JUMP_FIELD(_IO_underflow_t, __underflow);  
    JUMP_FIELD(_IO_underflow_t, __uflow);  
    JUMP_FIELD(_IO_pbackfail_t, __pbackfail);  
    /* showmany */  
    JUMP_FIELD(_IO_xsputn_t, __xsputn);  
    JUMP_FIELD(_IO_xsgetn_t, __xsgetn);  
    JUMP_FIELD(_IO_seekoff_t, __seekoff);  
    JUMP_FIELD(_IO_seekpos_t, __seekpos);  
    JUMP_FIELD(_IO_setbuf_t, __setbuf);  
    JUMP_FIELD(_IO_sync_t, __sync);  
    JUMP_FIELD(_IO_doallocate_t, __doallocate);  
    JUMP_FIELD(_IO_read_t, __read);  
    JUMP_FIELD(_IO_write_t, __write);  
    JUMP_FIELD(_IO_seek_t, __seek);  
    JUMP_FIELD(_IO_close_t, __close);  
    JUMP_FIELD(_IO_stat_t, __stat);  
    JUMP_FIELD(_IO_showmanyc_t, __showmanyc);  
    JUMP_FIELD(_IO_imbue_t, __imbue);  
#if 0  
    get_column;  
    set_column;  
#endif  
};

整体流程

源码解析

实际fread进入的是_IO_fread

#include "libioP.h"

size_t
_IO_fread (void *buf, size_t size, size_t count, FILE *fp)
{
	size_t bytes_requested = size * count;
	size_t bytes_read;
	CHECK_FILE (fp, 0);
	if (bytes_requested == 0)
	return 0;
	_IO_acquire_lock (fp);
	bytes_read = _IO_sgetn (fp, (char *) buf, bytes_requested);
	_IO_release_lock (fp);
	return bytes_requested == bytes_read ? count : bytes_read / size;
}
libc_hidden_def (_IO_fread)
weak_alias (_IO_fread, fread)

# ifndef _IO_MTSAFE_IO
strong_alias (_IO_fread, __fread_unlocked)
libc_hidden_def (__fread_unlocked)
weak_alias (_IO_fread, fread_unlocked)
# endif

进入_IO_sgetn

size_t
_IO_sgetn (FILE *fp, void *data, size_t n)
{
	/* FIXME handle putback buffer here! */
	return _IO_XSGETN (fp, data, n);
}
libc_hidden_def (_IO_sgetn)

IO_JUMPS_FUNC(THIS)返回的是_IO_jump_t地址,对应FILE结构体的vtable字段,由于JUMP2第一个参数就是__xsgetn，所以->FUNC访问的就是_IO_jump_t结构体中__xsgetn,采用的是vtable + offset的形式(借此可以伪造vtable,实现任意合法执行)

#define _IO_XSGETN(FP, DATA, N) JUMP2 (__xsgetn, FP, DATA, N)  
#define JUMP2(FUNC, THIS, X1, X2) (_IO_JUMPS_FUNC(THIS)->FUNC) (THIS, X1, X2)  
# define _IO_JUMPS_FUNC(THIS) (IO_validate_vtable (_IO_JUMPS_FILE_plus (THIS)))
static inline const struct _IO_jump_t *
IO_validate_vtable (const struct _IO_jump_t *vtable)
{
	uintptr_t ptr = (uintptr_t) vtable;
	uintptr_t offset = ptr - (uintptr_t) &__io_vtables;
	if (__glibc_unlikely (offset >= IO_VTABLES_LEN))
	/* The vtable pointer is not in the expected section. Use the
	slow path, which will terminate the process if necessary. */
	_IO_vtable_check ();
	return vtable;
}

void attribute_hidden
_IO_vtable_check (void)
{
#ifdef SHARED
	/* Honor the compatibility flag. */
	void (*flag) (void) = atomic_load_relaxed (&IO_accept_foreign_vtables);
	PTR_DEMANGLE (flag);
	if (flag == &_IO_vtable_check)
	return;
  
/* In case this libc copy is in a non-default namespace, we always
need to accept foreign vtables because there is always a
possibility that FILE * objects are passed across the linking
boundary. */
	{
		Dl_info di;
		struct link_map *l;
		if (!rtld_active ()
		|| (_dl_addr (_IO_vtable_check, &di, &l, NULL) != 0
		&& l->l_ns != LM_ID_BASE))
		return;
	}

  
#else /* !SHARED */
	/* We cannot perform vtable validation in the static dlopen case
	because FILE * handles might be passed back and forth across the
	boundary. Therefore, we disable checking in this case. */
	if (__dlopen != NULL)
		return;
#endif

__libc_fatal ("Fatal error: glibc detected an invalid stdio handle\n");

}

0x7ffff7e26661 <_IO_sgetn+33>              jmp    qword ptr [rax + 0x40]      <__GI__IO_file_xsgetn>

进入__GI__IO_file_xsgetn

size_t
_IO_file_xsgetn (FILE *fp, void *data, size_t n)
{
	size_t want, have;
	ssize_t count;
	char *s = data;
	want = n;
	
	
	/*第一部分*/
	//如果没有申请buf,_IO_doallocbuf内部malloc一个
	if (fp->_IO_buf_base == NULL)
	{
	/* Maybe we already have a push back pointer. */
		if (fp->_IO_save_base != NULL)
		{
			_IO_free_backup_buf (fp, fp->_IO_save_base);
			fp->_flags &= ~_IO_IN_BACKUP;
		}
	_IO_doallocbuf (fp);
	}
	
	while (want > 0)
	{   /*第二部分*/
		have = fp->_IO_read_end - fp->_IO_read_ptr;
		if (want <= have)
		{
			memcpy (s, fp->_IO_read_ptr, want);
			fp->_IO_read_ptr += want;
			want = 0;
		}
		else
		{
			if (have > 0)
			{
				s = __mempcpy (s, fp->_IO_read_ptr, have);
				want -= have;
				fp->_IO_read_ptr += have;
			}
			
			/*第三部分*/
			/* Check for backup and repeat */
			if (_IO_in_backup (fp))
			{
				_IO_switch_to_main_get_area (fp);
				continue;
			}
		
		
			/* If we now want less than a buffer, underflow and repeat
			the copy. Otherwise, _IO_SYSREAD directly to
			the user buffer. */
			/*第四部分*/
			if (fp->_IO_buf_base
			&& want < (size_t) (fp->_IO_buf_end - fp->_IO_buf_base))
			{
				if (__underflow (fp) == EOF)
				break;
				continue;
			}
			
			/* These must be set before the sysread as we might longjmp out
			waiting for input. */
			_IO_setg (fp, fp->_IO_buf_base, fp->_IO_buf_base, fp->_IO_buf_base);
			_IO_setp (fp, fp->_IO_buf_base, fp->_IO_buf_base);
			
			/* Try to maintain alignment: read a whole number of blocks. */
			count = want;
			if (fp->_IO_buf_base)
			{
				size_t block_size = fp->_IO_buf_end - fp->_IO_buf_base;
				if (block_size >= 128)
				count -= want % block_size;
			}
			
			count = _IO_SYSREAD (fp, s, count);
			if (count <= 0)
			{
				if (count == 0)
					fp->_flags |= _IO_EOF_SEEN;
				else
					fp->_flags |= _IO_ERR_SEEN;
				break;
			}
			
			s += count;
			want -= count;
			if (fp->_offset != _IO_pos_BAD)
				_IO_pos_adjust (fp->_offset, count);
		}
	}
	
	return n - want;
}
libc_hidden_def (_IO_file_xsgetn)

第一部分 3.1 进入_IO_doallocbuf

void
_IO_doallocbuf (FILE *fp)
{
	if (fp->_IO_buf_base)
	return;
	if (!(fp->_flags & _IO_UNBUFFERED) || fp->_mode > 0)
	if (_IO_DOALLOCATE (fp) != EOF)
	return;
	_IO_setb (fp, fp->_shortbuf, fp->_shortbuf+1, 0);
}
libc_hidden_def (_IO_doallocbuf)

3.2通过vtable进入_IO_file_doallocate 3.3进入vtable中的_IO_file_stat函数，也是通过vtable+offset 3.4调用fstat64，这个系统调用是来获取文件状态，并且初始化st结构体的可以看到此时的st_blksize为4096 3.5而这个st_blksize也就是接下来malloc申请的内存大小 3.6调用_IO_setb ,这个函数主要就是对_IO_buf_base和_IO_buf_end指针进行赋值

void
_IO_setb (FILE *f, char *b, char *eb, int a)
{
	if (f->_IO_buf_base && !(f->_flags & _IO_USER_BUF))
		free (f->_IO_buf_base);
	f->_IO_buf_base = b;
	f->_IO_buf_end = eb;
	if (a)
		f->_flags &= ~_IO_USER_BUF;
	else
		f->_flags |= _IO_USER_BUF;
}
libc_hidden_def (_IO_setb)

执行前执行后第二部分 have是剩余的缓冲区大小,want是需要读入的大小如果want小于等于have直接memcpy 如果have还有剩余但是want大于have，把能读的先读完

		have = fp->_IO_read_end - fp->_IO_read_ptr;
		if (want <= have)
		{
			memcpy (s, fp->_IO_read_ptr, want);
			fp->_IO_read_ptr += want;
			want = 0;
		}
		else
		{
			if (have > 0)
			{
				s = __mempcpy (s, fp->_IO_read_ptr, have);
				want -= have;
				fp->_IO_read_ptr += have;
			}

第三部分

如果当前处于备用的缓冲区，切换为主缓冲区

	/* Check for backup and repeat */
			if (_IO_in_backup (fp))
			{
				_IO_switch_to_main_get_area (fp);
				continue;
			}

#define _IO_in_backup(fp) ((fp)->_flags & _IO_IN_BACKUP)

void
_IO_switch_to_main_get_area (FILE *fp)
{
	char *tmp;
	fp->_flags &= ~_IO_IN_BACKUP;
	/* Swap _IO_read_end and _IO_save_end. */
	tmp = fp->_IO_read_end;
	fp->_IO_read_end = fp->_IO_save_end;
	fp->_IO_save_end= tmp;
	/* Swap _IO_read_base and _IO_save_base. */
	tmp = fp->_IO_read_base;
	fp->_IO_read_base = fp->_IO_save_base;
	fp->_IO_save_base = tmp;
	/* Set _IO_read_ptr. */
	fp->_IO_read_ptr = fp->_IO_read_base;
}

第四部分 __underflow 它先是经过一些检查后，去调用了vtable中的_IO_file_underflow函数

int
__underflow (FILE *fp)
{
	if (_IO_vtable_offset (fp) == 0 && _IO_fwide (fp, -1) != -1)
		return EOF;
	if (fp->_mode == 0)
		_IO_fwide (fp, -1);
	if (_IO_in_put_mode (fp))
		if (_IO_switch_to_get_mode (fp) == EOF)
			return EOF;
	if (fp->_IO_read_ptr < fp->_IO_read_end)
		return *(unsigned char *) fp->_IO_read_ptr;
	if (_IO_in_backup (fp))
	{
		_IO_switch_to_main_get_area (fp);
		if (fp->_IO_read_ptr < fp->_IO_read_end)
			return *(unsigned char *) fp->_IO_read_ptr;
		}
	if (_IO_have_markers (fp))
	{
		if (save_for_backup (fp, fp->_IO_read_end))
			return EOF;
	}
	else if (_IO_have_backup (fp))
		_IO_free_backup_area (fp);
	return _IO_UNDERFLOW (fp);
}
libc_hidden_def (__underflow)

在最后_IO_UNDERFLOW，通过vtable调用了_IO_file_underflow函数

int
_IO_new_file_underflow (FILE *fp)
{
	ssize_t count;
	/* C99 requires EOF to be "sticky". */
	if (fp->_flags & _IO_EOF_SEEN)
		return EOF;
	if (fp->_flags & _IO_NO_READS)
	{
		fp->_flags |= _IO_ERR_SEEN;
		__set_errno (EBADF);
		return EOF;
	}
	if (fp->_IO_read_ptr < fp->_IO_read_end)
		return *(unsigned char *) fp->_IO_read_ptr;
	if (fp->_IO_buf_base == NULL)
	{
		/* Maybe we already have a push back pointer. */
		if (fp->_IO_save_base != NULL)
		{
			_IO_free_backup_buf (fp, fp->_IO_save_base);
			fp->_flags &= ~_IO_IN_BACKUP;
		}
		_IO_doallocbuf (fp);
	}
	/* FIXME This can/should be moved to genops ?? */
	if (fp->_flags & (_IO_LINE_BUF|_IO_UNBUFFERED))
	{
	
	/* We used to flush all line-buffered stream. This really isn't
	required by any standard. My recollection is that
	traditional Unix systems did this for stdout. stderr better
	not be line buffered. So we do just that here
	explicitly. --drepper */
	
		_IO_acquire_lock (stdout);
		if ((stdout->_flags & (_IO_LINKED | _IO_NO_WRITES | _IO_LINE_BUF))
		== (_IO_LINKED | _IO_LINE_BUF))
			_IO_OVERFLOW (stdout, EOF);
		_IO_release_lock (stdout);
	}
	
	_IO_switch_to_get_mode (fp);
	
	/* This is very tricky. We have to adjust those
	pointers before we call _IO_SYSREAD () since
	we may longjump () out while waiting for
	input. Those pointers may be screwed up. H.J. */
	
	fp->_IO_read_base = fp->_IO_read_ptr = fp->_IO_buf_base;
	fp->_IO_read_end = fp->_IO_buf_base;
	fp->_IO_write_base = fp->_IO_write_ptr = fp->_IO_write_end
	= fp->_IO_buf_base;
	
	count = _IO_SYSREAD (fp, fp->_IO_buf_base,
	fp->_IO_buf_end - fp->_IO_buf_base);
	if (count <= 0)
	{
		if (count == 0)
			fp->_flags |= _IO_EOF_SEEN;
		else
			fp->_flags |= _IO_ERR_SEEN, count = 0;
	}
	fp->_IO_read_end += count;
	if (count == 0)
	{
	
	/* If a stream is read to EOF, the calling application may switch active
	handles. As a result, our offset cache would no longer be valid, so
	unset it. */
	
		fp->_offset = _IO_pos_BAD;
		return EOF;
	}
	if (fp->_offset != _IO_pos_BAD)
		_IO_pos_adjust (fp->_offset, count);
	return *(unsigned char *) fp->_IO_read_ptr;
}

libc_hidden_ver (_IO_new_file_underflow, _IO_file_underflow)

上来就是很多检查，不过根据程序当前的状态，直接跳过了前面的检查。先去执行了_IO_switch_to_get_mode 函数可以看到是给_IO_read_base赋值，其他也赋值了不过都是0

int
_IO_switch_to_get_mode (FILE *fp)
{
	if (fp->_IO_write_ptr > fp->_IO_write_base)
		if (_IO_OVERFLOW (fp, EOF) == EOF)
			return EOF;
	if (_IO_in_backup (fp))
		fp->_IO_read_base = fp->_IO_backup_base;
	else
	{
		fp->_IO_read_base = fp->_IO_buf_base;
		if (fp->_IO_write_ptr > fp->_IO_read_end)
			fp->_IO_read_end = fp->_IO_write_ptr;
	}
	fp->_IO_read_ptr = fp->_IO_write_ptr;
	  
	fp->_IO_write_base = fp->_IO_write_ptr = fp->_IO_write_end = fp->_IO_read_ptr;
	
	fp->_flags &= ~_IO_CURRENTLY_PUTTING;
	return 0;
}

libc_hidden_def (_IO_switch_to_get_mode)

执行前执行后

接下来就是赋值

fp->_IO_read_base = fp->_IO_read_ptr = fp->_IO_buf_base;
	fp->_IO_read_end = fp->_IO_buf_base;
	fp->_IO_write_base = fp->_IO_write_ptr = fp->_IO_write_end
	= fp->_IO_buf_base;

执行后然后是执行，通过vtavle进入_IO_file_read

count = _IO_SYSREAD (fp, fp->_IO_buf_base,

内部调用了read，读入_IO_read_ptr 读入后，现在_IO_read_end没有变执行到

fp->_IO_read_end += count;

的时候才被改变之后再次循环，不断改变_IO_read_ptr的值直到结束，退出

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://c4e-i-um-github-io.vercel.app/blog/fread%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%90/

fopen源码解析

Caelum — Sat, 04 Apr 2026 00:00:00 GMT

前置知识

_IO_FILE_plus 结构体

struct _IO_FILE_plus
{
  _IO_FILE file;
  const struct _IO_jump_t *vtable;
};

_IO_FILE结构体

先说_IO_FILE结构体，该结构体就是标准IO库中用来描述文件的结构，在程序执行fopen函数时会创建该结构，并分配在堆中。

struct _IO_FILE {
  int _flags;		/* High-order word is _IO_MAGIC; rest is flags. */
#define _IO_file_flags _flags

  /* The following pointers correspond to the C++ streambuf protocol. */
  /* Note:  Tk uses the _IO_read_ptr and _IO_read_end fields directly. */
  char* _IO_read_ptr;	/* Current read pointer */ 
  char* _IO_read_end;	/* End of get area. */
  char* _IO_read_base;	/* Start of putback+get area. */
  char* _IO_write_base;	/* Start of put area. */
  char* _IO_write_ptr;	/* Current put pointer. */
  char* _IO_write_end;	/* End of put area. */
  char* _IO_buf_base;	/* Start of reserve area. */
  char* _IO_buf_end;	/* End of reserve area. */
  /* The following fields are used to support backing up and undo. */
  char *_IO_save_base; /* Pointer to start of non-current get area. */
  char *_IO_backup_base;  /* Pointer to first valid character of backup area */
  char *_IO_save_end; /* Pointer to end of non-current get area. */

  struct _IO_marker *_markers;

  struct _IO_FILE *_chain;

  int _fileno;
#if 0
  int _blksize;
#else
  int _flags2;
#endif
  _IO_off_t _old_offset; /* This used to be _offset but it's too small.  */

#define __HAVE_COLUMN /* temporary */
  /* 1+column number of pbase(); 0 is unknown. */
  unsigned short _cur_column;
  signed char _vtable_offset;
  char _shortbuf[1];

  /*  char* _save_gptr;  char* _save_egptr; */

  _IO_lock_t *_lock;
#ifdef _IO_USE_OLD_IO_FILE
};

调试源码

#include <stdio.h>
#include <stdlib.h>

int main() {
	FILE *file = fopen("example.txt", "r");
	if (file == NULL) {
		perror("Error opening file");
		return EXIT_FAILURE;
	}
	
	fclose(file);
	return EXIT_SUCCESS;
}

总体概述

源码解析

打断点到fopen

fopen实际上进入的是_IO_new_fopen函数

FILE *
_IO_new_fopen (const char *filename, const char *mode)
{
	return __fopen_internal (filename, mode, 1);
}

strong_alias (_IO_new_fopen, __new_fopen)
versioned_symbol (libc, _IO_new_fopen, _IO_fopen, GLIBC_2_1);
versioned_symbol (libc, __new_fopen, fopen, GLIBC_2_1);

# if !defined O_LARGEFILE || O_LARGEFILE == 0
  weak_alias (_IO_new_fopen, _IO_fopen64)
  weak_alias (_IO_new_fopen, fopen64)
# endif

2. _IO_new_fopen函数进入了__fopen_internal 这个函数是对_IO_new_file_init_internal的封装，会在这里申请一个locked_FILE结构体

FILE *
__fopen_internal (const char *filename, const char *mode, int is32)
{
	struct locked_FILE
	{
		struct _IO_FILE_plus fp;
#ifdef _IO_MTSAFE_IO
		_IO_lock_t lock;
#endif
		struct _IO_wide_data wd;
	} *new_f = (struct locked_FILE *) malloc (sizeof (struct locked_FILE));
	
	  

	if (new_f == NULL)
		return NULL;
#ifdef _IO_MTSAFE_IO
	new_f->fp.file._lock = &new_f->lock;
#endif
	_IO_no_init (&new_f->fp.file, 0, 0, &new_f->wd, &_IO_wfile_jumps);
	_IO_JUMPS (&new_f->fp) = &_IO_file_jumps;
	_IO_new_file_init_internal (&new_f->fp);
	if (_IO_file_fopen ((FILE *) new_f, filename, mode, is32) != NULL)
		return __fopen_maybe_mmap (&new_f->fp.file);
	  
	_IO_un_link (&new_f->fp);
	free (new_f);
	return NULL;
}

pwndbg> ptype struct locked_FILE 
type = struct locked_FILE {
    struct _IO_FILE_plus fp;
    _IO_lock_t lock;
    struct _IO_wide_data wd;
}

__fopen_internal进入_IO_no_init

可以发现是初始化FILE结构体，分为两个部分_IO_old_init和wide_data的a初始化

void
_IO_no_init (FILE *fp, int flags, int orientation,
struct _IO_wide_data *wd, const struct _IO_jump_t *jmp)
{
	_IO_old_init (fp, flags);
	fp->_mode = orientation;
	if (orientation >= 0)
{

	fp->_wide_data = wd;
	fp->_wide_data->_IO_buf_base = NULL;
	fp->_wide_data->_IO_buf_end = NULL;
	fp->_wide_data->_IO_read_base = NULL;
	fp->_wide_data->_IO_read_ptr = NULL;
	fp->_wide_data->_IO_read_end = NULL;
	fp->_wide_data->_IO_write_base = NULL;
	fp->_wide_data->_IO_write_ptr = NULL;
	fp->_wide_data->_IO_write_end = NULL;
	fp->_wide_data->_IO_save_base = NULL;
	fp->_wide_data->_IO_backup_base = NULL;
	fp->_wide_data->_IO_save_end = NULL;
	
	fp->_wide_data->_wide_vtable = jmp;

}

else
	/* Cause predictable crash when a wide function is called on a byte
	stream. */
	fp->_wide_data = (struct _IO_wide_data *) -1L;
	fp->_freeres_list = NULL;
	fp->_total_written = 0;
}

初始化之前 4._IO_no_init 进入_IO_old_init

void
_IO_old_init (FILE *fp, int flags)
{
	fp->_flags = _IO_MAGIC|flags;  /*_IO_MAGIC是魔数标志位，表明这个FILE对象是有效的*/
	fp->_flags2 = 0;
	if (stdio_needs_locking)
	fp->_flags2 |= _IO_FLAGS2_NEED_LOCK;
	fp->_IO_buf_base = NULL;
	fp->_IO_buf_end = NULL;
	fp->_IO_read_base = NULL;
	fp->_IO_read_ptr = NULL;
	fp->_IO_read_end = NULL;
	fp->_IO_write_base = NULL;
	fp->_IO_write_ptr = NULL;
	fp->_IO_write_end = NULL;
	fp->_chain = NULL; /* Not necessary. */
	
	fp->_IO_save_base = NULL;
	fp->_IO_backup_base = NULL;
	fp->_IO_save_end = NULL;
	fp->_markers = NULL;
	fp->_cur_column = 0;
	#if _IO_JUMPS_OFFSET
	fp->_vtable_offset = 0;
#endif
#ifdef _IO_MTSAFE_IO
	if (fp->_lock != NULL)
	_IO_lock_init (*fp->_lock);
#endif
}

经过_IO_old_init初始化后 5. 设置_mode，这个字段代表的是流的字符方向/宽窄方向

void 
   587 _IO_no_init (FILE *fp, int flags, int orientation,
   588              struct _IO_wide_data *wd, const struct _IO_jump_t *jmp)
   589 {
   590   _IO_old_init (fp, flags);
 ► 591   fp->_mode = orientation;

`fp->_mode` 不是打开模式 `"r" / "w" / "a"`，而是 **流的字符方向/宽窄方向**：

- `0`：还没定向，未决定是字节流还是宽字符流
- `> 0`：宽字符流 wide-oriented
- `< 0`：字节流 byte-oriented

6. 初始化宽字符数据_wide_data 7. 返回__fopen_internal 8. 执行_IO_JUMPS (&new_f->fp) = &_IO_file_jumps;

#define _IO_JUMPS(THIS) (THIS)->vtable

也就是

new_f->fp.vtable = &_IO_file_jumps;

执行之前

pwndbg> p *new_f
$5 = {
  fp = {
    file = {
      _flags = -72548352,
      _IO_read_ptr = 0x0,
      _IO_read_end = 0x0,
      _IO_read_base = 0x0,
      _IO_write_base = 0x0,
      _IO_write_ptr = 0x0,
      _IO_write_end = 0x0,
      _IO_buf_base = 0x0,
      _IO_buf_end = 0x0,
      _IO_save_base = 0x0,
      _IO_backup_base = 0x0,
      _IO_save_end = 0x0,
      _markers = 0x0,
      _chain = 0x0,
      _fileno = 0,
      _flags2 = 0,
      _short_backupbuf = "",
      _old_offset = 0,
      _cur_column = 0,
      _vtable_offset = 0 '\000',
      _shortbuf = "",
      _lock = 0x5555555590f0,
      _offset = 0,
      _codecvt = 0x0,
      _wide_data = 0x555555559100,
      _freeres_list = 0x0,
      _freeres_buf = 0x0,
      _prevchain = 0x0,
      _mode = 0,
      _unused3 = 0,
      _total_written = 0,
      _unused2 = "\000\000\000\000\000\000\000"
    },
    vtable = 0x0    /*这里还没有*/
  },
  lock = {
    lock = 0,
    cnt = 0,
    owner = 0x0
  },
  wd = {
    _IO_read_ptr = 0x0,
    _IO_read_end = 0x0,
    _IO_read_base = 0x0,
    _IO_write_base = 0x0,
    _IO_write_ptr = 0x0,
    _IO_write_end = 0x0,
    _IO_buf_base = 0x0,
    _IO_buf_end = 0x0,
    _IO_save_base = 0x0,
    _IO_backup_base = 0x0,
    _IO_save_end = 0x0,
    _IO_state = {
      __count = 0,
      __value = {
        __wch = 0,
        __wchb = "\000\000\000"
      }
    },
    _IO_last_state = {
      __count = 0,
      __value = {
        __wch = 0,
        __wchb = "\000\000\000"
      }
    },
    _codecvt = {
      __cd_in = {
        step = 0x0,
        step_data = {
          __outbuf = 0x0,
          __outbufend = 0x0,
          __flags = 0,
          __invocation_counter = 0,
          __internal_use = 0,
          __statep = 0x0,
          __state = {
            __count = 0,
            __value = {
              __wch = 0,
              __wchb = "\000\000\000"
            }
          }
        }
      },
      __cd_out = {
        step = 0x0,
        step_data = {
          __outbuf = 0x0,
          __outbufend = 0x0,
          __flags = 0,
          __invocation_counter = 0,
          __internal_use = 0,
          __statep = 0x0,
          __state = {
            __count = 0,
            __value = {
              __wch = 0,
              __wchb = "\000\000\000"
            }
          }
        }
      }
    },
    _shortbuf = L"",
    _wide_vtable = 0x7ffff7f7c228 <_IO_wfile_jumps>
  }
}

执行后

 fp = {
    file = {
      _flags = -72548352,
      _IO_read_ptr = 0x0,
      _IO_read_end = 0x0,
      _IO_read_base = 0x0,
      _IO_write_base = 0x0,
      _IO_write_ptr = 0x0,
      _IO_write_end = 0x0,
      _IO_buf_base = 0x0,
      _IO_buf_end = 0x0,
      _IO_save_base = 0x0,
      _IO_backup_base = 0x0,
      _IO_save_end = 0x0,
      _markers = 0x0,
      _chain = 0x0,
      _fileno = 0,
      _flags2 = 0,
      _short_backupbuf = "",
      _old_offset = 0,
      _cur_column = 0,
      _vtable_offset = 0 '\000',
      _shortbuf = "",
      _lock = 0x5555555590f0,
      _offset = 0,
      _codecvt = 0x0,
      _wide_data = 0x555555559100,
      _freeres_list = 0x0,
      _freeres_buf = 0x0,
      _prevchain = 0x0,
      _mode = 0,
      _unused3 = 0,
      _total_written = 0,
      _unused2 = "\000\000\000\000\000\000\000"
    },
    vtable = 0x7ffff7f7c030 <_IO_file_jumps>
  },
  ...
  ...  
}

进入_IO_new_file_init_internal

void
_IO_new_file_init_internal (struct _IO_FILE_plus *fp)
{
	/* POSIX.1 allows another file handle to be used to change the position
	of our file descriptor. Hence we actually don't know the actual
	position before we do the first fseek (and until a following fflush). */
	fp->file._offset = _IO_pos_BAD;
	fp->file._flags |= CLOSED_FILEBUF_FLAGS;
	_IO_link_in (fp);
	fp->file._fileno = -1;
}

进入 _IO_link_in 主要是把新的_IO_FILE_plus结构体加入_IO_list_all

 void
_IO_link_in (struct _IO_FILE_plus *fp)
{
	if ((fp->file._flags & _IO_LINKED) == 0)
	{
		fp->file._flags |= _IO_LINKED;
#ifdef _IO_MTSAFE_IO
		_IO_cleanup_region_start_noarg (flush_cleanup);
		_IO_lock_lock (list_all_lock);
		run_fp = (FILE *) fp;
		_IO_flockfile ((FILE *) fp);
#endif
		fp->file._chain = (FILE *) _IO_list_all;
		if (_IO_vtable_offset ((FILE *) fp) == 0)
		{
			fp->file._prevchain = (FILE **) &_IO_list_all;
			if (_IO_list_all != NULL)
			_IO_list_all->file._prevchain = &fp->file._chain;
		}
			_IO_list_all = fp;   
#ifdef _IO_MTSAFE_IO
			_IO_funlockfile ((FILE *) fp);
			run_fp = NULL;
			_IO_lock_unlock (list_all_lock);
			_IO_cleanup_region_end (0);
#endif
		}
	}
libc_hidden_def (_IO_link_in)

执行_IO_file_fopen
基本是根据参数设置各种标志位

FILE *
_IO_new_file_fopen (FILE *fp, const char *filename, const char *mode,
int is32not64)
{
	int oflags = 0, omode;
	int read_write;
	int oprot = 0666;
	int i;
	FILE *result;
	const char *cs;
	const char *last_recognized;
	  
	if (_IO_file_is_open (fp))
	return NULL;
	switch (*mode)
	{
		case 'r':
		omode = O_RDONLY;
		read_write = _IO_NO_WRITES;
		break;
		case 'w':
		omode = O_WRONLY;
		oflags = O_CREAT|O_TRUNC;
		read_write = _IO_NO_READS;
		break;
		case 'a':
		omode = O_WRONLY;
		oflags = O_CREAT|O_APPEND;
		read_write = _IO_NO_READS|_IO_IS_APPENDING;
		break;
		default:
		__set_errno (EINVAL);
		return NULL;
	}
last_recognized = mode;
for (i = 1; i < 7; ++i)
{
	switch (*++mode)
	{
	case '\0':
	case ',':
		break;
	case '+':
		omode = O_RDWR;
		read_write &= _IO_IS_APPENDING;
		last_recognized = mode;
		continue;
	case 'x':
		oflags |= O_EXCL;
		last_recognized = mode;
		continue;
	case 'b':
		last_recognized = mode;
		continue;
	case 'm':
		fp->_flags2 |= _IO_FLAGS2_MMAP;
		continue;
	case 'c':
		fp->_flags2 |= _IO_FLAGS2_NOTCANCEL;
		continue;
	case 'e':
		oflags |= O_CLOEXEC;
		fp->_flags2 |= _IO_FLAGS2_CLOEXEC;
		continue;
	default:
	/* Ignore. */
		continue;
	}
	break;
	}

result = _IO_file_open (fp, filename, omode|oflags, oprot, read_write,
is32not64);
  
	if (result != NULL)
	{
		/* Test whether the mode string specifies the conversion. */
		cs = strstr (last_recognized + 1, ",ccs=");
		if (cs != NULL)
		{
		
				/* Yep. Load the appropriate conversions and set the orientation
				to wide. */
				struct gconv_fcts fcts;
				struct _IO_codecvt *cc;
				char *endp = __strchrnul (cs + 5, ',');
				char *ccs = malloc (endp - (cs + 5) + 3);
				
			if (ccs == NULL)
			{
				int malloc_err = errno; /* Whatever malloc failed with. */
				(void) _IO_file_close_it (fp);
				__set_errno (malloc_err);
				return NULL;
			}
			
			  
			
			*((char *) __mempcpy (ccs, cs + 5, endp - (cs + 5))) = '\0';
			strip (ccs, ccs);
			
			if (__wcsmbs_named_conv (&fcts, ccs[2] == '\0'
			? upstr (ccs, cs + 5) : ccs) != 0)
			{
				/* Something went wrong, we cannot load the conversion modules.
				This means we cannot proceed since the user explicitly asked
				for these. */
				(void) _IO_file_close_it (fp);
				free (ccs);
				__set_errno (EINVAL);
				return NULL;
			}
			
			free (ccs);
			assert (fcts.towc_nsteps == 1);
			assert (fcts.tomb_nsteps == 1);
			
			fp->_wide_data->_IO_read_ptr = fp->_wide_data->_IO_read_end;
			fp->_wide_data->_IO_write_ptr = fp->_wide_data->_IO_write_base;
			
			/* Clear the state. We start all over again. */
			memset (&fp->_wide_data->_IO_state, '\0', sizeof (__mbstate_t));
			memset (&fp->_wide_data->_IO_last_state, '\0', sizeof (__mbstate_t));
			
			cc = fp->_codecvt = &fp->_wide_data->_codecvt;
			cc->__cd_in.step = fcts.towc;
			
			cc->__cd_in.step_data.__invocation_counter = 0;
			cc->__cd_in.step_data.__internal_use = 1;
			cc->__cd_in.step_data.__flags = __GCONV_IS_LAST;
			cc->__cd_in.step_data.__statep = &result->_wide_data->_IO_state;
			
			cc->__cd_out.step = fcts.tomb;
			
			cc->__cd_out.step_data.__invocation_counter = 0;
			cc->__cd_out.step_data.__internal_use = 1;
			cc->__cd_out.step_data.__flags = __GCONV_IS_LAST | __GCONV_TRANSLIT;
			cc->__cd_out.step_data.__statep = &result->_wide_data->_IO_state;
			
			/* From now on use the wide character callback functions. */
			_IO_JUMPS_FILE_plus (fp) = fp->_wide_data->_wide_vtable;
			
			/* Set the mode now. */
			result->_mode = 1;
		}
	
	}
	return result;
}
libc_hidden_ver (_IO_new_file_fopen, _IO_file_fopen)

_IO_file_fopen 进入 _IO_file_open

FILE *
_IO_file_open (FILE *fp, const char *filename, int posix_mode, int prot,
int read_write, int is32not64)
{
	int fdesc;
	if (__glibc_unlikely (fp->_flags2 & _IO_FLAGS2_NOTCANCEL))
		fdesc = __open_nocancel (filename,
		posix_mode | (is32not64 ? 0 : O_LARGEFILE), prot);
	else
		fdesc = __open (filename, posix_mode | (is32not64 ? 0 : O_LARGEFILE), prot);
	if (fdesc < 0)
		return NULL;
	fp->_fileno = fdesc;     /*文件标识符fd保存在此*/
	_IO_mask_flags (fp, read_write,_IO_NO_READS+_IO_NO_WRITES+_IO_IS_APPENDING);
	/* For append mode, send the file offset to the end of the file. Don't
	update the offset cache though, since the file handle is not active. */
	if ((read_write & (_IO_IS_APPENDING | _IO_NO_READS))
	== (_IO_IS_APPENDING | _IO_NO_READS))
	{
		off64_t new_pos = _IO_SYSSEEK (fp, 0, _IO_seek_end);
		if (new_pos == _IO_pos_BAD && errno != ESPIPE)
		{
			__close_nocancel (fdesc);
			return NULL;
		}
	}
	_IO_link_in ((struct _IO_FILE_plus *) fp);
	return fp;
}
libc_hidden_def (_IO_file_open)

#define _IO_mask_flags(fp, f, mask) \
       ((fp)->_flags = ((fp)->_flags & ~(mask)) | ((f) & (mask)))

等价于

fp->_flags = (fp->_flags & ~(_IO_NO_READS|_IO_NO_WRITES|_IO_IS_APPENDING))
           | (read_write & (_IO_NO_READS|_IO_NO_WRITES|_IO_IS_APPENDING));

实际效果

模式	`read_write` 值	结果
"r"	`_IO_NO_WRITES`	可读，不可写
"w"	`_IO_NO_READS`	不可读，可写
"a"	`_IO_NO_READS\|_IO_IS_APPENDING`	不可读，可写，追加
"r+"	`0`	可读可写
"w+"	`0`	可读可写
"a+"	`_IO_IS_APPENDING`	可读可写，追加
11._IO_file_open进入open64

内部调用了openat 12. 返回._IO_file_open 13. _IO_file_open进入 _IO_link_in,再次确保FILE对象已经链入_IO_list_all 14. _IO_link_in返回 15. _IO_file_open返回__fopen_internal 16. 如果成功直接返回，如果失败fp脱离_IO_list_all，并free掉 17. fopen执行完成

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://c4e-i-um-github-io.vercel.app/blog/fopen%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%90/

archlinux启动流程

Caelum — Thu, 29 Jan 2026 00:00:00 GMT

本文大部分引自archlinux的中文wiki

大致流程可以总结为固件 -> 引导加载程序 -> 内核 -> initramfs ->早期用户空间 -> 晚期用户空间

固件

下面引用自维基百科

固件是开机时最先执行的程序。固件（英语：firmware），是一种嵌入在硬件设备中的软件。通常它是位于特殊应用集成电路（ASIC）或可编程逻辑器件（PLD）之中的闪存或EEPROM或PROM里，有的可以让用户更新。可以应用在非常广泛的电子产品中，从遥控器、计算器到电脑中的键盘、硬盘，甚至工业机器人中都可见到它的身影。

顾名思义，固件是介于软件和硬件之间的。像软件一样，它是由电脑所执行的程序。然而它是对于硬件内部而言更加贴近以及更加重要的部分，而对于外在世界而言较无重要的意义。

我们这里主要介绍两种：UEFI和BIOS

UEFI

统一可扩展固件接口（Unified Extensible Firmware Interface，简称 UEFI）**是操作系统和固件之间的接口。UEFI 提供了启动操作系统或运行预启动程序的标准环境。

BIOS

基本IO系统，（Basic Input-Output System）大多数情况下储存在主板自身的一块闪存内，独立于其它系统存储。

UEFI和BIOS

UEFI是BIOS的现代替代品，BIOS则较为传统

区别

特性	BIOS	UEFI
程序模式	16位实模式	32/64位保护模式
用户界面	文本菜单，键盘操作	图形界面，支持鼠标和触摸
硬盘分区	MBR（最大2TB，4主分区）	GPT（容量极大，分区数多）
启动流程	从MBR的固定扇区读取代码	从ESP分区中的可执行文件启动
启动速度	相对较慢	通常更快（支持快速启动）
安全功能	无或很弱	安全启动，防止恶意软件
扩展性	差	好，模块化设计
最大硬盘	2TB	理论18EB（当前受OS限制）

共同点

核心作用：

开机自检：检查CPU、内存、硬盘、显卡等关键硬件是否正常。
初始化硬件：加载硬件的基本驱动程序。
引导操作系统：按照预设顺序（如硬盘、U盘、光盘）寻找可启动设备，并加载该设备上主引导记录（MBR）中的引导程序，从而启动操作系统（如Windows、Linux）。

工作流程

以bios为例在电脑开启之后，bios会直接存在于内存之中，然后检测接入电脑的各种输入输出设备，比如U盘，硬盘，显示器，键盘，显卡等，然后会进行加电自检，检查计算机设备硬件是否存在问题，进而保证计算机的正常运行。

接下来就要分两种情况了首先要补充一点知识

EFI系统分区

EFI系统分区（也称为 ESP）是一个与操作系统无关的分区，其中存储了由 UEFI 固件启动的 UEFI 引导加载器、应用程序和驱动，是 UEFI 启动所必须的。

可见我的磁盘标签是GPT并且具有EFI分区，我的电脑是使用的UEFI,绝大多数现代电脑也都用的UEFI

使用UEFI的情况

加电自检后，UEFI 初始化引导所需的硬件（硬盘、键盘控制器等等）。
固件读取 NVRAM 中的引导项，以决定要启动哪一个 EFI 应用程序，以及从哪启动（比如从哪一个硬盘和分区）。
- 一个引导项可能对应的只是一块硬盘。在这种情况下，固件会寻找硬盘上的 EFI 系统分区，并尝试在后备引导路径 \EFI\BOOT\BOOTx64.EFI 处（在 IA32（32 位）UEFI 的系统上为 BOOTIA32.EFI）查找 EFI 应用程序。这就是UEFI 可引导可移除介质的工作原理。
固件启动 EFI 应用程序。
- 这可以是一个引导加载程序，或者是使用 EFISTUB 的 Arch 内核本体。
- 还可以是一些其他的 EFI 应用程序，比如 UEFI shell 或引导管理器（例如 systemd-boot) 或 rEFInd）。

如果启用了安全启动，启动过程将会通过签名验证 EFI 二进制文件的真实性。

使用BIOS的情况

上电自检后，BIOS 初始化引导所需的硬件（硬盘、键盘控制器等等）。
BIOS 启动在“BIOS 硬盘顺序”中第一块硬盘上的前 440 字节代码(即主引导记录引导代码区域)
引导加载程序在 MBR 引导代码的第一阶段，之后会从下列任意一处启动第二阶段代码（如果有的话）：
- MBR 之后的下一个磁盘扇区，即所谓 MBR 后间隙（post-MBR gap，仅在 MBR 分区表上有）。
- 分区或者无分区磁盘的卷引导记录（Volume Boot Record，VBR）。
- GRUB 特定 BIOS 引导分区（仅限 GPT 分区硬盘上的 GRUB，用于 GPT 上没有 MBR 后间隙的情况）

真正的引导加载程序启动。
随后，引导加载程序通过链式加载或直接加载操作系统内核的方式加载操作系统。

引导加载程序

这是前文BIOS和UEFI启动的程序

引导加载程序(boot loader)，负责用指定的内核参数加载内核和其他initramfs映像

引导管理器(boot managerc),让用户使用启动选项菜单或其他方式控制启动过程

一些程序例如GRUB兼具上面两者的功能

在 UEFI 的情况下，内核本身可以由 UEFI 使用 EFI boot stub接启动。要在引导前编辑内核参数，可以使用引导管理器或是单独的引导加载程序。

注意

引导加载程序必须能够访问通常位于 /boot 目录下的内核和 initramfs 映像才能成功引导 Arch 系统。也就是说，引导加载程序必须解决从块设备、堆叠块设备（LVM、RAID、dm-crypt、LUKS 等）开始，到内核和 initramfs 映像所在文件系统为止的访问。

因为几乎没有引导加载程序支持堆叠块设备，并且文件系统引入的一些新特性可能尚未有任何引导加载程序支持，所以用广泛支持的文件系统（例如 FAT32）单独创建 /boot 分区通常更可行。

内核

然后就到了下一步内核 boot loader会启动包含内核的vmlinux映像

内核是操作系统的核心。它运行于一个叫_内核空间_的底层上，负责机器硬件和应用程序之间的交流。在继续进入用户空间前，内核会首先执行硬件枚举和初始化。

在linux系统中，vmlinux（vmlinuz）是一个包含linux kernel的静态链接的可执行文件，文件类型可能是linux接受的可执行文件格式之一（ELF、COFF或a.out），vmlinux若要用于调试时则必须要在开机前增加symbol table。随着 linux Kernel 的成长，核心的内容日益增加超越了原本的限制大小。bzImage (big zImage) 格式则为了克服此缺点开始发展，利用将核心切割成不连续的存储器区块来克服大小限制。 bzImage 格式仍然是以 zlib 算法来做压缩，虽然有一些广泛的误解就是因为以 bz- 为开头，而让人误以为是使用 bzip2 压缩方式（bzip2 包所带的工具程序通常是以 bz- 为开头的，例如 bzless, bzcat ...）。 bzImage 文件是一个特殊的格式，包含了 bootsect.o + setup.o + misc.o + piggy.o 串接。piggy.o 包含了一个 gzip 格式的 vmlinux 文件（可以参看 arch/i386/boot／下的 compressed/Makefile piggy.o）

initramfs

initramfs（初始内存文件系统，init ial RAM file system）映像是一个 cpio存档文件，为早期用户空间（见下文）启动晚期用户空间提供了必要的文件。这包括了所有用于定位，访问和挂载根文件系统的内核模块、用户空间工具、相关库文件、类似 udev 规则的支持文件等。得益于 initramfs 的概念，它可以处理更加复杂的配置场景，例如从外置硬盘启动，堆叠设备（例如逻辑卷，软 RAID，压缩和加密），或是在早期用户空间中运行一个微型 SSH 服务器，以供远程解锁或为根文件系统执行维护任务。

绝大部分内核模块都将在初始化流程的后期阶段，由udev在根切换到根文件系统后加载。

具体流程如下：

/下的根文件系统原本是一个空的 rootfs，它是一个特殊的 tmpfs 或 ramfs 实例。这里就是 initramfs 会解压到的临时根文件系统。
内核会将其内置 initramfs 解压到临时根文件系统下。Arch Linux 官方支持的内核使用空白存档作为内置 initramfs，即构建内核时的默认行为。
然后，内核会按照引导加载器传递的命令行参数指定的顺序解压外置 initramfs 映像，覆盖掉之前内置 initramfs 或其它解压出来的文件。注意，可以将多个 initramfs 映像合并为一个文件，内核会按照文件内的顺序加载映像。
- 如果首个 initramfs 映像未经压缩，那么内核会在解包该映像后在 /kernel/x86/microcode/ 目录查找 CPU 微码更新，在 /kernel/firmware/acpi/ 目录查找 ACPI 表更新。
- 在适用的情况下，在处理完 CPU 微码和 ACPI 表更新后，内核会继续解压剩余的 initramfs 映像。

initramfs 映像是 Arch Linux 推荐的早期用户空间配置方法，并可通过 mkinitcpio，dracut 或 booster来生成。

内置 initramfs 是内核镜像里的 “附属品”，体积只有几十 KB，仅包含最基础的内核启动代码，没有任何硬件驱动；
外置 initramfs 是独立文件，体积几十 MB，包含了你在 mkinitcpio.conf 中配置的所有模块、钩子、脚本，是系统启动真正依赖的早期用户空间。

内核保留内置迷你 initramfs，核心是为了兼容性兜底：

如果系统没有外置 initramfs（比如极简内核、嵌入式系统），内置 initramfs 能保证内核至少能启动到 “紧急 shell”；
对于桌面 / 服务器系统（如 Arch），外置 initramfs 可灵活定制（加驱动、加加密脚本），无需重新编译内核 —— 这也是 mkinitcpio 的核心价值：用户不用改内核，只需定制外置 initramfs 就能适配不同硬件。

udev 是一个用户空间的设备管理器，用于为事件设置处理程序。作为守护进程， udev 接收的事件主要由 linux 内核生成，这些事件是外部设备产生的物理事件。总之， udev 探测外设和热插拔，将设备控制权传递给内核，例如加载内核模块或设备固件。

udev是一个用户空间系统，可以让操作系统管理员为事件注册用户空间处理器。为了实现外设侦测和热插拔，udev 守护进程接收 Linux 内核发出的外设相关事件; 加载内核模块、设备固件; 调整设备权限，让普通用户和用户组能够访问设备。

Ramfs 是一种极简的文件系统，它将 Linux 的磁盘缓存机制（页缓存与目录项缓存）封装为可动态调整大小的基于内存的文件系统。

mkinitcpio

外置的initramfs是由mkinitcpio.conf生成的

Arch Linux 中 /etc/mkinitcpio.conf 文件里 MODULES 配置项的含义，以及当前配置的 nvme 和一系列 nvidia 相关模块的作用 —— 这是定制 initramfs（早期用户空间）的核心配置，决定了哪些内核模块会被强制打包进 initramfs，并在系统启动最早期（所有启动钩子运行前）加载，是解决硬件驱动早期加载、避免启动故障的关键。

MODELES

这个数组是手动指定的、需要强制打包进 initramfs 的内核模块，每一个模块都对应核心硬件功能，且都是 “内核自动探测 / 钩子加载可能不及时” 的关键模块：

这是定制 initramfs（早期用户空间）的核心配置，决定了哪些内核模块会被强制打包进 initramfs，并在系统启动最早期（所有启动钩子运行前）加载，是解决硬件驱动早期加载、避免启动故障的关键。

我这里主要加载了NVMe 固态硬盘的核心驱动模块以及nvidia驱动的一些模块

给和我一样的新手提醒：NVIDIA 闭源驱动是第三方模块，内核默认不识别，无法通过 udev 自动探测加载；若不提前打包进 initramfs，而是靠 modules-load.d 加载，会导致：

早期用户空间阶段显卡无输出（开机黑屏）；
切换到真正根文件系统后才加载 NVIDIA 驱动，出现显示闪烁、分辨率异常；
启用 KMS 早启动（Arch 推荐配置）时，必须在 initramfs 阶段加载 nvidia_drm，否则显卡驱动无法正常初始化。

因为靠 modules-load.d加载时在早期用户空间阶段，而在那时，你还没加载驱动

BINARIES

BINARIES 用于将你需要的额外二进制可执行文件（比如命令行工具、自定义程序）加入到 CPIO 格式的 initramfs 镜像中（initramfs 本质是 cpio 压缩包，mkinitcpio 就是 “make init cpio” 的缩写）；比如你想在 initramfs 阶段（启动时的紧急 shell）执行 lsblk 查看磁盘分区（默认 initramfs 没有 lsblk），就需要添加：

BINARIES=(/usr/bin/lsblk)

如果你想让 initramfs 自动读取密钥文件解密根分区（无需开机手动输密码），可把密钥文件添加到 FILES：

# 示例：添加LUKS解密密钥文件到initramfs
FILES=(/etc/cryptkey.bin)

FILES

FILES 和 BINARIES 作用类似（都是向 initramfs 中添加文件），但处理方式完全不同；对于files来说会as-is（原样添加）—— mkinitcpio 会把你指定的文件原封不动复制到 initramfs 中而Binaries不是

HOOKS

HOOKS 是整个配置文件中最重要的项既控制 “哪些模块 / 脚本被打包进 initramfs”，也控制 “启动时按什么顺序执行什么操作”； 顺序极其重要（后一个钩子依赖前一个的执行结果），一般不要乱改顺序； 必需钩子：

base：必选（除非你完全清楚自己在做什么），包含 initramfs 运行的最基础脚本 / 模块（比如 shell、基础工具）；
udev/systemd：二选一必选（自动加载模块的核心），我用的是 systemd 替代了传统的 udev；
filesystems：必选（除非你在 MODULES 里手动指定了所有文件系统模块），负责加载 ext4/xfs/btrfs 等文件系统驱动；

COMPRESSION_OPTIONS

COMPRESSION：设置 initramfs 镜像的压缩算法

核心作用：指定 mkinitcpio 生成 initramfs 镜像时使用的压缩算法（initramfs 本质是 cpio 包 + 压缩层，最终生成 initramfs-linux.img 是 “cpio + 压缩” 的组合）；
默认行为：mkinitcpio 会自动适配内核版本 ——Linux 内核 ≥5.9 用 zstd（Arch 主流内核都满足），<5.9 用 gzip；
特殊值：若设为 COMPRESSION="cat"，则生成未压缩的 initramfs 镜像（体积最大，但解压最快）。

MODULES_DECOMPRESS

核心作用：开关（yes/no），控制 mkinitcpio 生成 initramfs 时，是否先解压内核模块（.ko）和固件文件，再打包进镜像；
默认行为：no → 内核模块 / 固件保持原始压缩状态（Linux 内核模块默认是 xz/gzip 压缩的），直接打包进 initramfs；
开启（yes）的目的：配合「高压缩参数」（如 xz -9e、zstd -22）进一步减小 initramfs 体积 —— 因为模块先解压再用指定算法压缩，比 “模块自带压缩 + initramfs 压缩” 的「双重压缩」效率更高；
开启（yes）的代价：早期启动阶段（initramfs 解压后），模块会以未压缩状态加载到内存，占用更多 RAM；
关键注意：开启后，解压后的模块会放在 initramfs 的 “未压缩早期 CPIO” 中，避免双重压缩（否则会抵消高压缩的收益）。

早期用户空间

Linux 内核启动后，本身无法直接识别所有硬件和根文件系统（比如加密分区、LVM 逻辑卷、NVMe 固态硬盘驱动、RAID 控制器等），如果直接尝试挂载根文件系统，大概率会 “找不到设备” 或 “无法解析文件系统”。

因此，内核会先加载一个精简的、内存中的临时文件系统（initramfs/initrd） —— 这就是 “早期用户空间”：它是一个迷你版的用户空间环境，包含了启动真正根文件系统所需的最小化工具、驱动和脚本，核心使命是 “帮内核扫清障碍，让内核能成功挂载并切换到真正的根文件系统”。

简单类比：早期用户空间就像 “系统启动的前置助手”，先帮内核搞定硬件识别、加密解密、存储栈组装这些 “前置工作”，再把控制权交还给真正的根文件系统。

早期用户空间阶段（亦称“initramfs 阶段”）在由 initramfs映像提供文件的 rootfs 中进行，始于内核以 PID 1 执行 /init。

/init程序我的是systemd

加载内核模块（systemd-modules-load (8)）

作用：加载挂载真正根文件系统必需的内核模块（驱动）。

内核本身只内置了最基础的驱动，像 NVMe 硬盘、SATA 控制器、USB 存储、加密分区（dm-crypt）、LVM（dm-mod）等驱动，都以 “模块” 形式存在，需要手动加载。
实现：基于 systemd 的 initramfs 会通过 systemd-modules-load.service，读取 /etc/modules-load.d/、/usr/lib/modules-load.d/ 等配置文件，自动加载指定模块；如果是 BusyBox 版 initramfs，则通过 modprobe/insmod 命令手动加载。
举例（Arch 场景）：如果你的根分区在 NVMe 硬盘上，必须加载 nvme 模块；如果用了 LUKS 加密，必须加载 dm-crypt 模块 —— 少了这些，内核找不到根硬盘，直接卡在 “Waiting for root device”。

构建存储栈 + 解密根文件系统

这是早期用户空间最复杂也最核心的工作（尤其对加密 / RAID/LVM 系统）：

“存储栈” 是什么：把底层硬件→逻辑卷 / RAID→加密层→文件系统这一系列组件组装起来，形成能访问根分区的完整链路。

比如：NVMe 硬盘（/dev/nvme0n1p3） → LUKS 加密层（dm-crypt） → LVM 逻辑卷（vg0/root） → ext4 文件系统，这个 “栈” 必须在早期用户空间组装完成。
核心工具：
- dm-crypt：解密 LUKS 加密的根分区（Arch 中加密根分区时，initramfs 会弹出密码输入界面，输入后解密）；
- dm-verity：验证根文件系统的完整性（防止篡改）；
- mdadm：组装软 RAID 阵列；
- LVM（lvm2）：激活逻辑卷组 / 逻辑卷；
- systemd-repart：动态调整分区大小（比如启动时自动扩容根分区）。
关键注意点：如果根分区加密，解密操作只能在早期用户空间做—— 因为解密前根文件系统完全不可访问，没有任何工具能运行。

udev 解析块设备持久化名称

问题背景：Linux 设备名（如 /dev/sda3）是动态的（比如插了 U 盘后，硬盘可能从 sda 变成 sdb），直接用动态名找根分区会出错。
udev 的作用：在早期用户空间中，udev 会扫描硬件，将动态设备名映射为持久化名称（比如 /dev/disk/by-uuid/xxxx、/dev/mapper/cryptroot），确保内核能精准找到根分区，不会因设备名变动导致启动失败。

加载 DRM 模块（早启动 KMS）

DRM（Direct Rendering Manager）：Linux 显卡驱动的核心框架；KMS（Kernel Mode Setting）：内核模式设置，负责显卡分辨率、显示输出。
为什么早加载：
1. 支持启动时的图形化启动画面（比如 Arch 的 plymouth 美化启动界面）；
2. 内核能更早输出显卡相关日志，方便排查启动故障；
3. 避免后续切换根文件系统时出现显示异常（比如黑屏、分辨率错误）。

其他关键任务（挂载根前必做）

fsck 和 “从休眠中恢复” 是早期用户空间的额外核心任务，且只能在挂载真正根文件系统前执行：

fsck：文件系统检查。如果根文件系统有损坏，fsck 必须在 “未挂载” 状态下执行（挂载后执行会破坏文件系统），因此只能放在早期用户空间；
休眠恢复：从交换分区 / 休眠镜像恢复系统时，需要先挂载休眠镜像所在的分区，且此时不能挂载根文件系统（否则会冲突），因此也必须在早期用户空间完成。

systemd

systemd 是Linux 系统的系统和服务管理器，也是现代绝大多数 Linux 发行版（包括你使用的 Arch Linux）默认的PID 1 进程（系统启动后用户空间运行的第一个进程），核心替代了传统的 SysVinit、Upstart 等初始化系统，负责接管系统启动、管理服务生命周期、统筹系统各类资源，是 Linux 系统运行的核心管家。

简单说：系统开机后，内核完成初始化后，第一个启动的用户空间程序就是 systemd，之后所有的系统服务、应用进程，几乎都是由 systemd 启动 / 管理的，它也会全程监控这些进程，同时处理系统关机、休眠、设备挂载等核心操作。

modules-load.d

modules-load.d 是 systemd 系 Linux 系统的标准化配置目录，专门用于定义 “系统启动时需要自动加载的内核模块”。

我这里是开机自动加载tun内核模块，里面一般写的是虚拟驱动模块，因为一般的硬件驱动模块（NVMe、SATA、USB 存储）被内核通过 udev 自动探测加载，无需配 conf，而功能类模块（dm-crypt、LVM/dm-mod）：mkinitcpio 钩子自动打包加载，无需配 conf

晚期用户空间

晚期用户空间从 init进程开始。Arch 官方支持的 systemd基于单元和服务的概念，但这里描述的功能在很大程度上与其它 init 系统重叠。

getty

init会为每个虚拟终端（通常有六个）调用一次 getty，它会初始化终端并保护其免受未授权访问。在提供用户名和密码后，getty 会对照 /etc/passwd 和 /etc/shadow 检查是否正确。如果正确，就接着调用 login(1)。

/etc/passwd

/etc/passwd 是 Linux 系统的核心用户账户配置文件，存储了系统中 ** 所有用户（包括 root、普通用户、系统服务用户）** 的基础账户信息，是系统识别、验证用户身份的核心依据，所有用户都拥有只读权限，仅 root 可修改，是 Linux 多用户管理的基础文件。

早期该文件还存储用户的加密密码，后因安全问题（全局可读易被破解），密码被迁移到 /etc/shadow（仅 root 可读），如今 /etc/passwd 仅保留非敏感的基础用户信息，这是 Linux 安全设计的重要调整。

/etc/passwd 中每行对应一个用户，行内用冒号 : 分隔为7 个固定字段，字段顺序不可乱，空字段也需保留冒号（格式错误会导致用户登录失败）。这里不再展开

为什么需要 /etc/shadow？

早期 Linux 把用户加密密码直接存在 /etc/passwd 的第二个字段，但 /etc/passwd 为了让系统程序识别用户，必须设置全局可读权限（644），这意味着任何用户都能读取加密密码串，再通过暴力破解工具尝试解密，存在极大安全风险。

为了解决这个问题，Linux 引入了影子密码机制：将加密密码、密码有效期、账户锁定等敏感信息从 /etc/passwd 迁移到 /etc/shadow，并将其权限严格限制为仅 root 可读写（600），而 /etc/passwd 仅保留非敏感的基础用户信息，实现了敏感信息与基础信息的分离，大幅提升了系统账户安全。

迁移后，/etc/passwd 的第二个字段固定为占位符 x，表示密码信息已迁移至 /etc/shadow。

login

login 会根据 /etc/passwd 设置环境变量并启动用户 shell，从而为用户配置一个会话。在成功登录后，启动登录 shell 前，login 程序会显示 /etc/motd（message of the day）的内容，你可以用它来显示服务条款以提醒用户你的本地策略，也可以显示其它提示信息。

/etc/motd

/etc/motd 是 Linux 系统的每日提示信息文件，全称 Message of the Day，核心作用是用户通过本地终端 / SSH 远程登录系统后，自动显示的欢迎 / 提示信息，是系统管理员发布系统通知、维护提醒、安全警告的常用方式，普通用户也可自定义个性化登录欢迎语，仅对终端登录生效，图形界面登录不会显示该文件内容。

shell

用户的 shell启动后，在显示命令行提示符前，通常会执行一个运行时配置文件（例如 bashrc。如果用户账户配置为在登录时自动启动 X，那么运行时配置文件会调用 startx 或 xinit，具体内容请参考#图形会话（Xorg）。

显示管理器

这里还没提到wayland

图形会话（Xorg）

xinit 会调用用户的 xinitrc 运行时配置文件，后者一般会启动一个窗口管理器或。如果用户退出了窗口管理器，xinit、startx、shell、login 就会依次中断，返回到 getty 或显示管理器。

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://c4e-i-um-github-io.vercel.app/blog/archlinux%E5%90%AF%E5%8A%A8%E6%B5%81%E7%A8%8B/

Rust引用和借用

Caelum — Tue, 27 Jan 2026 00:00:00 GMT

概述

函数传递常见问题

在上篇文章我们说到，凡是用到Box的变量中赋值的时候会出现所有权的转移，称为移动

但是每次这样移动未免太过麻烦，并且在函数传递的时候更不方便

比如下面这个例子

format!是重新创建一个格式化后的String类型变量

fn main(){
	let m1 = String::from("Hello");
	let m2 = Srting::from("world");
	greet(m1,m2);   #L2
	let s = format!("{} {}",m1,m2);  #L3  //Error: m1 and m2 are moved
}

fn greet(g1: Srting,g2: String){
	println!("{} {}!",g1,g2);  #L1
}

这个例子是在函数传递的时候发生了移动，导致原来的变量无法访问，如果访问编译器会报错

解决方式

第一种（返回值的方式）

let (m1_again,m2_again) = greet(m1,m2);是把greet的两个返回值分别返回给m1_again,m2_again

把所有权再移动回main函数中的变量所有权转移： m1 -> g1 -> m1_again m2 -> g2 -> m2_again

fn main(){
	let m1 = String::from("Hello");
	let m2 = String::from("world"); #L1
	let (m1_again,m2_again) = greet(m1,m2);
	let s = format!("{} {}",m1_again,m2_again); #L2
}

fn greet(g1: String,g2: Srting) -> (String, String){
	println!("{} {}", g1, g2);
	(g1, g2)
}

第二种（引用的方式）

由第一种可以看出，返回值的方式同样复杂，为了解决这种不方便，rust有一种类型叫做引用

引用

引用：引用是没有 “所有权” 的指针

也就是使用引用类型的变量不会移动所有权

fn main(){

	let m1 = String::from("Hello");
	let m1 = String::from("world"); #L1
	greet(m1,m2); #L3
	let s = format!("{} {}", m1 m2);
}

fn greet(){g1: &Srting,g2: &String}{
	#L2
	println!("{} {}", g1, g2);
}

解引用指针以访问数据

解引用运算符： *

这是我们常理解的正常解引用，也就是显示解引用

let mut x: Box<i32> = Box::new(1);
let a: i32 = *x;
*x += 1;

let r1: &Box<i32> = &x;
let b: i32 = **r1;

let r2: &i32 = &*x;
let c: i32 = *r2;  #L1

而在Rust中，很多情况都是隐式的解引用

let x: Box<i32> = Box::new(-1);
let x_abs1 = i32::abs(*x);   //显式解引用
let x_abs2 = x.abs();  //隐式解引用
assert_eq!(x_abs1,x_abs2);

let r: &Box<i32> = &x;
let r_abs1 = i32::abs(**r); //显式解引用,两次
let r_abs2 = r.abs()  //隐式解引用，两次
assert_eq!(r_abs1,r_abs2)

let s = String::from("Hello");
let s_len1 = str::len(&s); //显式解引用
let s_len2 = s.len(); //隐式解引用
assert_eq!(s_len1,s_len2)

我们不难发现，Rust中有一个规律

一般类型::方法(变量) 这种需要显式解引用（或显式引用）
而变量.方法() 这种一般是隐式解引用（或隐式引用），并且支持多层

引用带来的问题

别名：通过不同的变量访问同一数据别名数据：可被多个变量访问的一块数据

一个指针变量，如果把这个变量的值传给另一个指针变量叫创建了他的一个别名（也就是所谓的传递地址）
一般来说引用一个变量也“相当于”创建了他的一个别名（但Rust中引用与别名不完全相同）

试想如果我释放了引用数据，然后再通过原变量访问，就出现了UAF

或者我通过引用改变了Heap内存的值，而原变量却不知道，可能会出现与预期不相符的结果

或引用和原变量同时修改，可能会导致数据竞争，产生漏洞

Rust为解决引用带来的不安全性的方案

Rust为解决这些可能产生未定义行为的代码，引入了一个原则：别名和可变性不可以同时存在

先看下面这个例子

补充： Vec的底层结构

ptr：指向堆上分配的内存起始地址的指针
len：当前已存储的元素数量
cap：分配的内存总共能容纳的元素数量 push 的逻辑：
如果 len < cap：直接在ptr + len的内存位置写入新元素，len += 1，指针和内存区域完全不变；
如果 len >= cap：触发扩容（reallocation）—— 分配一块更大的内存（通常是原容量的 2 倍，小容量时可能按固定值增长），把原有元素拷贝到新内存，释放旧内存，然后在新内存尾部写入新元素，此时ptr指向新内存地址。 let mut v： Vec<i32> = vec![1, 2, 3]; 是初始创建了包含3个元素1,2,3,容量为3的一个vec

let mut v: Vec<i32> = vec![1, 2, 3];
let num: &i32 = &v[2]; #L1
v.push(4); #L2
println!("Third element is {}", *num); #L3 error

这个例子由于push之后v的容量超过了原来的容量，需要另外开辟一个空间并拷贝且增加容量，那么num这个别名就访问到了非法内存，在Rust中编译器会报错

因为这违反了rust的原则：别名与可变不可以同时存在在这个例子中也就是，在num存在的时候，v不能调用push方法，v没有写的权限W

同时为了安全考虑，Rust的引用被设计之初就不是一种等同于别名的存在。

引用不等于别名

一个很好的解释说，Rust中的引用是临时创建的别名

Box(有所有权的指针)：不能别名（上文中的第一条），但可被引用（上文中的第二条），若将一个Box变量赋值给另一个Box变量（把地址传给另一个变量，别名操作），只会发生移动，也就是所有权的转移

不能让多个Box同时拥有一块数据

引用(无所有权的指针)：旨在临时创建别名，把Box的地址传给一个引用变量，这个引用可以间接访问到Box指向的Heap内存

由于println！会自动解引用

fn main(){
	let x = Box::new(1);
	let y = x;
	println!("y: {}",y);
	
	let r1 = &y;
	let r2 = &y;
	println!("r1: {r1},r2: {r2}");
  }

Rust中的权限

Rust通过借用检测器确保引用的安全性

变量（数据所在地址）对其数据（地址的内容）有三种权限：读（R）：数据可以被复制到另一个位置写（W）：数据可以被修改拥有（O）：数据可以被移动或释放

这些权限在运行时并不存在，仅在编译器内部存在

默认情况下，变量对其数据具有读/拥有权限（RO）。如果一个变量被注解为let mut,那么他还具有写权限（W）。

关键：引用可以临时移除这些权限，所以引用有时也被叫做借用，把权限暂时借用走了

补充：对于数组或者vec来说，引用其中的一个元素，这个元素地址的权限以及v都会受到影响，也就是&v[2]的权限和v的权限都变了

对于不可变引用（共享引用）：引用只会让原变量失去W和O权限，也就是修改和释放权限

比如这里的&v[2]他就是一个不可变引用

如何理解变量（数据所在地址）对其数据（地址的内容）这个限定 x_ref（一个地址）对地址的内容具有修改的权限而*x_ref（一个数0）则没有

权限是定义在位置上的

权限是定义在位置上的，不仅仅是单个变量位置上任何可以防在赋值语句左侧的东西

比如*((*a)[0].1),他就是一个位置，他具有权限这个定义

为什么失去特定权限

因为有些权限是互斥的

怎么理解

下面这个例子，当num有读权限R的时候，v就必然不能有O权限，因为num在访问v指向的Heap内存的时候，要保证v不能释放所指向的Heap内存，否则会出现未定义的行为

同时为了防止数据竞争，当num有读权限R的时候，v就必然不能有W权限，防止num读的时候，v恰好修改Heap数据而造成的数据竞争，出现未定义的行为

比如在num使用的时候,就必然不能修改v指向的内存，下面这个例子就会报错，在num还存在的时候（还使用的时候）企图通过v来修改Heap内存

不可变引用和可变引用

以上都是说的不可变引用

不可变引用可以存在多个，因为他们不违反：多个Box不能同时指向同一个Heap内存

不可变引用（共享引用）：只读的

如果只有不可变引用，我们要想修改一个Box类型指向的Heap内存，只能通过移动所有权的方式来用另一个变量修改

因此我们还需要有可变引用

可变引用（独占引用）：在不移动数据的情况下，临时提供可变访问

同一作用域，特定数据只能有一个可变的引用：

可变引用：可变引用提供对数据 “唯一的”(同一个作用域) 且 “非拥有的”访问按道理来说可变引用也可以存在多个，因为他们不违反：多个Box不能同时指向同一个Heap内存，

但是可变引用由于另一个原则，只能是唯一的

我们说过权限是互斥的，当一个可变引用在修改Heap内存的时候，其他变量，不管是原变量还是另一个原变量的引用都不能再修改Heap内存了，因为如果是同时进行的话就会出现数据竞争

也就是说，访问同一个Heap内存，只能有一个变量的权限有W,这也对应着，对于Box来说，别名和不可变性不能同时存在

同时可变引用也会让原变量失去R权限和O权限，O权限和不可变引用一样，而失去R权限还是为了防止数据竞争，在使用可变引用来修改Heap内存的时候，不能通过原变量来访问Heap内存，因为如果可变引用修改的时候原变量来访问，就会出现数据竞争，出现未定义对行为

下面是可变引用的例子

很多时候，大括号可以帮我们解决一些编译不通过的问题，通过手动限制变量的作用域：

let mut s = String::from("hello"); 
 {  
   let r1 = &mut s; 
 } // r1 在这里离开了作用域，所以我们完全可以创建一个新的引用 
  let r2 = &mut s;

不可变引用和可变引用对原变量权限的影响

由上面的例子，我们大致可以推断出这样一个原则

不可变引用可以存在多个，他会让原变量失去WO权限，而引用本身获得R权限

可变引用只能存在一个，他会让原变量失去RWO权限，而引用本身获得RW权限

由以上还可以推断出

引用不能用来释放Heap,只有权限还给原变量的时候，才能通过原变量释放Heap
原变量和引用一个有R另一个就没有W,一个有W另一个就不能有R

可变引用和不可变引用不能同时存在

下面的代码会导致一个错误：

let mut s = String::from("hello");

let r1 = &s; // 没问题
let r2 = &s; // 没问题
let r3 = &mut s; // 大问题

println!("{}, {}, and {}", r1, r2, r3);

错误如下：

error[E0502]: cannot borrow `s` as mutable because it is also borrowed as immutable
        // 无法借用可变 `s` 因为它已经被借用了不可变
 --> src/main.rs:6:14
  |
4 |     let r1 = &s; // 没问题
  |              -- immutable borrow occurs here 不可变借用发生在这里
5 |     let r2 = &s; // 没问题
6 |     let r3 = &mut s; // 大问题
  |              ^^^^^^ mutable borrow occurs here 可变借用发生在这里
7 |
8 |     println!("{}, {}, and {}", r1, r2, r3);
  |                                -- immutable borrow later used here 不可变借用在这里使用

其实这个也很好理解，正在借用不可变引用的用户，肯定不希望他借用的东西，被另外一个人莫名其妙改变了。多个不可变借用被允许是因为没有人会去试图修改数据，每个人都只读这一份数据而不做修改，因此不用担心数据被污染。

注意，引用 r1,r2,r3 的作用域从创建开始，一直持续到它最后一次使用的地方 println!(....)，这个跟变量的作用域有所不同，变量的作用域从创建持续到某一个花括号 }

Rust 的编译器一直在优化，早期的时候，引用的作用域跟变量作用域是一致的，这对日常使用带来了很大的困扰，你必须非常小心的去安排可变、不可变变量的借用，免得无法通过编译，例如以下代码：

fn main() {
   let mut s = String::from("hello");

    let r1 = &s;
    let r2 = &s;
    println!("{} and {}", r1, r2);
    // 新编译器中，r1,r2作用域在这里结束

    let r3 = &mut s;
    println!("{}", r3);
} // 老编译器中，r1、r2、r3作用域在这里结束
  // 新编译器中，r3作用域在这里结束

在老版本的编译器中（Rust 1.31 前），将会报错，因为 r1 和 r2 的作用域在花括号 } 处结束，那么 r3 的借用就会触发 无法同时借用可变和不可变 的规则。

但是在新的编译器中，该代码将顺利通过，因为 引用作用域的结束位置从花括号变成最后一次使用的位置，因此 r1 借用和 r2 借用在 println! 后，就结束了，此时 r3 可以顺利借用到可变引用。

可变引用临时降级为只读引用

还是同样的道理，如果先创建可变引用再创建不可变引用的话可变引用会降级

可以这么理解，要创建不可变引用，首先要保证创建的是不可变引用，所以只有R权限，而他的R和可变引用的W互斥，因为如果同时存在可能能发生数据竞争，所以可变引用被临时降级，当不可变引用灭亡时，可变引用重新获得W权限

曾经的疑惑为什么下面一串代码会报错

fn main() {
	let mut v: Vec<i32> = vec![1,2,3];
	let num : &mut i32 = &mut v[2];
	let num2 : & i32 = &v[2];
	println!("{} {}", num, num2);
}

其实就是Rust借用检测器关注的是借用的来源，如果这么写就相当于有一个可变引用和一个不可变引用在同一作用域，并且他们的根为v[2]

而原来的写法相当于一个可变引用根为v[2],一个不可变引用根为num，这叫做派生借用，也叫子借用

悬垂引用问题

悬垂引用也叫做悬垂指针，意思为指针指向某个值后，这个值被释放掉了，而指针仍然存在，其指向的内存可能不存在任何值或已被其它变量重新使用。在 Rust 中编译器可以确保引用永远也不会变成悬垂状态：当你获取数据的引用后，编译器可以确保数据不会在引用结束前被释放，要想释放数据，必须先停止其引用的使用。

让我们尝试创建一个悬垂引用，Rust 会抛出一个编译时错误： `

fn main() {
    let reference_to_nothing = dangle();
}

fn dangle() -> &String {
    let s = String::from("hello");

    &s
}

这里是错误：

error[E0106]: missing lifetime specifier
 --> src/main.rs:5:16
  |
5 | fn dangle() -> &String {
  |                ^ expected named lifetime parameter
  |
  = help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from
help: consider using the `'static` lifetime
  |
5 | fn dangle() -> &'static String {
  |                ~~~~~~~~

错误信息引用了一个我们还未介绍的功能：生命周期(lifetimes)。不过，即使你不理解生命周期，也可以通过错误信息知道这段代码错误的关键信息：

fn dangle() -> &String { // dangle 返回一个字符串的引用

    let s = String::from("hello"); // s 是一个新字符串

    &s // 返回字符串 s 的引用
} // 这里 s 离开作用域并被丢弃。其内存被释放。
  // 危险！

仔细看看 dangle 代码的每一步到底发生了什么：

fn dangle() -> &String { // dangle 返回一个字符串的引用

    let s = String::from("hello"); // s 是一个新字符串

    &s // 返回字符串 s 的引用
} // 这里 s 离开作用域并被丢弃。其内存被释放。
  // 危险！

因为 s 是在 dangle 函数内创建的，当 dangle 的代码执行完毕后，s 将被释放，但是此时我们又尝试去返回它的引用。这意味着这个引用会指向一个无效的 String，这可不对！

其中一个很好的解决方法是直接返回 String：

fn no_dangle() -> String {
    let s = String::from("hello");

    s
}

这样就没有任何错误了，最终 String 的 所有权被转移给外面的调用者。

借用规则总结

总的来说，借用规则如下：

同一时刻，你只能拥有要么一个可变引用，要么任意多个不可变引用，可变引用和不可变引用不能同时存在
引用必须总是有效的

F权限流动权限

最后再补充一下

流动权限F：在表达式使用输入引用或返回输出引用时需要

F权限在函数体内不会发生变化

如果一个引用被允许在特定表达式中使用（即流动），那么它就具有F权限

我的理解是，流动权限是决定你能不能在不同表达式之间“流动”的一种权限，如果可以那么就具有流动权限，如果不可以就不具有流动权限

第一行的引用是输入引用（也就是函数某一参数的引用）需要流动权限，而他也具有流动权限第二行返回输出引用，也需要流动权限，而他也具有流动权限

这个例子就会报错，因为Rust检查输出引用的返回时只看函数的签名，而这个例子中Rust只看这个函数签名，不知道&String返回的是引用自谁的引用，可能是strings的，也可能是default的，由于这种不确定性，可能会导致未定义的行为，比如下面的例子可能造成UAF,drop为释放Box指向的Heap内存

可见&string[0]和default的输出引用都不具有流动权限

这个例子就是我们上面说的悬挂引用的例子 s_ref输出引用显然不具有流动权限

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://c4e-i-um-github-io.vercel.app/blog/rust%E5%BC%95%E7%94%A8%E5%92%8C%E5%80%9F%E7%94%A8/

Rust所有权

Caelum — Mon, 26 Jan 2026 00:00:00 GMT

rust为了防止出现未定义的行为引入了所有权机制，极大的保障了内存的安全

概述

未定义行为

未定义行为：当执行一段代码时，结果不可预测且未被语言指定的情况

比如数组越界访问，访问释放的堆内存，释放两次堆内存等

Rust的目标

基础目标：确保程序永远不会有未定义的行为次要目标：在编译的时候而不是运行的时候防止未定义行为

所有权

局部变量在stack中

fn main(){
	let n = 5;    #L1
	let y = plus_one(n);    #L3
	println!("The value of y is: {y}");
}

fn plus_one(x: i32) -> i32{
	x + 1        #L2
}

Box存活在Heap中

如果不使用Box,也就是在Stack上分配，会浪费很多空间

fn main(){
	let a = [0;1_000_000];  #L1
	let b = a;     #L2
}

如果使用Box在Heap上分配，Stack上存放的只是指针，指向同一个Heap地址，其他语言一般通过这两个指针都可以访问这个Heap内存，但在Rust中，由于所有权的概念，同时最多只能有一个指针能访问指向的Heap内存。

一开始我们说a具有所有权，到后来let b = a; 我们说，a把所有权转移给了b,此时只能通过b来访问Heap,如果企图通过a来访问，rust编辑器会报错。

let a = Box::new([0;1_000_000]);  #L1
let b = a;   #L2

需要注意的是这种情况

let a = Box::new(15);
let b = a;
let c = Box::new(15);

这种情况是另开了一个Box，不是所有权的转移

Rust内存管理策略

Rust不允许手动内存管理

Stack Frame由Rust自动管理：当调用一个函数时，Rust为调用的函数分配一个Stack Frame。当调用结束时，Rust释放该Stack Frame

假设有一段代码,这段代码会由于手动释放了b所在的Stack内存，然后rust在函数调用结束后又自动释放了b所在的Stack内存，这就出现了Double Free,为了防止这样的未定义行为，Rust不允许手动内存管理

let b = Box::new([0;100]);
free(b);
assert!(b[0] == 0);

Box的真正拥有者来管理对应Box内存的释放

Rust会自动释放Box的Heap内存

Box内存释放原则：如果一个变量拥有（所有）一个Box,当Rust释放该变量的Stack Frame时，Rust会释放该Box的Heap内存。

而使用Box的集合有：Vec,String, &HashMap等

fn main(){
	let first = String::from("Ferris");  #L1
	let full = add_suffix(first); #L4
}

fn add_suffix(mut name: String) -> String{
	#L2
	name.push_str("Jr.");  #L3
	name
}

所有权的转移：first -> name -> full

移动

移动：如果变量x将Heap内存的所有权给了另一个变量y,也就是发生了所有权的转移，这就叫移动，所有权转移后x将不再能访问原来的Heap内存。

克隆

而与移动相对应的就是克隆

避免数据移动的一种方法是使用.clone()方法进行克隆

fn main(){
	let first = String::from("Ferris");
	let fist_clone = first.clone(); #L1
	let full = add_suffix(first_clone); #L2
	println!("{full},originally {first}"); 
}

fn add_suffix(mut name: String) -> String{
	name.push_str("Jr.");
	name
}

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://c4e-i-um-github-io.vercel.app/blog/rust%E6%89%80%E6%9C%89%E6%9D%83%E6%9C%BA%E5%88%B6/

glibc2.39 free总结

Caelum — Sat, 01 Nov 2025 00:00:00 GMT

执行free进入_int_free函数
检查,如果free的地址p大于(uintptr_t) -size或者p不是0x10对齐的，报错"free(): invalid pointer"
如果根据p获取到的size，小于0x20或者size不是8字节对齐，则报错"free(): invalid size"
检查下一个size的prev_inuse位
进入free 进入tcache的流程
1. 根据size获取tc_idx
2. 如果tcache已经初始化，并且tc_idx< mp_.tcache_bins
  1. 获取p指向堆块的头,p原来指的是0x10偏移的位置,这个地址为e
  2. 如果e的key等于tcache_key（一个随机数），就进入检查
    1. 循环遍历该tcache，如果循环计数器cnt大于mp_.tcache_count每个tcache存放堆块的最大个数，报错"free(): too many chunks detected in tcache"
    2. 如果tcache里有堆块没对齐，报错"free(): unaligned chunk detected in tcache 2"
    3. 如果e等于tmp，就是存在两个相同堆块，报错"free(): double free detected in tcache 2"
  3. 如果对应tc_idx的tcache没满，放入tcache，返回
进入free进入fastbin的流程
1. 如果size，小于等于MAX_FAST，并且p的下一个堆块不是top
  1. 检查，如果下一个堆块的size小于0x10或者大于av->system_mem，则报错"free(): invalid next size (fast)"
  2. 让av->have_fastchunks变为true
  3. 根据size获取对应的fastbin的idx
  4. 获取对应fastbin的地址，fb
  5. 获取fastbin最后放入的堆块，为old
  6. 如果释放的和old是同一个堆块，报错"double free or corruption (fasttop)"
  7. 加密释放堆块的fd
  8. 放入fastbin
否则如果不是mmap的堆块，进入_int_free_merge_chunk函数
1. 根据size，获取p的nextchunk
2. 如果p是topchunk，报错"double free or corruption (top)"
3. 如果arena是sbrk分配的，并且nextchunk的地址>av->top加上top的size，报错"double free or corruption (out)"
4. 如果下一个堆块的pre_inuse为0，报错"double free or corruption (!prev)"
5. 如果下一个堆块的size<0x10或者下一个堆块的size>=av->system_mem,报错"free(): invalid next size (normal)"
6. 进行向后合并
  1. 如果p的prev_inuse为0
  2. 获取p的prev_size,为prevsize
  3. 根据prevsize更新p为上一个堆块
  4. 如果现在的p的size，与刚刚保存的prev_size不同，报错"corrupted size vs. prev_size while consolidating"
  5. unlink现在的p
    1. 如果堆块的size位不等于（根据size找到的）下一个堆块的pre_size 报错 "corrupted size vs. prev_size"
    2. 更新fd为p的fd，bk为p的bk
    3. 如果fd->bk!=p或者bk->fd!=p报错"corrupted double-linked list"
    4. 执行fd和bk的unlink过程
      1. fd->bk = bk;
      2. bk->fd = fd;
    5. 如果这个堆块不属于small bin的大小范围,并且这个堆块的fd_nextsize不等于NULL，则会进入unlink largebin的过程
      1. 如果p->fd_nextsize->bk_nextsize != p或者p->bk_nextsize->fd_nextsize != p报错"corrupted double-linked list (not small)"
      2. 如果fd->fd_nextsize == NULL
        
        如果p->fd_nextsize == p
        
        fd->fd_nextsize = fd->bk_nextsize = fd;
        
        否则
        
        fd->fd_nextsize = p->fd_nextsize;
        
        fd->bk_nextsize = p->bk_nextsize;
        
        p->fd_nextsize->bk_nextsize = fd;
        
        p->bk_nextsize->fd_nextsize = fd;
      3. 否则
        
        p->fd_nextsize->bk_nextsize = p->bk_nextsize;
        
        p->bk_nextsize->fd_nextsize = p->fd_nextsize;
如果是mmap的堆块，munmap它

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://c4e-i-um-github-io.vercel.app/blog/glibc239-free%E6%80%BB%E7%BB%93/

glibc2.39 malloc总结

Caelum — Sat, 01 Nov 2025 00:00:00 GMT

malloc首先进入__libc_malloc
在__libc_malloc中首先申请的是tcache bin
1. 如果没初始化tcache就初始化
2. 检查：
  1. 检查请求的大小对应的idx，是不是小于tcache_bins的个数
  2. 检查tcache是否不为空
  3. 检查tcache->counts[tc_idx] 是否大于0
3. 如果检查通过那么就从tcache中取堆块，然后返回给用户，不进入_int_malloc
进入_int_malloc
1. 获取0x10对齐后的大小，后简记为nb
2. 如果av等于NULL，那么sysmalloc一个
3. 如果nb小于等于宏定义中的MAX_FAST,进入fastbin的申请流程
  1. 根据nb，获取对应fastbin的idx
  2. 获取对应idx的fastbin的地址，fb
  3. victim等于*fb,也就是fastbin的最后放入的一个堆块
  4. 如果victim不为NULL
    1. 检查是否0x10对齐，不对齐就报错"malloc(): unaligned fastbin chunk detected 2
    2. 还原已经xor的指针
    3. 如果victim不为NULL（一般都会执行）
      1. 根据victim的size大小获取idx，victim_idx
      2. 如果victim_idx !=idx，就会报错"malloc(): memory corruption (fast)"
      3. 如果tcache已经初始化，并且获取到的tc_idx小于tcache_bins的个数
        
        只要对应tc_idx的tcache没满，fastbin中还有堆块，那么就会让tc_victim等于fastbin最后释放的堆块
        
        如果tc_victim不对齐，报错"malloc(): unaligned fastbin chunk detected 3"
        
        如果是单线程
        
        还原xor的fastbin指针
        
        放入对应tc_idx的tcache（原来的victim也被放入，根据头插法，会被放到所有fastbin堆块最后）
        
        直到不满足条件结束循环
      4. 返回victim
4. 如果nb大于 MAX_FAST，并且属于smallbin的范围
  1. 获取nb对应smallbin的idx
  2. 获取对应idx的samllbin的地址，bin
  3. 如果smallbin不为空，同时
    1. 让victim等于smallbin尾部的堆块，也就是最先放入的堆块
    2. 获取victim的bk指向的堆块，bck
    3. 如果bck的fd指针不指向victim，报错"malloc(): smallbin double linked list corrupted"
    4. 为下一个堆块设置pre_inuse标志位
    5. 让bin的bk连上bck，让后面的fd连上bin，也就是victim从smallbin中拿出
    6. 根据nb获取对应的tcache的tc_idx
    7. 如果tcache已经初始化，并且tc_idx小于tcache_bins（其实就是在tcache的范围内，tcache_bins可以理解为管控tcache的大小范围的）
      1. 只要tcachebin没满并且smallbin不为空，不断取出循环放入tcache（同样根据头插法victim也会被放入tcache，并且是最后）
      2. 直到不满足条件，循环结束
    8. 返回用户堆块
5. 如果上述条件不满足
  1. 根据nb，获取largebin对应的idx
  2. 如果fastbin不为空
    1. 触发malloc_consolidate，合并fastbin放入unsorted bin
6. 初始化一些tcache的东西，为下面进入unsorted bin大循环做准备
  1. 根据nb获取对应tc_idx
  2. 如果tcache已经初始化，并且tc_idx小于tcache_bins
  3. 让tcache_nb=nb;
  4. 让return_cached = 0;标志位，标记是否直接从 tcache 返回内存
  5. 让tcache_unsorted_count = 0; 用于统计本次 _int_malloc 从 unsorted bin 移入 tcache 的 chunk 数量
7. 进入unsorted bin大循环，最多循环1000次
  1. 初始化计数器iters = 0
  2. 只要unsorted bin不为空
    1. victim等于unsorted bin最后放入的堆块
    2. bck = victim的bk指向的堆块
    3. 获取victim的size，size
    4. 根据size，获取下一个堆块的地址，next
    5. 然后是一大堆检查
      1. 如果该堆块victim的size<0x10或者size>arena的大小就会报错"malloc(): invalid size (unsorted)"
      2. 如果下一个堆块next的size<0x10或者size>arena的大小就会报错"malloc(): invalid next size (unsorted)"
      3. 如果next的prev_size不等于victim的size就报错"malloc(): mismatching next->prev_size (unsorted)"
      4. 如果bck的fd不等于victim，或者victim的fd不等于unsorted bin就报错"malloc(): unsorted double linked list corrupted"
      5. 如果next的prev_inuse为1，就报错"malloc(): invalid next->prev_inuse (unsorted)"
    6. 如果这个堆块属于unsorted bin中smallbin的范围，并且unsorted bin只有这一个堆块，并且这个堆块还是上一次切割剩下的堆块，也就是last remainder，并且size>nb+0x20
      1. 再次切割这个堆块
        
        remainder_size = size - nb;然后remainder = chunk_at_offset (victim, nb);此时victim等于切割下来的堆块
        
        保存remainder到last_remainder中，last_remainder=remainder
        
        如果切割后还属于smallbin的范围，把fd_nextsize和bk_nextsize置为NULL
        
        给victim设置头部信息，给remainder设置头部信息，给remainder的下一个堆块写入prev_size
        
        进行检查
        
        检查victim是否是mmap的
        
        检查arenna的地址
        
        检查victim是否对齐
        
        检查victim是否size>=0x20
        
        检查victim的大小是否≥nb
        
        检查victim的大小是否 <nb+0x20
        
        返回用户堆块
    7. 如果不切割，把victim拿出，unsorted_chunks (av)->bk = bck; bck->fd = unsorted_chunks (av);
    8. 如果victim的size等于nb
      1. 给victim的下一个堆块设置prev_inuse位
      2. 如果nb>0，并且对应idx的tcache还没满
        
        把victim放入对应idx的tcache，然后继续循环取和放入，直到tcache满或者unsorted bin为空了
        
        让return_cached = 1，标志一会要从tcache bin返回堆块
        
        continue直接跳出while循环，跳到如果return_cached = 1，从tcache_get获取
      3. 否则
        
        检查是否是mmap的如果是不进行接下来的检查，检查arenna的地址，检查是否对齐，检查是否size>=0x20, 检查victim的大小是否>=用户申请的大小，检查victim的大小是否<用户申请的大小+0x20
        
        返回victim给用户
    9. 否则说明unsorted bin中没有合适的，把unsorted bin中的堆块放入对应大小的bin中，接下来就是这一过程，这个过程是沿着unsorted bin中的fd链的，如果第一个是0x420，第二个是0x430，第三个是0x410，那么malloc 0x430以后，0x420的堆块会进入large bin，0x430的堆块会被取出返回，0x410的堆块会呆在unsorted bin，参考上面victim的size等于nb的情况
    10. 如果victim的size属于smallbin的范围
      1. 根据size，获取对应smallbin的下标，victim_index
      2. bck等于对应victim的idx的smallbin地址
      3. fwd为从smallbin最后放入的堆块
    11. 如果victim的size属于largebin的范围(下面是更新fd_nextsize和bk_nextsize) 1. 根据size，获取对应largebin的下标，victim_index 2. bck等于对应victim的idx的largebin地址 3. fwd为从largebin最后放入的堆块（即largebin中最大 chunk ）
      1. 如果idx对应的largebin不为空
        
        将victim的size的prev_inuse位设置为1
        
        如果victim的size<对应largebin放入的最先一个堆块（当前large bin中最小的chunk时），那么认定victim更小，因此需要将它插入到 Large Bin 的末尾（即最小 chunk 之后），把victim找到合适位置放入largebin并更新十字链表的指针
        
        更新fwd等于largebin的地址
        
        bck为该largebin最先的第二个放入的堆块当前 Large Bin 中第二大的 chunk
        
        让victim的fd_nextsize指向该largebin最后放入的堆块（当前 Large Bin 中最大的 chunk），这里是循环链表的缘故，victim最小了再小就指向最大的了
        
        让victim的bk_nextsize指向该largebin最后放入的堆块（当前 Large Bin 中最大的 chunk）的bk_nextsize
        
        该largebin最后放入的堆块（当前 Large Bin 中最大的 chunk）的bk_nextsize指向victim
        
        否则
        
        只要size小于即fwd（largebin中最大 chunk ），同时大于等于该large bin中最小的chunk
        
        一直去寻找更小的堆块，
        
        更新fwd=fwd->fd_nextsize
        
        直到找到刚好小于等于victim size的chunk,此时fwd为这个chunk
        
        如果victim的size正好等于这个chunk的size
        
        更新fwd 等于 fwd的fd，准备把victim放到fwd的fd位置
        
        否则
        
        则说明victim要放到fwd的bk_nextsize位置
        
        victim的fd_nextsize指针指向这个chunk
        
        victim的bk_nextsize指针指向这个chunk的bk_nextsize
        
        检查，如果这个chunk的bk_nextsize的fd_nextsize不是这个堆块报错"malloc(): largebin double linked list corrupted (nextsize)"
        
        这个堆块（fwd）的bk_nextsize指向victim
        
        更新bck为fwd（此时的堆块）的bk指向的堆块
        
        检查，如果bck的fd不等于fwd报错"malloc(): largebin double linked list corrupted (bk)"
      2. 否则
        
        让victim的fd_nextsize和bk_nextsize都指向victim
    12. victim->bk = bck; victim->fd = fwd; fwd->bk = victim; bck->fd = victim，victim连接fwd和bck，它们再连接victim
  3. 让tcache_unsorted_count++ tcache_unsorted_count代表tcacge中unsorted bin数量
  4. 如果return_cached = 1并且mp_.tcache_unsorted_limit （是 tcache中unsorted bin的限制值通常为0）> 0并且tcache_unsorted_count大于mp_.tcache_unsorted_limit
    1. 直接从tcache中拿堆块，并返回用户堆块
  5. 如果循环大于1000次，退出循环
  6. 如果return_cached = 1，从tcache_get获取，并返回
8. 接下来准备从largebin中拿
9. 如果nb属于large bin的范围
  1. 获取对应large bin的地址，bin
  2. 如果largebin不为空，让victim变为largebin最后放入的堆块并且如果victim的size大于等于nb（意味着肯定是可以被分配的）
    1. 让victim变为large bin中最小的
    2. 只要victim的size小于nb
      1. 就去寻找更大的
    3. 直到victim的size大于等于nb
    4. 如果victim不是largebin最小的堆块并且victim的size等于victim->fd
      1. 选择切割后放入(victim->fd)的而不是先放入的(victim)
    5. 切割，remainder_size = size - nb
    6. 让victim脱链unlink
    7. 如果切割后剩下的小于 0x20
      1. 给下一个堆块设置prev_inuse位
    8. 否则
      1. 更新remainder为切割后的堆块，victim为切割下来的堆块
      2. 获取unsorted_chunks的地址，bck
      3. 更新fwd为unsorted bin中最后放入的堆块
  3. 检查，如果fwd的bk不指向bck，报错"malloc(): corrupted unsorted chunks"
    1. 让切割剩下的remainder放入unsorted bin的头部
    2. 如果remainder属于large bin的范围
      1. 把fd_nextsize和bk_nextsize设置为NULL
    3. 为victim设置头部信息，为remainder设置头部信息，为remainder的下一个堆块设置prev_size
    4. 常规检查
    5. 返回用户堆块
10. 位图再次搜索，如果有可用堆块，返回用户堆块
11. 如果上述都没能返回用户堆块，使用top chunk
  1. victim = av->top ,获取top chunk的地址
  2. 根据victim获取size
  3. 检查，如果size>av->system_mem，报错"malloc(): corrupted top size"
  4. 如果size >=nb + 0x20
    1. 切割top chunk
    2. 设置victim的头部信息，设置remainder的头部信息，为remainder的下一个堆块设置prev_size
    3. 返回用户堆块
  5. 否则，查看fastbin是否存在堆块
    1. 若存在进行malloc_consolidate，让fastbin堆块合并放入unsorted bin
    2. 如果nb属于smallbin的范围，获取对应smallbin的idx
    3. 如果nb属于largebin的范围，获取对应larrgebin的idx
  6. 否则
    1. 就是前面都不能找到合适堆块
    2. 直接sysmalloc
    3. 返回用户堆块

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://c4e-i-um-github-io.vercel.app/blog/glibc239-malloc%E6%80%BB%E7%BB%93/

浅析tcache bin的前世今生

Caelum — Mon, 01 Sep 2025 00:00:00 GMT

前言

本文重点关注两个方面，tcache的取和放，意在帮助自己更加深入理解各个版本的tcache的行为，提高ctf做题能力。

tcahe的分水岭

2.26 tcache出现 2.28 _int_free引入key防止双重释放 2.32 PROTECT_PTR的引入 2.34 使得key随机生成，而非tcache_perthread_struct的地址

tcache机制的演变以及对应的绕过手法

glibc 2.26-2.27

tcache相关的宏定义

#if USE_TCACHE
/* We want 64 entries.  This is an arbitrary limit, which tunables can reduce.  */
# define TCACHE_MAX_BINS		64
# define MAX_TCACHE_SIZE	tidx2usize (TCACHE_MAX_BINS-1)

/* Only used to pre-fill the tunables.  */
# define tidx2usize(idx)	(((size_t) idx) * MALLOC_ALIGNMENT + MINSIZE - SIZE_SZ)

/* When "x" is from chunksize().  */
# define csize2tidx(x) (((x) - MINSIZE + MALLOC_ALIGNMENT - 1) / MALLOC_ALIGNMENT)
/* When "x" is a user-provided size.  */
# define usize2tidx(x) csize2tidx (request2size (x))

/* With rounding and alignment, the bins are...
   idx 0   bytes 0..24 (64-bit) or 0..12 (32-bit)
   idx 1   bytes 25..40 or 13..20
   idx 2   bytes 41..56 or 21..28
   etc.  */

/* This is another arbitrary limit, which tunables can change.  Each
   tcache bin will hold at most this number of chunks.  */
# define TCACHE_FILL_COUNT 7
#endif

tcache相关的结构体

malloc_par里有与tcache相关的内容

struct malloc_par
{
  /* Tunable parameters */
  unsigned long trim_threshold;
  INTERNAL_SIZE_T top_pad;
  INTERNAL_SIZE_T mmap_threshold;
  INTERNAL_SIZE_T arena_test;
  INTERNAL_SIZE_T arena_max;

  /* Memory map support */
  int n_mmaps;
  int n_mmaps_max;
  int max_n_mmaps;
  /* the mmap_threshold is dynamic, until the user sets
     it manually, at which point we need to disable any
     dynamic behavior. */
  int no_dyn_threshold;

  /* Statistics */
  INTERNAL_SIZE_T mmapped_mem;
  INTERNAL_SIZE_T max_mmapped_mem;

  /* First address handed out by MORECORE/sbrk.  */
  char *sbrk_base;

//下面是tcache相关的内容
---------------------------------------------------------------------


#if USE_TCACHE
  /* Maximum number of buckets to use.  */
  size_t tcache_bins;
  size_t tcache_max_bytes;
  /* Maximum number of chunks in each bucket.  */
  size_t tcache_count;
  /* Maximum number of chunks to remove from the unsorted list, which
     aren't used to prefill the cache.  */
  size_t tcache_unsorted_limit;
#endif
};

可以看到这里定义了malloc_par结构体名为mp_


static struct malloc_par mp_ =
{
  .top_pad = DEFAULT_TOP_PAD,
  .n_mmaps_max = DEFAULT_MMAP_MAX,
  .mmap_threshold = DEFAULT_MMAP_THRESHOLD,
  .trim_threshold = DEFAULT_TRIM_THRESHOLD,
#define NARENAS_FROM_NCORES(n) ((n) * (sizeof (long) == 4 ? 2 : 8))
  .arena_test = NARENAS_FROM_NCORES (1)
#if USE_TCACHE
  ,
  .tcache_count = TCACHE_FILL_COUNT,
  .tcache_bins = TCACHE_MAX_BINS,
  .tcache_max_bytes = tidx2usize (TCACHE_MAX_BINS-1),
  .tcache_unsorted_limit = 0 /* No limit.  */
#endif

tcache_entry

#if USE_TCACHE

/* We overlay this structure on the user-data portion of a chunk when
   the chunk is stored in the per-thread cache.  */
typedef struct tcache_entry
{
  struct tcache_entry *next;
} tcache_entry;

tcache_perthread_struct

typedef struct tcache_perthread_struct
{
  char counts[TCACHE_MAX_BINS];
  tcache_entry *entries[TCACHE_MAX_BINS];
} tcache_perthread_struct;

MAX_TCACHE_COUNT以及一些其他的东西

#define MAX_TCACHE_COUNT 127	/* Maximum value of counts[] entries.  */

static __thread bool tcache_shutting_down = false;
static __thread tcache_perthread_struct *tcache = NULL;

tcache主要行为

放入tcache bin的时候

/* Caller must ensure that we know tc_idx is valid and there's room
   for more chunks.  */
tatic __always_inline void
tcache_put (mchunkptr chunk, size_t tc_idx)
{
  tcache_entry *e = (tcache_entry *) chunk2mem (chunk);
  assert (tc_idx < TCACHE_MAX_BINS);
  e->next = tcache->entries[tc_idx];   //这里采用的是头插法
  tcache->entries[tc_idx] = e;
  ++(tcache->counts[tc_idx]);
}

申请的时候

static __always_inline void *
tcache_get (size_t tc_idx)
{
  tcache_entry *e = tcache->entries[tc_idx];
  assert (tc_idx < TCACHE_MAX_BINS);
  assert (tcache->entries[tc_idx] > 0);
  tcache->entries[tc_idx] = e->next;
  --(tcache->counts[tc_idx]);
  return (void *) e;
}

总结

这个时期的tcache存在着很大的漏洞，几乎没有防护，也为后来打patch埋下基础

glibc 2.28-2.33

tcache 相关定义

这里只展示不同之处

tcache_entry

可以看到相比于上一个阶段，这里多了个key指针，类型是struct tcache_perthread_struct *,指向的是当前线程的struct tcache_entry结构体变量，用于检测是否出现了double free

#if USE_TCACHE

/* We overlay this structure on the user-data portion of a chunk when
   the chunk is stored in the per-thread cache.  */
typedef struct tcache_entry
{
  struct tcache_entry *next;
  /* This field exists to detect double frees.  */
  struct tcache_perthread_struct *key;
} tcache_entry;

tcache_perthread_struct

可以看到原来的char counts[TCACHE_MAX_BINS]变成了uint16_t类型，也许是预防了一手类型混淆，劫持 tcache_perthread_struct结构体的时候就需要注意了

typedef struct tcache_perthread_struct
{
  uint16_t counts[TCACHE_MAX_BINS];  
  tcache_entry *entries[TCACHE_MAX_BINS];
} tcache_perthread_struct;

tcache的行为

放入tcache bin

可以看到多了个PROTECT_PTR，相关宏定义,也就是放入时候的堆块的 e的next指针的地址>>12 与 tcache->entries\[tc_idx\] 异或，也就是和当前堆块所属下标的tcache->entries指向的第一个堆块，根据头插法，其实就是和要释放堆块同属一个entries的上一个堆块异或（其实就是next指针的值）简单来说就是e的next指针的取地址>>12和 e的next指针的值异或了

不过当第一个堆块放入的时候tcache->entries指向的第一个堆块为NULL, 也就是0,相当于没有xor,可以用来泄露堆地址

#define PROTECT_PTR(pos, ptr) \
  ((__typeof (ptr)) ((((size_t) pos) >> 12) ^ ((size_t) ptr)))

static __always_inline void
tcache_put (mchunkptr chunk, size_t tc_idx)
{
  tcache_entry *e = (tcache_entry *) chunk2mem (chunk);

  /* Mark this chunk as "in the tcache" so the test in _int_free will
     detect a double free.  */
  e->key = tcache;

  e->next = PROTECT_PTR (&e->next, tcache->entries[tc_idx]);
  tcache->entries[tc_idx] = e;
  ++(tcache->counts[tc_idx]);
}
/* Caller must ensure that we know tc_idx is valid and there's
   available chunks to remove.  */

申请

可以看见多了个REVEAL_PTR，其实根据xor的性质，直接还原了

#define REVEAL_PTR(ptr)  PROTECT_PTR (&ptr, ptr)

static __always_inline void *
tcache_get (size_t tc_idx)
{
  tcache_entry *e = tcache->entries[tc_idx];
  if (__glibc_unlikely (!aligned_OK (e)))
    malloc_printerr ("malloc(): unaligned tcache chunk detected");
  tcache->entries[tc_idx] = REVEAL_PTR (e->next);
  --(tcache->counts[tc_idx]);
  e->key = NULL;
  return (void *) e;
}

释放的时候

可以看到 if (__glibc_unlikely (e->key == tcache)) 如果相等就会遍历处于相同下标 entrys的所有chunk, 来检查要释放的堆块是否已经存在，是否double free

static void
_int_free (mstate av, mchunkptr p, int have_lock)
{
  INTERNAL_SIZE_T size;        /* its size */
  mfastbinptr *fb;             /* associated fastbin */
  mchunkptr nextchunk;         /* next contiguous chunk */
  INTERNAL_SIZE_T nextsize;    /* its size */
  int nextinuse;               /* true if nextchunk is used */
  INTERNAL_SIZE_T prevsize;    /* size of previous contiguous chunk */
  mchunkptr bck;               /* misc temp for linking */
  mchunkptr fwd;               /* misc temp for linking */

  size = chunksize (p);

  /* Little security check which won't hurt performance: the
     allocator never wrapps around at the end of the address space.
     Therefore we can exclude some size values which might appear
     here by accident or by "design" from some intruder.  */
  if (__builtin_expect ((uintptr_t) p > (uintptr_t) -size, 0)
      || __builtin_expect (misaligned_chunk (p), 0))
    malloc_printerr ("free(): invalid pointer");
  /* We know that each chunk is at least MINSIZE bytes in size or a
     multiple of MALLOC_ALIGNMENT.  */
  if (__glibc_unlikely (size < MINSIZE || !aligned_OK (size)))
    malloc_printerr ("free(): invalid size");

  check_inuse_chunk(av, p);

#if USE_TCACHE
  {
    size_t tc_idx = csize2tidx (size);
    if (tcache != NULL && tc_idx < mp_.tcache_bins)
      {
	/* Check to see if it's already in the tcache.  */
	tcache_entry *e = (tcache_entry *) chunk2mem (p);

	/* This test succeeds on double free.  However, we don't 100%
	   trust it (it also matches random payload data at a 1 in
	   2^<size_t> chance), so verify it's not an unlikely
	   coincidence before aborting.  */
	if (__glibc_unlikely (e->key == tcache))
	  {
	    tcache_entry *tmp;
	    size_t cnt = 0;
	    LIBC_PROBE (memory_tcache_double_free, 2, e, tc_idx);
	    for (tmp = tcache->entries[tc_idx];
		 tmp;
		 tmp = REVEAL_PTR (tmp->next), ++cnt)
	      {
		if (cnt >= mp_.tcache_count)
		  malloc_printerr ("free(): too many chunks detected in tcache");
		if (__glibc_unlikely (!aligned_OK (tmp)))
		  malloc_printerr ("free(): unaligned chunk detected in tcache 2");
		if (tmp == e)
		  malloc_printerr ("free(): double free detected in tcache 2");
		/* If we get here, it was a coincidence.  We've wasted a
		   few cycles, but don't abort.  */
	      }
	  }

	if (tcache->counts[tc_idx] < mp_.tcache_count)
	  {
	    tcache_put (p, tc_idx);
	    return;
	  }
      }
  }
#endif

glibc2.34--至今

主要不同只有一个地方，原来e->key=tcache现在e->key=tcache_key

static __always_inline void
tcache_put (mchunkptr chunk, size_t tc_idx)
{
  tcache_entry *e = (tcache_entry *) chunk2mem (chunk);

  /* Mark this chunk as "in the tcache" so the test in _int_free will
     detect a double free.  */
  e->key = tcache_key;

  e->next = PROTECT_PTR (&e->next, tcache->entries[tc_idx]);
  tcache->entries[tc_idx] = e;
  ++(tcache->counts[tc_idx]);
}

那么tcache_key哪来的呢

static void
tcache_key_initialize (void)
{
  if (__getrandom (&tcache_key, sizeof(tcache_key), GRND_NONBLOCK)
      != sizeof (tcache_key))
    {
      tcache_key = random_bits ();
#if __WORDSIZE == 64
      tcache_key = (tcache_key << 32) | random_bits ();
#endif
    }
}

实际上是tcache_key变为了一个随机数

释放的时候

可以看到if(e->key == tcache)变为了 if(e->key == tcache_key),但我们只要能获取key一样可以绕过检测

static void
_int_free (mstate av, mchunkptr p, int have_lock)
{
  INTERNAL_SIZE_T size;        /* its size */
  mfastbinptr *fb;             /* associated fastbin */
  mchunkptr nextchunk;         /* next contiguous chunk */
  INTERNAL_SIZE_T nextsize;    /* its size */
  int nextinuse;               /* true if nextchunk is used */
  INTERNAL_SIZE_T prevsize;    /* size of previous contiguous chunk */
  mchunkptr bck;               /* misc temp for linking */
  mchunkptr fwd;               /* misc temp for linking */

  size = chunksize (p);

  /* Little security check which won't hurt performance: the
     allocator never wrapps around at the end of the address space.
     Therefore we can exclude some size values which might appear
     here by accident or by "design" from some intruder.  */
  if (__builtin_expect ((uintptr_t) p > (uintptr_t) -size, 0)
      || __builtin_expect (misaligned_chunk (p), 0))
    malloc_printerr ("free(): invalid pointer");
  /* We know that each chunk is at least MINSIZE bytes in size or a
     multiple of MALLOC_ALIGNMENT.  */
  if (__glibc_unlikely (size < MINSIZE || !aligned_OK (size)))
    malloc_printerr ("free(): invalid size");

  check_inuse_chunk(av, p);

#if USE_TCACHE
  {
    size_t tc_idx = csize2tidx (size);
    if (tcache != NULL && tc_idx < mp_.tcache_bins)
      {
	/* Check to see if it's already in the tcache.  */
	tcache_entry *e = (tcache_entry *) chunk2mem (p);

	/* This test succeeds on double free.  However, we don't 100%
	   trust it (it also matches random payload data at a 1 in
	   2^<size_t> chance), so verify it's not an unlikely
	   coincidence before aborting.  */
	if (__glibc_unlikely (e->key == tcache_key))
	  {
	    tcache_entry *tmp;
	    size_t cnt = 0;
	    LIBC_PROBE (memory_tcache_double_free, 2, e, tc_idx);
	    for (tmp = tcache->entries[tc_idx];
		 tmp;
		 tmp = REVEAL_PTR (tmp->next), ++cnt)
	      {
		if (cnt >= mp_.tcache_count)
		  malloc_printerr ("free(): too many chunks detected in tcache");
		if (__glibc_unlikely (!aligned_OK (tmp)))
		  malloc_printerr ("free(): unaligned chunk detected in tcache 2");
		if (tmp == e)
		  malloc_printerr ("free(): double free detected in tcache 2");
		/* If we get here, it was a coincidence.  We've wasted a
		   few cycles, but don't abort.  */
	      }
	  }

	if (tcache->counts[tc_idx] < mp_.tcache_count)
	  {
	    tcache_put (p, tc_idx);
	    return;
	  }
      }
  }
#endif

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://c4e-i-um-github-io.vercel.app/blog/%E6%B5%85%E6%9E%90tcache-bin%E7%9A%84%E5%89%8D%E4%B8%96%E4%BB%8A%E7%94%9F/

堆泄漏技巧

Caelum — Mon, 31 Mar 2025 00:00:00 GMT

有UAF

有UAF，基本就不用说了，随便一种就行:

利用tcache/fastbin
1. 利用释放后的tcache next指针>>12，可获取堆地址
利用unsorted bin
1. 利用释放后的unsorted bin的fd和bk , 可获取libc地址
2. 释放两个堆块(这两个堆块不连续，否则会合并)，让他们进入unsorted bin，可同时获取libc和堆地址，前提是输出不被截断

无UAF,但是输出不截断

主要是利用了堆块申请出来不会主动清空fd和bk 还有fd_nextsize和bk_nextsize

利用unsorted bin

add(0,0x418)
add(1,0x10)
add(2,0x4f8)
free(0)
free(2)
add(3,0x418)
show(3)   //不截断输出

利用效果也是这样 2. 利用large bin

add(0,0x418)
add(1,0x10)
free(0)
add(2,0x4f8)
add(3,0x418)
show(3)    //不截断输出

This rendering was automatically generated by Frosti Feed and may have formatting issues. For the best experience, please visit: https://c4e-i-um-github-io.vercel.app/blog/%E5%A0%86%E6%B3%84%E6%BC%8F%E6%8A%80%E5%B7%A7/