From owner-freebsd-questions@FreeBSD.ORG Fri Sep 1 08:41:24 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 360E216A4DA for ; Fri, 1 Sep 2006 08:41:24 +0000 (UTC) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (mp.cs.niu.edu [131.156.68.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB9D643D4C for ; Fri, 1 Sep 2006 08:41:23 +0000 (GMT) (envelope-from bennett@cs.niu.edu) Received: from mp.cs.niu.edu (bennett@localhost [127.0.0.1]) by mp.cs.niu.edu (8.13.8/8.13.8) with ESMTP id k818fCGW012645; Fri, 1 Sep 2006 03:41:12 -0500 (CDT) Date: Fri, 1 Sep 2006 03:41:12 -0500 (CDT) From: Scott Bennett Message-Id: <200609010841.k818fCrc012644@mp.cs.niu.edu> To: backyard Cc: Questions , "Chad Leigh -- Shire.Net LLC" Subject: Re: shared cache -- Re: SMP detection X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2006 08:41:24 -0000 On Thu, 31 Aug 2006 08:18:57 -0700 (PDT) backyard wrote: >--- "Chad Leigh -- Shire.Net LLC" >wrote: > >> >> On Aug 30, 2006, at 12:12 PM, backyard wrote: >> >> > with HT disabling in FreeBSD is more for the >> security >> > issues about a potential exploit whereby one >> process >> > in one pipe can access the priveledged information >> of >> > a process in another pipe because the two cores >> share >> > one processor cache and thus one cache table. To >> my >> > knowledge this hasn't been exploited yet. >> >> >> How is this any different than say an Intel Core Duo >> or Core 2 Duo? >> I believe they have a shared cache as well for each >> (real) processor >> core. I'm not sure about the Core Duo, but I think it has two separate, fixed-sized caches. The Core 2 Duo supposedly keeps a total of 4 MB of L2 cache, but dynamically manages how much is currently used by each core, still keeping what they use separate (i.e., each core can only access what is allocated to it). >> >> Chad >> >> --- >> Chad Leigh -- Shire.Net LLC >> Your Web App and Email hosting provider >> chad at shire.net >> >> > >I would say there is no difference if what you say is >true. A Multi-Core chip is only true SMP if the two >cores share no resources internally and thus are >capable of running process separate from each other >entirely. independantly and with their own internal >caches. The process shouldn't have to wait on a lock >to access it's cache, which I would have to assume >occurs on these HT machines; which is probably why >they have degraded performance. The cache should only >be shared if a process explicity copies its content to >the other cores cache. If should not be possible for >both Cores to see the same internal cache. To my Thus far, Intel's dual-cored processors do not have HT enabled, though the circuitry may well be present. Intel has said publicly that they may make HT available again at some point, so that each core would have two logical processors. If Intel does that, then presumably the FreeBSD kernel would need a third level of processor relationships in addition to the distinction between processors in the same group (i.e., logical processors in a particular real processor) versus processors in different groups (i.e., logical processors in different real processors). >knowledge the AMDx2 follow this model with independant >cores only sharing a common die. This ensures the >context and priveledge of one running process cannot >be compromised by a non-priveldeged process waiting on >say a login attempt to root, and then grabbing the >password from the common cache before the privelidged >process can clean up. Many people have panned HT, but HT does make it possible to keep more components of a real processor (e.g., DAT, TLB, FPU, address and data lines to the off- chip world, etc.) in active use more of the time. This is an issue that is separate from the issues involving multiple real processors on one die. It is, of course, too bad that Intel's design allows the logical processors to cross-access their cache spaces, but I doubt that that particular weakness has hurt anyone much. A greater problem for some installations is the accounting problem caused by the fact that a logical processor waiting for a hardware lock set by another logical processor in the same core appears to have 100% CPU utilization during the lockout. In other words, 100% utilization of both logical processors is equivalent to something on the order of 110% - 140% utilization of a single logical processor that has no competition from another logical processor. So which thread is getting overcharged? The software cannot determine the answer. And what institutional accounting policy should be in effect to handle billing for CPU time in an HT-enabled environment, given this indeterminacy? > >I don't think this flaw has been exploited yet, but >the boys at OpenBSD found it (from memory, pretty sure >it was one of them) and it has spread through the BSD >community as it has potentially dire consequences. > >Personally I'm done with Intel so I don't think I'll >ever have this issue. Afterall they're still the >reason my computer boots up with 640k of RAM... I also >think AMD has come from being a clone to being on top >of the market, but this is my personal opinion. The >fact Core Duos are only 32-bit means Intel is still >only concerned with shortend gains on the Windows >market, not long term migration to 64-bit PCs like That's not quite entirely true. According to the Intel web site, some models of Core chips don't list EM64T as a supported feature, but some of the *do*. The Core Solo and Core Duo series do not show EM64T as a feature, but the entire Mobile Core 2 Duo series, the Core 2 Extreme X6800, and the entire Core 2 Duo Desktop series do list EM64T as a supported feature. >everyone else... And banking on Microsoft has never >been a solid idea; its too bad banks use Windows; >there's a security nightmare, but a topic in and of >itself... Indeed. (Ugh!) > >-brian > Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************