summaryrefslogtreecommitdiffstats
path: root/compiler-rt/test/hwasan
Commit message (Collapse)AuthorAgeFilesLines
* [compiler-rt] libhwasan interceptor ABI intercept longjmp/setjmpDavid Tellenbach2019-10-301-0/+39
| | | | | | | | | | | | | | | | | | | | | | Summary: The hwasan interceptor ABI doesn't have interceptors for longjmp and setjmp. This patch introduces them. We require the size of the jmp_buf on the platform to be at least as large as the jmp_buf in our implementation. To enforce this we compile hwasan_type_test.cpp that ensures a compile time failure if this is not true. Tested on both GCC and clang using an AArch64 virtual machine. Reviewers: eugenis, kcc, pcc, Sanatizers Reviewed By: eugenis, Sanatizers Tags: #sanatizers, #llvm Differential Revision: https://reviews.llvm.org/D69045 Patch By: Matthew Malcomson <matthew.malcomson@arm.com>
* [hwasan] Fix typo in the error type.Evgenii Stepanov2019-10-281-1/+1
| | | | "alocation-tail-overwritten" -> "allocation-tail-overwritten"
* Fix lld detection in standalone compiler-rt.Evgenii Stepanov2019-10-241-1/+3
| | | | | | | | | | | | | | | Summary: Right now all hwasan tests on Android are silently disabled because they require "has_lld" and standalone compiler-rt can not (and AFAIK was never able to) set it. Reviewers: pcc Subscribers: dberris, mgorny, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69405
* [hwasan] Workaround unwinder issues in try-catch test.Evgeniy Stepanov2019-10-211-4/+5
| | | | | | | | | | Android links the unwinder library to every DSO. The problem is, unwinder has global state, and hwasan implementation of personality function wrapper happens to rub it the wrong way. Switch the test to static libc++ as a temporary workaround. llvm-svn: 375471
* [hwasan] Remove system allocator fallback.Evgeniy Stepanov2019-10-181-54/+0
| | | | | | | | | | | | | | | | Summary: This has been an experiment with late malloc interposition, made possible by a non-standard feature of the Android dynamic loader. Reviewers: pcc, mmalcomson Subscribers: srhines, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69199 llvm-svn: 375296
* hwasan: Compatibility fixes for short granules.Peter Collingbourne2019-09-272-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | We can't use short granules with stack instrumentation when targeting older API levels because the rest of the system won't understand the short granule tags stored in shadow memory. Moreover, we need to be able to let old binaries (which won't understand short granule tags) run on a new system that supports short granule tags. Such binaries will call the __hwasan_tag_mismatch function when their outlined checks fail. We can compensate for the binary's lack of support for short granules by implementing the short granule part of the check in the __hwasan_tag_mismatch function. Unfortunately we can't do anything about inline checks, but I don't believe that we can generate these by default on aarch64, nor did we do so when the ABI was fixed. A new function, __hwasan_tag_mismatch_v2, is introduced that lets code targeting the new runtime avoid redoing the short granule check. Because tag mismatches are rare this isn't important from a performance perspective; the main benefit is that it introduces a symbol dependency that prevents binaries targeting the new runtime from running on older (i.e. incompatible) runtimes. Differential Revision: https://reviews.llvm.org/D68059 llvm-svn: 373035
* [hwasan] Fix test failure in r369721.Evgeniy Stepanov2019-08-261-3/+6
| | | | | | | | | Try harder to emulate "old runtime" in the test. To get the old behavior with the new runtime library, we need both disable personality function wrapping and enable landing pad instrumentation. llvm-svn: 369977
* hwasan: Untag unwound stack frames by wrapping personality functions.Peter Collingbourne2019-08-232-3/+13
| | | | | | | | | | | | | | | | | | | | | | | One problem with untagging memory in landing pads is that it only works correctly if the function that catches the exception is instrumented. If the function is uninstrumented, we have no opportunity to untag the memory. To address this, replace landing pad instrumentation with personality function wrapping. Each function with an instrumented stack has its personality function replaced with a wrapper provided by the runtime. Functions that did not have a personality function to begin with also get wrappers if they may be unwound past. As the unwinder calls personality functions during stack unwinding, the original personality function is called and the function's stack frame is untagged by the wrapper if the personality function instructs the unwinder to keep unwinding. If unwinding stops at a landing pad, the function is still responsible for untagging its stack frame if it resumes unwinding. The old landing pad mechanism is preserved for compatibility with old runtimes. Differential Revision: https://reviews.llvm.org/D66377 llvm-svn: 369721
* Add LLD as a requirement for hwasan tests because of change in r368111.Douglas Yung2019-08-081-1/+1
| | | | llvm-svn: 368242
* [HWASan] Use LLD for check-hwasan.Mitch Phillips2019-08-071-1/+1
| | | | | | | | HWASan+globals build fix in rL368111 unfortunately didn't fix the problem when clang_cflags specified -fuse-ld=ld.gold. Change the order to force lld in an attempt to fix the Android sanitizer bot. llvm-svn: 368218
* Require lld for hwasan tests.Peter Collingbourne2019-08-063-2/+5
| | | | | | | | We're using relocations that are unsupported by the version of gold on the bot, so force the use of lld. One of the tests is already using lld, so this should be safe. llvm-svn: 368111
* hwasan: Instrument globals.Peter Collingbourne2019-08-062-1/+23
| | | | | | | | | | | | | | | | | | Globals are instrumented by adding a pointer tag to their symbol values and emitting metadata into a special section that allows the runtime to tag their memory when the library is loaded. Due to order of initialization issues explained in more detail in the comments, shadow initialization cannot happen during regular global initialization. Instead, the location of the global section is marked using an ELF note, and we require libc support for calling a function provided by the HWASAN runtime when libraries are loaded and unloaded. Based on ideas discussed with @evgeny777 in D56672. Differential Revision: https://reviews.llvm.org/D65770 llvm-svn: 368102
* hwasan: Untag global variable addresses in tests.Peter Collingbourne2019-08-0514-42/+99
| | | | | | | | | | | | Once we start instrumenting globals, all addresses including those of string literals that we pass to the operating system will start being tagged. Since we can't rely on the operating system to be able to cope with these addresses, we need to untag them before passing them to the operating system. This change introduces a macro that does so and uses it everywhere it is needed. Differential Revision: https://reviews.llvm.org/D65768 llvm-svn: 367938
* More follow-up to r367851Nico Weber2019-08-053-3/+3
| | | | llvm-svn: 367856
* compiler-rt: Rename cc files in test/hwasan/TestCases subdirectories as wellNico Weber2019-08-054-0/+0
| | | | | | Should've been part of r367849. llvm-svn: 367851
* compiler-rt: Rename .cc file in test/hwasan to .cppNico Weber2019-08-0513-6/+6
| | | | | | Like r367463, but for test/hwasan. llvm-svn: 367849
* hwasan: Use C++ driver for cfi.cc test.Peter Collingbourne2019-07-171-1/+1
| | | | | | | | | | | | | | It turns out that this test was only passing by accident. It was relying on the optimizer to remove the only reference to A's vtable by realizing that the CFI check will always fail. The vtable contains a reference to RTTI in libc++, which will be unresolved because the C driver won't link against it. This was found by my prototype implementation of HWASAN for globals, which happens to end up preserving the reference. Differential Revision: https://reviews.llvm.org/D64890 llvm-svn: 366389
* hwasan: Improve precision of checks using short granule tags.Peter Collingbourne2019-07-094-64/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A short granule is a granule of size between 1 and `TG-1` bytes. The size of a short granule is stored at the location in shadow memory where the granule's tag is normally stored, while the granule's actual tag is stored in the last byte of the granule. This means that in order to verify that a pointer tag matches a memory tag, HWASAN must check for two possibilities: * the pointer tag is equal to the memory tag in shadow memory, or * the shadow memory tag is actually a short granule size, the value being loaded is in bounds of the granule and the pointer tag is equal to the last byte of the granule. Pointer tags between 1 to `TG-1` are possible and are as likely as any other tag. This means that these tags in memory have two interpretations: the full tag interpretation (where the pointer tag is between 1 and `TG-1` and the last byte of the granule is ordinary data) and the short tag interpretation (where the pointer tag is stored in the granule). When HWASAN detects an error near a memory tag between 1 and `TG-1`, it will show both the memory tag and the last byte of the granule. Currently, it is up to the user to disambiguate the two possibilities. Because this functionality obsoletes the right aligned heap feature of the HWASAN memory allocator (and because we can no longer easily test it), the feature is removed. Also update the documentation to cover both short granule tags and outlined checks. Differential Revision: https://reviews.llvm.org/D63908 llvm-svn: 365551
* hwasan: Teach the runtime to identify the local variable being accessed in ↵Peter Collingbourne2019-06-273-13/+53
| | | | | | | | | | | | | | UAR reports. Each function's PC is recorded in the ring buffer. From there we can access the function's local variables and reconstruct the tag of each one with the help of the information printed by llvm-symbolizer's new FRAME command. We can then find the variable that was likely being accessed by matching the pointer's tag against the reconstructed tag. Differential Revision: https://reviews.llvm.org/D63469 llvm-svn: 364607
* [compiler-rt] Rename lit.*.cfg.* -> lit.*.cfg.py.*Reid Kleckner2019-06-275-3/+3
| | | | | | | | | | | | | These lit configuration files are really Python source code. Using the .py file extension helps editors and tools use the correct language mode. LLVM and Clang already use this convention for lit configuration, this change simply applies it to all of compiler-rt. Reviewers: vitalybuka, dberris Differential Revision: https://reviews.llvm.org/D63658 llvm-svn: 364591
* hwasan: Use bits [3..11) of the ring buffer entry address as the base stack tag.Peter Collingbourne2019-06-173-13/+16
| | | | | | | | | | | | | | This saves roughly 32 bytes of instructions per function with stack objects and causes us to preserve enough information that we can recover the original tags of all stack variables. Now that stack tags are deterministic, we no longer need to pass -hwasan-generate-tags-with-calls during check-hwasan. This also means that the new stack tag generation mechanism is exercised by check-hwasan. Differential Revision: https://reviews.llvm.org/D63360 llvm-svn: 363636
* Set an output file name for the override-new-delete.cpp test.Peter Collingbourne2019-06-071-1/+1
| | | | | | The android_compile.py script requires one. llvm-svn: 362764
* [HWASAN] Make new/delete weakEugene Leviant2019-06-041-0/+23
| | | | | | | | | This allows instrumenting programs which have their own versions of new and delete operators. Differential revision: https://reviews.llvm.org/D62794 llvm-svn: 362478
* [hwasan] Limit try-catch tests to aarch64.Evgeniy Stepanov2019-05-171-0/+3
| | | | | | | HWASan C++ tests do not do well on x86_64. Fixes https://bugs.llvm.org/show_bug.cgi?id=41923 llvm-svn: 361063
* HWASan exception support.Evgeniy Stepanov2019-05-161-0/+60
| | | | | | | | | | | | | | | | | | Summary: Adds a call to __hwasan_handle_vfork(SP) at each landingpad entry. Reusing __hwasan_handle_vfork instead of introducing a new runtime call in order to be ABI-compatible with old runtime library. Reviewers: pcc Subscribers: kubamracek, hiraditya, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D61968 llvm-svn: 360959
* [sanitizer] Implement reallocarray.Evgeniy Stepanov2019-05-013-8/+25
| | | | | | | | | | | | | | | | Summary: It's a cross of calloc and realloc. Sanitizers implement calloc-like check for size overflow. Reviewers: vitalybuka, kcc Subscribers: kubamracek, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D61108 llvm-svn: 359708
* Removed regiser dump checks from FP unit test.Mitch Phillips2019-04-191-41/+14
| | | | llvm-svn: 358770
* [HWASan] Added no-FP unit test for register dump.Mitch Phillips2019-04-191-12/+12
| | | | | | | | | | | | | | Summary: Unit test for D60798. Reviewers: eugenis Subscribers: kubamracek, #sanitizers, llvm-commits, pcc Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D60806 llvm-svn: 358769
* Updated test case.Mitch Phillips2019-04-191-7/+19
| | | | llvm-svn: 358768
* Added no-FP unit test for register dump.Mitch Phillips2019-04-191-0/+43
| | | | llvm-svn: 358767
* hwasan: Enable -hwasan-allow-ifunc by default.Peter Collingbourne2019-04-091-2/+1
| | | | | | | | | It's been on in Android for a while without causing problems, so it's time to make it the default and remove the flag. Differential Revision: https://reviews.llvm.org/D60355 llvm-svn: 357960
* [HWASan] Save + print registers when tag mismatch occurs in AArch64.Mitch Phillips2019-03-081-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change change the instrumentation to allow users to view the registers at the point at which tag mismatch occured. Most of the heavy lifting is done in the runtime library, where we save the registers to the stack and emit unwind information. This allows us to reduce the overhead, as very little additional work needs to be done in each __hwasan_check instance. In this implementation, the fast path of __hwasan_check is unmodified. There are an additional 4 instructions (16B) emitted in the slow path in every __hwasan_check instance. This may increase binary size somewhat, but as most of the work is done in the runtime library, it's manageable. The failure trace now contains a list of registers at the point of which the failure occured, in a format similar to that of Android's tombstones. It currently has the following format: Registers where the failure occurred (pc 0x0055555561b4): x0 0000000000000014 x1 0000007ffffff6c0 x2 1100007ffffff6d0 x3 12000056ffffe025 x4 0000007fff800000 x5 0000000000000014 x6 0000007fff800000 x7 0000000000000001 x8 12000056ffffe020 x9 0200007700000000 x10 0200007700000000 x11 0000000000000000 x12 0000007fffffdde0 x13 0000000000000000 x14 02b65b01f7a97490 x15 0000000000000000 x16 0000007fb77376b8 x17 0000000000000012 x18 0000007fb7ed6000 x19 0000005555556078 x20 0000007ffffff768 x21 0000007ffffff778 x22 0000000000000001 x23 0000000000000000 x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000 x28 0000000000000000 x29 0000007ffffff6f0 x30 00000055555561b4 ... and prints after the dump of memory tags around the buggy address. Every register is saved exactly as it was at the point where the tag mismatch occurs, with the exception of x16/x17. These registers are used in the tag mismatch calculation as scratch registers during __hwasan_check, and cannot be saved without affecting the fast path. As these registers are designated as scratch registers for linking, there should be no important information in them that could aid in debugging. Reviewers: pcc, eugenis Reviewed By: pcc, eugenis Subscribers: srhines, kubamracek, mgorny, javed.absar, krytarowski, kristof.beyls, hiraditya, jdoerfert, llvm-commits, #sanitizers Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D58857 llvm-svn: 355738
* [hwasan, asan] Intercept vfork.Evgeniy Stepanov2019-02-271-0/+32
| | | | | | | | | | | | | | | Summary: Intercept vfork on arm, aarch64, i386 and x86_64. Reviewers: pcc, vitalybuka Subscribers: kubamracek, mgorny, javed.absar, krytarowski, kristof.beyls, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D58533 llvm-svn: 355030
* [hwasan] Fix tests after .cc->.cpp renaming.Evgeniy Stepanov2019-02-271-2/+2
| | | | llvm-svn: 355028
* Revert "[asan] Fix vfork handling.", +1Evgeniy Stepanov2019-02-211-32/+0
| | | | | | Revert r354625, r354627 - multiple build failures. llvm-svn: 354629
* [hwasan,asan] Intercept vfork.Evgeniy Stepanov2019-02-211-0/+32
| | | | | | | | | | | | | | Summary: AArch64 only for now. Reviewers: vitalybuka, pcc Subscribers: srhines, kubamracek, mgorny, javed.absar, krytarowski, kristof.beyls, jdoerfert, #sanitizers, llvm-commits, kcc Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D58313 llvm-svn: 354625
* Fix unsymbolized stack history printing.Evgeniy Stepanov2019-02-151-0/+5
| | | | | | | | | | | | | | | | | | | | | Summary: When symbols are unavailable, the current code prints sp: ... pc: ... (null) (null) instead of module name + offset. Change the output to include module name and offset, and also to match the regular sanitizer stack trace format so that it is recognized by symbolize.py out of the box. Reviewers: kcc, pcc Subscribers: kubamracek, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58267 llvm-svn: 354157
* Runtime flags for malloc bisection.Evgeniy Stepanov2019-02-151-0/+26
| | | | | | | | | | | | Reviewers: kcc, pcc Subscribers: kubamracek, mgorny, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58162 llvm-svn: 354156
* Fix false positive when tag_in_malloc=0,tag_in_free=1.Evgeniy Stepanov2019-02-151-0/+51
| | | | | | | | | | | | | | | | Summary: With tag_in_free=1, malloc() can not assume that the memory is untagged, and needs to retag is to 0. Reviewers: pcc, kcc Subscribers: kubamracek, jfb, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58158 llvm-svn: 354155
* [sanitizer] Decorate /proc/self/maps better.Evgeniy Stepanov2019-02-061-0/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Refactor the way /proc/self/maps entries are annotated to support most (all?) posix platforms, with a special implementation for Android. Extend the set of decorated Mmap* calls. Replace shm_open with internal_open("/dev/shm/%s"). Shm_open is problematic because it calls libc open() which may be intercepted. Generic implementation has limits (max number of files under /dev/shm is 64K on my machine), which can be conceivably reached when sanitizing multiple programs at once. Android implemenation is essentially free, and enabled by default. The test in sanitizer_common is copied to hwasan and not reused directly because hwasan fails way too many common tests at the moment. Reviewers: pcc, vitalybuka Subscribers: srhines, kubamracek, jfb, llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D57720 llvm-svn: 353255
* gn build: Upgrade to NDK r19.Peter Collingbourne2019-02-051-1/+3
| | | | | | | | | | NDK r19 includes a sysroot that can be used directly by the compiler without creating a standalone toolchain, so we just need a handful of flags to point Clang there. Differential Revision: https://reviews.llvm.org/D57733 llvm-svn: 353139
* [hwasan] Implement print_module_map flag.Evgeniy Stepanov2019-01-251-0/+32
| | | | | | | | | | Reviewers: kcc, pcc Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D57130 llvm-svn: 352150
* hwasan: Read shadow address from ifunc if we don't need a frame record.Peter Collingbourne2019-01-231-1/+2
| | | | | | | | | | | | | This saves a cbz+cold call in the interceptor ABI, as well as a realign in both ABIs, trading off a dcache entry against some branch predictor entries and some code size. Unfortunately the functionality is hidden behind a flag because ifunc is known to be broken on static binaries on Android. Differential Revision: https://reviews.llvm.org/D57084 llvm-svn: 351989
* [HWASAN] Improve tag mismatch diagnosticsEugene Leviant2019-01-211-5/+7
| | | | | | | | | Reports correct size and tags when either size is not power of two or offset to bad granule is not zero. Differential revision: https://reviews.llvm.org/D56603 llvm-svn: 351730
* [hwasan] Madvise away unused shadow.Evgeniy Stepanov2019-01-191-0/+70
| | | | | | | | | | | | | | | | | | Summary: Whenever a large shadow region is tagged to zero, madvise(DONT_NEED) as much of it as possible. This reduces shadow RSS on Android by 45% or so, and total memory use by 2-4%, probably even more on long running multithreaded programs. CPU time seems to be in the noise. Reviewers: kcc, pcc Subscribers: srhines, kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D56757 llvm-svn: 351620
* compiler-rt/test: Add a couple of convenience features for Android.Peter Collingbourne2019-01-152-0/+4
| | | | | | | | | | | | | | | | Add a ANDROID_SERIAL_FOR_TESTING CMake variable. This lets you run the tests with multiple devices attached without having to set ANDROID_SERIAL. Add a mechanism for pushing files to the device. Currently most sanitizers require llvm-symbolizer and the sanitizer runtime to be pushed to the device. This lets the sanitizer make this happen automatically before running the tests by specifying the paths in the lit.site.cfg file. Differential Revision: https://reviews.llvm.org/D56712 llvm-svn: 351260
* hwasan: Ignore loads and stores of size 0.Peter Collingbourne2019-01-091-0/+10
| | | | | | | | | | | | | | | | | | Now that memory intrinsics are instrumented, it's more likely that CheckAddressSized will be called with size 0. (It was possible before with IR like: %val = load [0 x i8], [0 x i8]* %ptr but I don't think clang will generate IR like that and the optimizer would normally remove it by the time it got anywhere near our pass anyway). The right thing to do in both cases is to disable the addressing checks (since the underlying memory intrinsic is a no-op), so that's what we do. Differential Revision: https://reviews.llvm.org/D56465 llvm-svn: 350683
* Disable system-allocator-fallback.cc test on Android O and earlier.Peter Collingbourne2019-01-041-0/+4
| | | | | | | The dynamic loader on Android O appears to have a bug where it crashes when dlopening DF_1_GLOBAL libraries. llvm-svn: 350444
* hwasan: Use system allocator to realloc and free untagged pointers in ↵Peter Collingbourne2019-01-042-1/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | interceptor mode. The Android dynamic loader has a non-standard feature that allows libraries such as the hwasan runtime to interpose symbols even after the symbol already has a value. The new value of the symbol is used to relocate libraries loaded after the interposing library, but existing libraries keep the old value. This behaviour is activated by the DF_1_GLOBAL flag in DT_FLAGS_1, which is set by passing -z global to the linker, which is what we already do to link the hwasan runtime. What this means in practice is that if we have .so files that depend on interceptor-mode hwasan without the main executable depending on it, some of the libraries in the process will be using the hwasan allocator and some will be using the system allocator, and these allocators need to interact somehow. For example, if an instrumented library calls a function such as strdup that allocates memory on behalf of the caller, the instrumented library can reasonably expect to be able to call free to deallocate the memory. We can handle that relatively easily with hwasan by using tag 0 to represent allocations from the system allocator. If hwasan's realloc or free functions are passed a pointer with tag 0, the system allocator is called. One limitation is that this scheme doesn't work in reverse: if an instrumented library allocates memory, it must free the memory itself and cannot pass ownership to a system library. In a future change, we may want to expose an API for calling the system allocator so that instrumented libraries can safely transfer ownership of memory to system libraries. Differential Revision: https://reviews.llvm.org/D55986 llvm-svn: 350427
* [hwasan] Switch to 64 allocator with a dense size class map.Evgeniy Stepanov2019-01-032-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Replace the 32-bit allocator with a 64-bit one with a non-constant base address, and reduce both the number of size classes and the maximum size of per-thread caches. As measured on [1], this reduces average weighted memory overhead (MaxRSS) from 26% to 12% over stock android allocator. These numbers include overhead from code instrumentation and hwasan shadow (i.e. not a pure allocator benchmark). This switch also enables release-to-OS functionality, which is not implemented in the 32-bit allocator. I have not seen any effect from that on the benchmark. [1] https://android.googlesource.com/platform/system/extras/+/master/memory_replay/ Reviewers: vitalybuka, kcc Subscribers: kubamracek, cryptoad, llvm-commits Differential Revision: https://reviews.llvm.org/D56239 llvm-svn: 350370
OpenPOWER on IntegriCloud