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: <alpine.LNX.1.10.0805282210580.19264@fbirervta.pbzchgretzou.qr>
Date:	Wed, 28 May 2008 22:14:31 +0200 (CEST)
From:	Jan Engelhardt <jengelh@...ozas.de>
To:	Willy Tarreau <w@....eu>
cc:	Hugh Dickins <hugh@...itas.com>, Fede <fedux@...men.org.ar>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] Re: bad pmd ffff810000207238(9090909090909090).


On Wednesday 2008-05-28 21:56, Willy Tarreau wrote:
>On Wed, May 28, 2008 at 07:36:07PM +0100, Hugh Dickins wrote:
>> On Tue, 27 May 2008, Fede wrote:
>> > 
>> > Today I tried to start a firewalling script and failed due to an unrelated
>> > issue, but when I checked the log I saw this:
>> > 
>> > May 27 20:38:15 kaoz ip_tables: (C) 2000-2006 Netfilter Core Team
>> > May 27 20:38:28 kaoz Netfilter messages via NETLINK v0.30.
>> > May 27 20:38:28 kaoz nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
>> > May 27 20:38:28 kaoz ctnetlink v0.93: registering with nfnetlink.
>> > May 27 20:38:28 kaoz ClusterIP Version 0.8 loaded successfully
>> > May 27 20:38:28 kaoz mm/memory.c:127: bad pmd
>> > ffff810000207238(9090909090909090).
>> > 
>> > I also found another post with a very similar issue. The other post had almost
>> > the same message (*mm*/*memory*.*c*:*127*: *bad* *pmd*
>> > ffff810000207808(9090909090909090).)
>> > 
>> > Does anyone know what is it?
>> 
>> Thanks a lot for re-reporting this: it was fun to work it out.
>> It's not a rootkit, it's harmless, but we ought to fix the noise.
>> Simple patch below, but let me explain more verbosely first.
>> 
>> What was really interesting in your report was that the address
>> is so close to that in OGAWA-San's report.  I had a look at that
>> page on my x86_64 boxes, and they have lots of 0x90s there too.
>> It's just some page alignment filler that x86_64 kernel startup
>> has missed cleaning up - patch below fixes that.  There's no
>> security aspect to it: the entries were already not-present,
>> they just generate this noise by triggering the pmd_bad test.
>
>Is there a particular reason we use 0x90 as an alignment filler ?

Alignment within functions. You could use a JMP to jump over
the alignment, but that would be costly. So in order to
"run through the wall", you need an opcode that does not
do anything, something like 0x90.
0xAF would map to scasd on x86, and I'd hardly call that a
no-op.
--
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