aboutsummaryrefslogtreecommitdiffstats
path: root/scripts/leaking_addresses.pl
AgeCommit message (Collapse)Author
2017-11-14leaking_addresses: add SigIgn to false positivesTobin C. Harding
Signal masks are false positives, we already check for SigBlk and SigCgt but we missed SigIgn. Add SigIgn to false positive check. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2017-11-14leaking_addresses: add timeout on file readTobin C. Harding
Currently script can stall if we read certain files (like /proc/kmsg). While we have a mechanism to skip these files once they are discovered it would be nice to not stall on as yet undiscovered files of this kind. Set a timer before each file is parsed, warn user if timer expires. Suggested-by: Kees Cook <keescook@chromium.org> Signed-off-by: Tobin C. Harding <me@tobin.cc>
2017-11-14leaking_addresses: add support for ppc64Tobin C. Harding
Currently script is targeted at x86_64. We can support other architectures by using the correct regular expressions for each architecture. Add the infrastructure to support multiple architectures. Add support for ppc64. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2017-11-14leaking_addresses: add summary reporting optionsTobin C. Harding
Currently script just dumps all results found. Potentially, this risks losing single results among multiple duplicate results. We need some way of restricting duplicates to assist users of the script. It would also be nice if we got a report instead of raw results. Duplicates can be defined in various ways, instead of trying to find a single perfect solution we can present the user with various options to display the output. Doing so will typically lead to users wanting to view the output multiple times. Currently we scan the kernel each time, this is slow and unnecessary. We can expedite the process by writing the results to file for subsequent viewing. Add command line options to enable summary reporting, including options to write to and read from file. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2017-11-14leaking_addresses: add to exclude files/paths listTobin C. Harding
There are a couple more files that cause the script to stall. /sys/firmware/devicetree and its symlink /proc/device-tree, reported by Michael Ellerman. usbmon should be skipped were ever it appears. Reported by Kees Cook Add files to be excluded from parsing. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2017-11-14leaking_addresses: fix comment string typoTobin C. Harding
Fix typo in comment string. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2017-11-14leaking_addresses: remove command line optionsTobin C. Harding
Currently script accepts files to skip. This was added to make running the script faster (for repeat runs). We can remove this functionality in preparation for adding sub commands (scan and format) to the script. Remove command line options. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2017-11-14leaking_addresses: remove dead/unused codeTobin C. Harding
debug_arrays is not called. Also, %seen hash is not used. We should remove unused code. Remove dead code. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2017-11-14leaking_addresses: use tabs instead of spacesTobin C. Harding
Current code uses spaces instead of tabs in places. Use tabs instead of spaces. Signed-off-by: Tobin C. Harding <me@tobin.cc>
2017-11-06scripts: add leaking_addresses.plTobin C. Harding
Currently we are leaking addresses from the kernel to user space. This script is an attempt to find some of those leakages. Script parses `dmesg` output and /proc and /sys files for hex strings that look like kernel addresses. Only works for 64 bit kernels, the reason being that kernel addresses on 64 bit kernels have 'ffff' as the leading bit pattern making greping possible. On 32 kernels we don't have this luxury. Scripts is _slightly_ smarter than a straight grep, we check for false positives (all 0's or all 1's, and vsyscall start/finish addresses). [ I think there is a lot of room for improvement here, but it's already useful, so I'm merging it as-is. The whole "hash %p format" series is expected to go into 4.15, but will not fix %x users, and will not incentivize people to look at what they are leaking. - Linus ] Signed-off-by: Tobin C. Harding <me@tobin.cc> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>