lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y1z4kZVRmX33GJ0F@p183>
Date:   Sat, 29 Oct 2022 12:55:29 +0300
From:   Alexey Dobriyan <adobriyan@...il.com>
To:     "H. Peter Anvin" <hpa@...or.com>
Cc:     tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        dave.hansen@...ux.intel.com, linux-kernel@...r.kernel.org,
        x86@...nel.org
Subject: Re: [PATCH] selftests/x86: add "ffff8" -- kernel memory scanner

On Fri, Oct 28, 2022 at 03:14:31PM -0700, H. Peter Anvin wrote:
> On October 28, 2022 12:33:49 PM PDT, Alexey Dobriyan <adobriyan@...il.com> wrote:
> >During Meltdown drama Microsoft managed to screw up pagetables and give
> >full kernel memory access to userspace:
> >
> >	https://blog.frizk.net/2018/03/total-meltdown.html
> >
> >We don't want _any_ of that.
> >
> >This utility named ffff8 tries to read upper half of virtual address space
> >and report access that went through (excluding vsyscall page if present).
> >
> >It works by doing access and rewriting RDI in the SIGSEGV handler.
> >
> >I've tested it with kernel patch which installs rogue page and it was found.
> >
> >	$ ./a.out -h
> >	usage: ./a.out [-f] [-r] [-n N] [-s S]
> >	        -f: sequential scan
> >	        -r: random scan (default)
> >	        -n: use N threads (default: $(nproc))
> >	        -s: lowest address shift (default: 47)
> >	        -t: time to run (default: 256 seconds)
> >
> >Intended usages are:
> >
> >	$ ./a.out -f		# full scan on all cores
> >or
> >	$ ./a.out -r -t ...	# time limited random scan for QA test
> >
> >Features include:
> >* multithreading
> >* auto spreads over CPUs given by taskset
> >* full sequential scan / random scan
> >* auto split work for full scan
> >* smaller than 47-bit scanning (for benchmarking)
> >* time limit
> >
> >Note 1:
> >HT appears to make scanning slower. If this is the case use taskset(1)
> >to exclude HT siblings.
> >
> >Note 2:
> >Full 47-bit window scan takes a long time. My 16c/32t potato can do it
> >in ~8 hours. Benchmark with smaller shifts first.
> 
> Good initiative!

Thanks!

> Only complaint I have is the name and the limit to LA48. LA57 (5-level
> page tables) have the same potential issue.

Yes. It would take only half a year to scan 57-bit space if my system
had one. :-)

> You may want to consider doing a breadth-first sweep scanning
> by decreasing powers of 2 as that will more quickly catch errors caused
> by problems in the upper levels of the page table hierarchy.

It can scan from top to bottom so that fixmap space is easily covered.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ