From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: tuhs-bounces@minnie.tuhs.org X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.1 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 83fc0147 for ; Tue, 26 Jun 2018 22:34:17 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id EAE78A18B7; Wed, 27 Jun 2018 08:34:16 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id B20EAA18AB; Wed, 27 Jun 2018 08:33:54 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 2AD79A18AB; Wed, 27 Jun 2018 08:33:54 +1000 (AEST) Received: from p3plsmtpa07-02.prod.phx3.secureserver.net (p3plsmtpa07-02.prod.phx3.secureserver.net [173.201.192.231]) by minnie.tuhs.org (Postfix) with ESMTPS id 6B30EA189F for ; Wed, 27 Jun 2018 08:33:43 +1000 (AEST) Received: from medusa.kilonet.net ([72.69.223.155]) by :SMTPAUTH: with ESMTPA id XwWsf08KXU3O0XwWsfehRB; Tue, 26 Jun 2018 15:33:42 -0700 Received: from [199.89.231.101] (ender.kilonet.net [199.89.231.101]) by medusa.kilonet.net (8.14.8/8.15.1) with ESMTP id w5QMXfkQ006331 for ; Tue, 26 Jun 2018 18:33:41 -0400 (EDT) To: tuhs@minnie.tuhs.org References: <1f8043fd-e8d6-a5e6-5849-022d1a41f5bf@kilonet.net> <20180626215012.GE8150@mcvoy.com> <20180626215905.GH8150@mcvoy.com> <117BE24B-C768-43ED-A470-40FCD1662ECD@bitblocks.com> From: Arthur Krewat Message-ID: <769e0f86-eb90-0ec5-e744-319ab74dbd85@kilonet.net> Date: Tue, 26 Jun 2018 18:33:37 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <117BE24B-C768-43ED-A470-40FCD1662ECD@bitblocks.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-CMAE-Envelope: MS4wfE8SwI7VXnt5H7rM4ii0bN9dxAql4wZhik6ozQuJj10lqqR9r2Q+QQhXT1U/wyb4PV+Z4lxesOIBfvVA0+xSdOTIxyuRA1PnzHynoONNcKdF10XbnSu6 Bhc4JOHSFe7/I2rqa/mNEbgBRpEZrmYot+cE8VH2QE80VVkJk9zvs3d8K4Sib1Dfr9aPLE+6QNutFg== Subject: Re: [TUHS] PDP-11 legacy, C, and modern architectures X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 6/26/2018 6:20 PM, Bakul Shah wrote: > it is becoming increasingly clear that > caching (hidden memory to continue with the illusion of a simple memory > model) itself is a potential security issue. Then let's discuss why caching is the problem. If thread X reads memory location A, why is thread Y able to access that cached value? Shouldn't that cached value be associated with memory location A which I would assume would be in a protected space that thread Y shouldn't be able to access? I know the nuts and bolts of how this cache exploit works, that's not what I'm asking. What I'm asking is, why is cache accessible in the first place? Any cache offset should have the same memory protection as the value it represents. Isn't this the CPU manufacturer's fault? art k.