linux-kernel - Re: [PATCH] tsc_khz= boot option to avoid TSC calibration variance

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:	13 May 2009 14:45:16 -0400
From:	"George Spelvin" <linux@...izon.com>
To:	belyshev@...ni.sinp.msu.ru, johnstul@...ibm.com
Cc:	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	linux@...izon.com, mingo@...e.hu, tglx@...utronix.de,
	ulrich.windl@...uni-regensburg.de, williams@...hat.com,
	zippel@...ux-m68k.org
Subject: Re: [PATCH] tsc_khz= boot option to avoid TSC calibration variance

> No, it won't, because...  
> <cde snippet>
> ... of this "if".
> 
> Please *please* don't set arbitrary limits.  Just use user supplied value.
> 
> Or at the very least print big red warning if you are going to ignore a user
> supplied option (and have another tsc_khz_really= option to override faulty
> calibration routine).

I'd like to disagree.  The calibration is accurate and reliable.
It has worked without any override for millions of users for many
years.  What is the plausible reason to need to set it to a wildly
divergent value?

On the other hand, what if my CPU gets fried and I replace it with one
with a different clock multiplier?  Or the motherboard fries and I move
the boot hard drive to a different machine?  That's a situation that I
have found myself in.  And I don't want to figure out how to edit the
LILO options before booting the machine, even if I remember to do it
at all; this is an emergency replacement.

In such a case, having the kernel believe the command line could result
in it not booting, or the system not working properly.

Much better that it basically work, even if some fine-tuning remains
to be done.

And that's the idea: this is a fine-tuning option.  If the calibration
says the option value is grossly wrong, then something strange has
happened, and the kernel calibration value is safer.

If you think a coarse-tuning option is required, I can extend the patch
so that a trailing ! (e.g. "tsc_khz=3000000!") disables the sanity check.
Bit I'd still like to see an argument for why it is required.  Remember,
it would be far better to make the kernel self-calibration more accurate,
so people don't even have to use this option.  It's only there because
it's the simplest way (simplest for the lazy programmer, not the user!)
to guarantee getting exactly the same value each boot.

>From a *user* point of view, I'd rather the kernel did it automagically
and I didn't need to futz with the kernel command line at all.
--
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/