linux-kernel - Re: Linux 2.6.29-rc6

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.LFD.2.00.0903151323260.3131@localhost.localdomain>
Date:	Sun, 15 Mar 2009 13:32:42 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jesper Krogh <jesper@...gh.cc>
cc:	john stultz <johnstul@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Len Brown <len.brown@...el.com>
Subject: Re: Linux 2.6.29-rc6

On Sun, 15 Mar 2009, Jesper Krogh wrote:
> 
> I went on to trying Thomas Gleixners patch (which seems to do excactly the
> same .. ), I'll write a reply in to that message in a few minutes.

Side note: no, Thomas' patch doesn't do at all exactly the same. It does 
something similar, in that it looks at the time differences between calls 
to the whole "wait for the PIT MSB to change" function, but those 
differences _could_ in theory be very small, even if the error is very 
big.

That's especially true if the PIT read ends up serializing with the PIT, 
so that the "wait for MSB" essentially always takes exactly the same 
amount of cycles (giving a zero error estimation in Thomas' version), but 
the reads themselves can still be quite slow (giving a non-zero error term 
in the end result).

IOW, Thomas' patch is good at finding variability in the reads - which 
could be the result of SMM interaction, while my patch literally measures 
how long it takes to read the MSB change.

Now in practice I suspect the variability in the MSB reads _probably_ 
correlate reasonably well with how long a single PIT read will take (ie 
rather than finding variability due to SMM interaction, it will find 
variability due to the "quanitization" effect of the reads taking a 
reasonably long time), so I suspect that in many cases Thomas' patch will 
error out for the same cases mine does.

But the two patches are rather fundamentally different.

		Linus
--
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/