en Copyright 2015 Java http://172.16.0.5:8080/history/llvm-project-15.0.7/compiler-rt/lib/scudo/scudo_new_delete.cpp#2946cd70 Update the file headers across all of the LLVM projects in the monorepoto reflect the new license.We understand that people may be surprised that we're moving the headerentirely to discuss the new license. We checked this carefully with theFoundation's lawyer and we believe this is the correct approach.Essentially, all code in the project is now made available by the LLVMproject under our new license, so you will see that the license headersinclude that license only. Some of our contributors have contributedcode under our old license, and accordingly, we have retained a copy ofour old license notice in the top-level files in each project andrepository.llvm-svn: 351636 List of files: /llvm-project-15.0.7/compiler-rt/lib/scudo/scudo_new_delete.cpp Sat, 19 Jan 2019 08:50:56 +0000 Chandler Carruth <chandlerc@gmail.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/compiler-rt/lib/scudo/scudo_new_delete.cpp#4adf2450 [scudo] Add verbose failures in place of CHECK(0)Summary:The current `FailureHandler` mechanism was fairly opaque with regard to thefailure reason due to using `CHECK(0)`. Scudo is a bit different from the otherSanitizers as it prefers to avoid spurious processing in its failure path. Sowe just `dieWithMessage` using a somewhat explicit string.Adapted the tests for the new strings.While this takes care of the `OnBadRequest` & `OnOOM` failures, the next stepis probably to migrate the other Scudo failures in the same failes (headercorruption, invalid state and so on).Reviewers: alekseyshlReviewed By: alekseyshlSubscribers: filcab, mgorny, delcypher, #sanitizers, llvm-commitsDifferential Revision: https://reviews.llvm.org/D48199llvm-svn: 334843 List of files: /llvm-project-15.0.7/compiler-rt/lib/scudo/scudo_new_delete.cpp Fri, 15 Jun 2018 16:45:19 +0000 Kostya Kortchinsky <kostyak@google.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/compiler-rt/lib/scudo/scudo_new_delete.cpp#76969eaf [scudo] Add C++17 aligned new/delete operators supportSummary:This CL adds support for aligned new/delete operators (C++17). Currently wedo not support alignment inconsistency detection on deallocation, as thisrequires a header change, but the APIs are introduced and are functional.Add a smoke test for the aligned version of the operators.Reviewers: alekseyshlReviewed By: alekseyshlSubscribers: delcypher, #sanitizers, llvm-commitsDifferential Revision: https://reviews.llvm.org/D48031llvm-svn: 334505 List of files: /llvm-project-15.0.7/compiler-rt/lib/scudo/scudo_new_delete.cpp Tue, 12 Jun 2018 14:42:40 +0000 Kostya Kortchinsky <kostyak@google.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/compiler-rt/lib/scudo/scudo_new_delete.cpp#43917720 [scudo] Application & platform compatibility changesSummary:This patch changes a few (small) things around for compatibility purposes forthe current Android & Fuchsia work:- `realloc`'ing some memory that was not allocated with `malloc`, `calloc` or `realloc`, while UB according to http://pubs.opengroup.org/onlinepubs/009695399/functions/realloc.html is more common that one would think. We now only check this if `DeallocationTypeMismatch` is set; change the "mismatch" error messages to be more homogeneous;- some sketchily written but widely used libraries expect a call to `realloc` to copy the usable size of the old chunk to the new one instead of the requested size. We have to begrundingly abide by this de-facto standard. This doesn't seem to impact security either way, unless someone comes up with something we didn't think about;- the CRC32 intrinsics for 64-bit take a 64-bit first argument. This is misleading as the upper 32 bits end up being ignored. This was also raising `-Wconversion` errors. Change things to take a `u32` as first argument. This also means we were (and are) only using 32 bits of the Cookie - not a big thing, but worth mentioning.- Includes-wise: prefer `stddef.h` to `cstddef`, move `scudo_flags.h` where it is actually needed.- Add tests for the memalign-realloc case, and the realloc-usable-size one.(Edited typos)Reviewers: alekseyshlReviewed By: alekseyshlSubscribers: llvm-commitsDifferential Revision: https://reviews.llvm.org/D36754llvm-svn: 311018 List of files: /llvm-project-15.0.7/compiler-rt/lib/scudo/scudo_new_delete.cpp Wed, 16 Aug 2017 16:40:48 +0000 Kostya Kortchinsky <kostyak@google.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/compiler-rt/lib/scudo/scudo_new_delete.cpp#4b450685 [Sanitizers] Operator new() interceptors always die on allocation errorSummary:Operator new interceptors behavior is now controlled by their nothrowproperty as well as by allocator_may_return_null flag value:- allocator_may_return_null=* + new() - die on allocation error- allocator_may_return_null=0 + new(nothrow) - die on allocation error- allocator_may_return_null=1 + new(nothrow) - return nullIdeally new() should throw std::bad_alloc exception, but that is nottrivial to achieve, hence TODO.Reviewers: eugenisSubscribers: kubamracek, llvm-commitsDifferential Revision: https://reviews.llvm.org/D34731llvm-svn: 306604 List of files: /llvm-project-15.0.7/compiler-rt/lib/scudo/scudo_new_delete.cpp Wed, 28 Jun 2017 21:58:57 +0000 Alex Shlyapnikov <alekseys@google.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/compiler-rt/lib/scudo/scudo_new_delete.cpp#1148dc52 [scudo] 32-bit and hardware agnostic supportSummary:This update introduces i386 support for the Scudo Hardened Allocator, andoffers software alternatives for functions that used to require hardwarespecific instruction sets. This should make porting to new architectureseasier.Among the changes:- The chunk header has been changed to accomodate the size limitations encountered on 32-bit architectures. We now fit everything in 64-bit. This was achieved by storing the amount of unused bytes in an allocation rather than the size itself, as one can be deduced from the other with the help of the GetActuallyAllocatedSize function. As it turns out, this header can be used for both 64 and 32 bit, and as such we dropped the requirement for the 128-bit compare and exchange instruction support (cmpxchg16b).- Add 32-bit support for the checksum and the PRNG functions: if the SSE 4.2 instruction set is supported, use the 32-bit CRC32 instruction, and in the XorShift128, use a 32-bit based state instead of 64-bit.- Add software support for CRC32: if SSE 4.2 is not supported, fallback on a software implementation.- Modify tests that were not 32-bit compliant, and expand them to cover more allocation and alignment sizes. The random shuffle test has been deactivated for linux-i386 & linux-i686 as the 32-bit sanitizer allocator doesn't currently randomize chunks.Reviewers: alekseyshl, kccSubscribers: filcab, llvm-commits, tberghammer, danalbert, srhines, mgorny, modocacheDifferential Revision: https://reviews.llvm.org/D26358llvm-svn: 288255 List of files: /llvm-project-15.0.7/compiler-rt/lib/scudo/scudo_new_delete.cpp Wed, 30 Nov 2016 17:32:20 +0000 Kostya Kortchinsky <kostyak@google.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/compiler-rt/lib/scudo/scudo_new_delete.cpp#712fc980 [sanitizer] Initial implementation of a Hardened AllocatorSummary:This is an initial implementation of a Hardened Allocator based on Sanitizer Common's CombinedAllocator.It aims at mitigating heap based vulnerabilities by adding several features to the base allocator, while staying relatively fast.The following were implemented:- additional consistency checks on the allocation function parameters and on the heap chunks;- use of checksum protected chunk header, to detect corruption;- randomness to the allocator base;- delayed freelist (quarantine), to mitigate use after free and overall determinism.Additional mitigations are in the works.Reviewers: eugenis, aizatsky, pcc, krasin, vitalybuka, glider, dvyukov, kccSubscribers: kubabrecka, filcab, llvm-commitsDifferential Revision: http://reviews.llvm.org/D20084llvm-svn: 271968 List of files: /llvm-project-15.0.7/compiler-rt/lib/scudo/scudo_new_delete.cpp Tue, 07 Jun 2016 01:20:26 +0000 Kostya Serebryany <kcc@google.com>