- 28 7月, 2022 1 次提交
-
-
由 Far 提交于
1. 指针混淆: 对空闲chunk的双向链表指针next、prev进行混淆。具体为将该指针与一个key做异或操作。 不同的bin拥有不同的key,key通过随机数生成器生成。 2. safe unlink: 在unbin操作时校验双向链表的有效性,即检查双向链表中前一项和后一项的指向当前chunk 的指针是否正常,否则终止进程。 这两个功能均可通过MALLOC_FREELIST_HARDENED宏开关 这个宏可以通过编译框架直接开关(在编译命令后增加 --gn-args "musl_secure_level=1"打开) Change-Id: I05fd4404aeebcb396c8471f181a30305fb9dbe74 Signed-off-by: NFar <yesiyuan2@huawei.com>
-
- 11 3月, 2021 1 次提交
-
-
由 mamingshuai 提交于
-
- 09 9月, 2020 1 次提交
-
-
由 wenjun 提交于
-
- 13 9月, 2018 5 次提交
-
-
由 Rich Felker 提交于
libc.h was intended to be a header for access to global libc state and related interfaces, but ended up included all over the place because it was the way to get the weak_alias macro. most of the inclusions removed here are places where weak_alias was needed. a few were recently introduced for hidden. some go all the way back to when libc.h defined CANCELPT_BEGIN and _END, and all (wrongly implemented) cancellation points had to include it. remaining spurious users are mostly callers of the LOCK/UNLOCK macros and files that use the LFS64 macro to define the awful *64 aliases. in a few places, new inclusion of libc.h is added because several internal headers no longer implicitly include libc.h. declarations for __lockfile and __unlockfile are moved from libc.h to stdio_impl.h so that the latter does not need libc.h. putting them in libc.h made no sense at all, since the macros in stdio_impl.h are needed to use them correctly anyway.
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
commits leading up to this one have moved the vast majority of libc-internal interface declarations to appropriate internal headers, allowing them to be type-checked and setting the stage to limit their visibility. the ones that have not yet been moved are mostly namespace-protected aliases for standard/public interfaces, which exist to facilitate implementing plain C functions in terms of POSIX functionality, or C or POSIX functionality in terms of extensions that are not standardized. some don't quite fit this description, but are "internally public" interfacs between subsystems of libc. rather than create a number of newly-named headers to declare these functions, and having to add explicit include directives for them to every source file where they're needed, I have introduced a method of wrapping the corresponding public headers. parallel to the public headers in $(srcdir)/include, we now have wrappers in $(srcdir)/src/include that come earlier in the include path order. they include the public header they're wrapping, then add declarations for namespace-protected versions of the same interfaces and any "internally public" interfaces for the subsystem they correspond to. along these lines, the wrapper for features.h is now responsible for the definition of the hidden, weak, and weak_alias macros. this means source files will no longer need to include any special headers to access these features. over time, it is my expectation that the scope of what is "internally public" will expand, reducing the number of source files which need to include *_impl.h and related headers down to those which are actually implementing the corresponding subsystems, not just using them.
-
由 Rich Felker 提交于
the malloc-implementation-private header is the only right place for this, because, being in the reserved namespace, __memalign is not interposable and thus not valid to use anywhere else. anything outside of the malloc implementation must call an appropriate-namespace public function (aligned_alloc or posix_memalign).
-
由 Rich Felker 提交于
-
- 06 9月, 2018 1 次提交
-
-
由 Rich Felker 提交于
this cleans up what had become widespread direct inline use of "GNU C" style attributes directly in the source, and lowers the barrier to increased use of hidden visibility, which will be useful to recovering some of the efficiency lost when the protected visibility hack was dropped in commit dc2f368e, especially on archs where the PLT ABI is costly.
-
- 20 4月, 2018 3 次提交
-
-
由 Rich Felker 提交于
commit 618b18c7 removed the previous detection and hardening since it was incorrect. commit 72141795 already handled all that remained for hardening the static-linked case. in the dynamic-linked case, have the dynamic linker check whether malloc was replaced and make that information available. with these changes, the properties documented in commit c9f415d7 are restored: if calloc is not provided, it will behave as malloc+memset, and any of the memalign-family functions not provided will fail with ENOMEM.
-
由 Rich Felker 提交于
this change serves multiple purposes: 1. it ensures that static linking of memalign-family functions will pull in the system malloc implementation, thereby causing link errors if an attempt is made to link the system memalign functions with a replacement malloc (incomplete allocator replacement). 2. it eliminates calls to free that are unpaired with allocations, which are confusing when setting breakpoints or tracing execution. as a bonus, making __bin_chunk external may discourage aggressive and unnecessary inlining of it.
-
由 Rich Felker 提交于
-