Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: John Savard Newsgroups: comp.arch Subject: Re: Privilege Levels Below User Date: Tue, 11 Jun 2024 13:27:35 -0600 Organization: A noiseless patient Spider Lines: 71 Message-ID: References: <2024Jun9.185245@mips.complang.tuwien.ac.at> <38ob6jl9sl3ceb0qugaf26cbv8lk7hmdil@4ax.com> <2024Jun10.091648@mips.complang.tuwien.ac.at> <3a691dbdc80ebcc98d69c3a234f4135b@www.novabbs.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Date: Tue, 11 Jun 2024 21:27:38 +0200 (CEST) Injection-Info: dont-email.me; posting-host="f752231138247ec5b6f53ce61cda1d0c"; logging-data="1275443"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18ZvLwmMeBm5LpFYWTcOs0zQ9fYUAvkRRM=" Cancel-Lock: sha1:Wj0tzJoZGDe0we95SGpSYtAgOdQ= X-Newsreader: Forte Free Agent 3.3/32.846 Bytes: 4271 On Tue, 11 Jun 2024 00:27:02 +0000, mitchalsup@aol.com (MitchAlsup1) wrote: >ALL I have DONE is to not have the MB write into the cache until the >causing instruction retires !! I suppose that depends on how you define "write". If by "write" you mean store data in the cache, for eventual writing out into RAM, well, since RAM doesn't contain "rename locations" to play with, it seems to me that any CPU designer had better do that. At least, I'm not imaginative enough to think of doing it any other way. However, if by "write" you mean to change the state of the cache in any way, such as by reading data from memory... now, _then_ you would indeed have done what is necessary to combat Spectre. Obviously, though, a "load" instruction will _never_ retire unless it can read the data from memory it is trying to put in a register. So apparently WHAT you have REALLY DONE is to modify how memory reads work... if the data a load instruction requires is not already in the cache, then a direct read from memory is performed which *completely bypasses* the cache; this data (and its associated address) are retained by the CPU to be placed in the cache _if_ the instruction is actually executed and when it retires. And, in fact, the various cache levels have to work this way too. You have an L1 cache miss, but an L2 cache hit? Fine, you take your data directly from L2, and don't promote the data into L2 until instruction retirement. So now the process of fetching data from memory is _not_ done by fetching always from L1 and going _throughl_ L1 to access L2, and going _through_ L2 to access RAM, which seems to be the usual way these days. That certainly can be done. But it isn't quite as simple and obvious as you seem to claim. >My 66000 is also insensitive to RowHammer and derivatives..... When I first read that sentence, I was completely incredulous. DRAM is sensitive to RowHammer because it's gone to feature sizes which are beyond the state-of-the-art to do properly... so corners have been cut. How a CPU can be "insensitive" to it was mysterious. After all, RowHammer is caused by multiple rapid-fire accesses to the same address, or to related addresses, in memory. But given that you are now explicitly passing accesses to DRAM around the caches, instead of having the caches access DRAM as needed, perhaps that also makes it possible for the CPU to detect suspicious behavior more easily. (Since _relateld_ accesses may be used in a RowHammer attack, simply pruning redundant memory accesses from the operation stream won't be enough. I could see you doing _that_ as part of "doing it right".) If the "row" that was "hammered" just consisted of the 16 consecutive locations that can be accessed speedily after the first one is ready, then pruning reduntant accesses _would_ be enough, since to "hammer" a row one has to access it hundreds of times, not at most 32 times; but I'm afraid that isn't the case. John Savard