linux-kernel - Re: [RFC][patch 00/12] clocksource / timekeeping rework V2

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:	Fri, 31 Jul 2009 09:44:34 -0700
From:	Daniel Walker <dwalker@...o99.com>
To:	john stultz <johnstul@...ibm.com>
Cc:	Martin Schwidefsky <schwidefsky@...ibm.com>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC][patch 00/12] clocksource / timekeeping rework V2

On Fri, 2009-07-31 at 01:34 -0700, john stultz wrote:

> 
> Again, distro kernels. Users can't rebuild them without possibly losing
> the support they've paid for, and often recompiling them can cause 3rd
> party drivers to fail to work (some distros preserve kernel ABI
> stability between minor releases). Waiting 6 months or two years for the
> next release where everything is fixed upstream isn't going to make
> users happy.

It wouldn't need to be a module. The distro would update the kernel as
needed.. Just the act of loading an unauthorized kernel module would
potentially invalidate any distro support someone might get.. Distro's
typically provide backported fixes also.

> Now, with most hardware vendors implementing decent HPET/ACPI PM
> counters, maybe this case is more me reacting to a bad situation I had
> to deal with in the past then what we can realistically expect in the
> future. But given hardware designers like to break assumptions to
> squeeze out performance or features, I'd suspect there will be future
> situations where having some extra flexibility would be valuable.
> 
> Imaginary example: broken BIOS has incorrect HPET freq and the TSCs are
> not in sync. Savvy IT dude finds the problem, copies the HPET driver,
> names it hpet-fix and hard codes the proper HPET freq in. Sets the
> rating higher then HPET, builds it as a module and loads it on the
> affected hardware.

The IT guy more than likely would need to rebuild the kernel multiple
times to discover what the problem was .. In the end the distro would
push a fix for this to mainline, and provide a new kernel for the distro
users with a backported fix.

If there a potential for a clocksource to have some type of issue like
what you describe for the HPET, wouldn't it be easier to have all those
as tunable boot args or sysfs options .. 

Daniel

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