From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 1F0022194232C for ; Thu, 6 Apr 2017 03:16:19 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id t20so54094727wra.1 for ; Thu, 06 Apr 2017 03:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=vl26+FCNKI7uf8ug225iuAcWQ6l4cTxGl0UEJ6iouyM=; b=gyrhnW5vb90PnXUS+gupX5AChcltS7HqFhd0rbK0UbQlLdV8o469Kul6PaHSPKqLq8 hePs5S+SdTrF9qHpxZ5oyUtzCQwIK3UpOFN3r1wkzjdvPFCvQtWH/plZKoM8kFaR8k5l VAh8l8X7rfW3O7OecPFSQ4/tg93dIgdnEYWWg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=vl26+FCNKI7uf8ug225iuAcWQ6l4cTxGl0UEJ6iouyM=; b=ocpKlbzDVDZJIqisNpN8TzOQ8d4/c7yBHjQ5N1JxzizMWnpZ05zYzLKEnpFnQHQMLi 54qRZZsfypR3suVCRuZlLCZHclVnhReRfvYqJT71aIBNs62XwO1QrtUzhyvmBpe93HLU 9B6f1uRyByB9RbovUax+jSd2x7PMRRWX/nx1EO+mwPPG45HAIgpe9I0NtHW2mKuZywCT 2E7wsod2jngzMoFuj869bbGxtw2nurBdcdUhxiIiD8CYEuVNiBt+QUphskb4yAcx6KrM X2tTE5Ng55K6pKk0ti5FQPE6GbZDona2ODLXkv7vyt1BTnp+aXP0MNveR/tolgJl8j6T 3/Ew== X-Gm-Message-State: AFeK/H0dZFNlfT9KoQaelJjl8NxT69xn6+aBg/i0r0Eg8eIC2121kZY5ED09ZuPDw8/0JDbV X-Received: by 10.223.139.196 with SMTP id w4mr30307836wra.70.1491473777454; Thu, 06 Apr 2017 03:16:17 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id q129sm30567644wmg.1.2017.04.06.03.16.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 03:16:16 -0700 (PDT) Date: Thu, 6 Apr 2017 11:16:14 +0100 From: Leif Lindholm To: Ard Biesheuvel Cc: Jeremy Linton , "edk2-devel@lists.01.org" , "Gao, Liming" , "Kinney, Michael D" , Charles Garcia-Tobin , Dong Wei , Evan Lloyd Message-ID: <20170406101614.GV25239@bivouac.eciton.net> References: <1473429644-13480-1-git-send-email-ard.biesheuvel@linaro.org> <1473429644-13480-5-git-send-email-ard.biesheuvel@linaro.org> <8871a794-80f8-049f-5abc-ca1d4a8fb3a3@arm.com> <20170406093547.GR25239@bivouac.eciton.net> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [PATCH v5 4/4] MdePkg/BaseMemoryLibOptDxe ARM|AARCH64: disallow use in SEC & PEI phases X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 10:16:19 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Apr 06, 2017 at 10:43:57AM +0100, Ard Biesheuvel wrote: > On 6 April 2017 at 10:35, Leif Lindholm wrote: > > On Wed, Apr 05, 2017 at 10:55:49PM +0100, Ard Biesheuvel wrote: > >> >>> I think this is a problem because nowhere in the UEFI specs do I see such > >> >>> restrictions on those memory operations. > >> >> > >> >> Using device attributes for memory is something we should ban for > >> >> AArch64 in the spec. > > > > Yes, completely agree. And doing so is generally the result of > > misinderstanding the memory model (i.e., it probably won't provide the > > guarantee that was sought). > > Charles/Dong? Something to add to list? > > As an additional note, the UEFI spec mandates that unaligned accesses > are enabled for AArch64, which clearly expresses the intent that > routines operating on memory should be able to do so without going out > of its way to avoid unaligned accesses. It does - but only if you already understand the memory model. > > Can we insert a test preventing device memory type to be set for > > regions with _WB attribute? Or is that already only possible through > > manual trickery? > > We should simply remove the _UC attribute from all memory. I have > already done so for many of the platforms I more or less maintain (and > for virt, we removed _WT and _WC as well, because KVM only supports > _WB) Agreed. > Note that this does not prevent the NOR and RTC drivers from creating > _UC regions for their own MMIO registers, it just prevents them from > being remapped _UC via the DXE services. OK, good. / Leif