linux-kernel - Re: [PATCH 01/22] x86: add methods for writing of an MSR on several CPUs

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]

Date:	Thu, 21 May 2009 16:08:00 +0200
From:	Borislav Petkov <borislav.petkov@....com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	akpm@...ux-foundation.org, greg@...ah.com, mingo@...e.hu,
	norsk5@...oo.com, tglx@...utronix.de, mchehab@...hat.com,
	aris@...hat.com, edt@....ca, linux-kernel@...r.kernel.org,
	Andreas Herrmann <andreas.herrmann3@....com>
Subject: Re: [PATCH 01/22] x86: add methods for writing of an MSR on
	several CPUs

On Wed, May 20, 2009 at 02:39:29PM -0700, H. Peter Anvin wrote:
> Borislav Petkov wrote:
> > 
> > We currently need them for enabling the NB error reporting bank over
> > MCG_CTL on each core on the node. The question is whether we really need
> > the concurrency when accessing an MSR on several cores. With MCG_CTL,
> > BKDG says "It is expected that this register is programmed to the same
> > value in all nodes," but nothing concerning concurrency.
> > 
> > But you're right, if this interface is supposed to be generic enough,
> > it is probably wise to access an MSR concurrently. I could imagine
> > an obscure case where this is required. However, is sending IPIs
> > (smp_call_function_many) guaranteeing the needed concurrency? Or, should
> > it be more like how the mtrr code jumps through hoops (set_mtrr())
> > in order to ensure that _ALL_ registers have been written _before_
> > continuing?
> > 
> 
> smp_call_function_many() does allow concurrent execution.

Well, IMHO, not an absolutely concurrent execution since you can't
control at what moment in time the IPIs will be executed on each core,
IOW, the respective call function IPIs will generally not coincide on
each core at a given moment in time. This is especially true if you're
sending IPIs to cores across nodes.

And there's hypothetically a small window where you might get an
inconsistent MSR content across cores. It's a whole another question
whether this is going to be relevant.

> Looping over a list with smp_call_function_one() -- which you
> currently have -- is serializing, at which point we might just push
> the loop into the caller rather than worrying about a new interface.

So, the actual question is do we need that done in msr.c? If there are
no potential users, I could easily do the whole thing in the driver and
do not touch x86 code.

Hmm?

-- 
Regards/Gruss,
Boris.

Operating | Advanced Micro Devices GmbH
  System  | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
 Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni
  Center  | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
  (OSRC)  | Registergericht München, HRB Nr. 43632

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