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] [day] [month] [year] [list]
Date:	Sun, 24 Apr 2011 22:47:25 +0200
From:	Pavel Machek <pavel@....cz>
To:	Rik van Riel <riel@...hat.com>
Cc:	rwhitton@....org, linux-kernel@...r.kernel.org
Subject: Re: Background memory scrubbing

Hi!

> >>>for each PFN from 256 to the highest valid PFN
> >>>{
> >>>if (pfn_valid(PFN))
> >>>{
> >>>page = pfn_to_page(PFN)
> >>>va = kmap(page)
> >>>atomic_scrub(va, PAGE_SIZE)
> >>>kunmap(page)
> >>>}
> >>>
> >>>sleep(for_a_while)
> >>>}
> >>
> >>What exactly does atomic_scrub do?
> >
> >atomic_scrub is part of the edac subsystem see arch/x86/include/asm/edac.h. It simply does a locked add of zero to each DWORD in the specified range.
> 
> I can think of only a few ways in which that could cause a
> kernel page fault.
> 
> One of the more obvious causes would be running into an
> area of kernel memory that is mapped read-only.  Writing
> to a page that is mapped read-only would cause a page
> fault :)

...also... you are actually making kernel use "self modifying code"
here. There  are CPU bugs in that area...  for example on K6.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ