Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
tree: 4680186e31
Fetching contributors…

Cannot retrieve contributors at this time

55 lines (45 sloc) 2.655 kb
A combination of tools to deal with bad memory on a Linux machine with
root access but limited access to kernel configuration. (The exact use case
is an Android tablet with a locked bootloader but a local root exploit).
It's an ugly hack, but the circumstances were ugly too :-)
mtester:
A simple memory tester that tries to find the physical address
of faulty memory.
Works like this:
- Allocate a large memory buffer and mlock() it.
- Fill the buffer with a repeating random pattern.
- Go through the buffer again, checking that the random pattern
repeats correctly.
- If not, try to find the physical address corresponsing to that
virtual address space page. Do this by opening /dev/mem, and
looking for a page there whose contents exactly match the contents
of the virtual address page with a failure. The expectation is
that it'll mostly be unique (working pages will have the random
pattern written flawlessly, and so should not match the broken
page's apparent contents).
Run as root with "mtester XXX", where XXX is as much memory
(in megabytes) as the machine can spare. It'll output the faulty
pages, and some diagnostic information in case the results don't
look entirely trustworthy.
You'll probably want to run the program multiple times in a row,
to account for various random factors.
Once that is done, pipe the combined output of these several
rust to the included merge-ranges.pl. This will merge adjacent
pages to larger regions, and expand each region to be aligned
at 128kB boundaries at both ends.
mlocker:
Prevent a faulty physical memory region from being handed to programs.
Works like this:
- mmap the specified regions in /dev/mem
- exit()
... and that's it. I expected that the program would at a minimum need
to mlock() the mapped regions + stay running for ever (and in the worst
case jump through similar hoops as mtester to find the relevant
physical addresses in the first place). But in practice none of that
was needed. Instead it turns out that just the act of mmaping a bit
of /dev/mem is sufficient to lock that memory out until the next
reboot.
I haven't yet read the kernel source to figure out what the mechanism
behind this would be. If any kernel hacker knows what is going on
(or wants to argue that this isn't what actually happening), I'd
love to hear from you :-)
Jump to Line
Something went wrong with that request. Please try again.