linux-kernel - Re: [PATCH 1/2] MSR: Add support for safe variants

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-next>] [day] [month] [year] [list]

Message-Id: <200703261157.l2QBvTJg011821@harpo.it.uu.se>
Date:	Mon, 26 Mar 2007 13:57:29 +0200 (MEST)
From:	Mikael Pettersson <mikpe@...uu.se>
To:	akpm@...ux-foundation.org, khali@...ux-fr.org
Cc:	adobriyan@...nvz.org, davej@...hat.com,
	linux-kernel@...r.kernel.org, r.marek@...embler.cz
Subject: Re: [PATCH 1/2] MSR: Add support for safe variants

On Mon, 26 Mar 2007 13:29:37 +0200, Jean Delvare wrote:
> * * * * * Updated patch * * * * *
> 
> From: Rudolf Marek <r.marek@...embler.cz>
> 
> Add safe (exception handled) variants of rdmsr_on_cpu and wrmsr_on_cpu.
> You should use these when the target MSR may not actually exist, as
> doing so could trigger an exception which the regular functions do not
> handle. The safe variants are slower, though.
> 
> The upcoming coretemp hardware monitoring driver will need this.

Maybe I'm in the minority here, but I for one strongly believe
that any attempt to access an MSR "which might not be there" is
inherently wrong. It implies that your HW detection is incomplete,
which in combination with MSR accesses means that you may end up
accessing MSRs that aren't at all what you think they should be.

Who supplies these imprecise MSR definitions anyway?
Intel manuals? ACPI?

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