From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 600A580467 for ; Mon, 20 Mar 2017 07:09:15 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id y18so34648323itc.0 for ; Mon, 20 Mar 2017 07:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wumdQkyWBUqT8wMuXKTl2hLFTwZJPo0PjEz34q0hQ8Q=; b=alErLVLj1MxGW04i/qno+MnM7KCqHZFG+G3IzpqV5IgVE6tqyuAi3Q/wnI8eIL9j3X Fu4Nv93lLD0wTMzH2xv65Ul7zCUDjE3TMurwI6B55gC1m1f85xktyNhtKAIQ6qx8ZXCg 7nskRfKVNuQkXV21QZ6TC7ToKpize0aofBChE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wumdQkyWBUqT8wMuXKTl2hLFTwZJPo0PjEz34q0hQ8Q=; b=S8LkctH8kAr0rVBJ3iDgosK06kCAOFisi3aL5f+7RoLBI2TBTcZp1NnIdafyQR+OLV mb5vVgrJJzlQQUaWLFDLU+Omf7+LztuntBcHLeUXBSi/ovlVtnZBrYryoq6rRwahN7Q7 r3KCjcBWiMXMBjthtPD/Bdm1RqfUMmJIIrfEMYsmYYZJ/8kB5HrN/ki7hj6Ps0rb8KOP hqUe4asWvmZ3ENljFQbOM6g1khouHBRhRRwel5DEQBLepBCtM5KYrghLLsim48d48dNT NPb5K2CT/jMKL0CgyPQNs5ZwzkK2fwJEvF/lxcM3YKwxD38HvPNZkaUhQVus9ekjfJ80 kyaw== X-Gm-Message-State: AFeK/H0nBjGE2sZuhjLgKP9PEgCJbzqB8Y1mDDTRx0EpZfL1zsCOm871G9HuH/pCrWbq3W0JRZw52J3WnzK3No6R X-Received: by 10.36.77.10 with SMTP id l10mr9220093itb.59.1490018916045; Mon, 20 Mar 2017 07:08:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.27 with HTTP; Mon, 20 Mar 2017 07:08:35 -0700 (PDT) In-Reply-To: <72d13754-5c7d-9734-33a8-bd2dab32b2bb@redhat.com> References: <72d13754-5c7d-9734-33a8-bd2dab32b2bb@redhat.com> From: Ard Biesheuvel Date: Mon, 20 Mar 2017 14:08:35 +0000 Message-ID: To: Laszlo Ersek Cc: Michael Zimmermann , edk2-devel-01 Subject: Re: SetMemorySpaceAttributes with EFI_MEMORY_XP 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: Mon, 20 Mar 2017 14:09:15 -0000 Content-Type: text/plain; charset=UTF-8 On 20 March 2017 at 11:38, Laszlo Ersek wrote: > On 03/20/17 12:20, Ard Biesheuvel wrote: >> On 20 March 2017 at 11:16, Michael Zimmermann wrote: >>> Ard, why is SetMSetMemorySpaceAttributes being called in first place? >>> (ignoring the recent NX patch) >>> Looking at the initial GCD, it looks like unused memory usually >>> doesn't have any attributes set anyway. >>> >> >> Originally, we added the new memory with >> EFI_MEMORY_WB|EFI_MEMORY_WT|EFI_MEMORY_WC|EFI_MEMORY_UC capabilities, >> and selected the EFI_MEMORY_WB attribute with the call to >> gDS->SetMemorySpaceAttributes. Later, we removed all capabilities >> expect EFI_MEMORY_WB, since the other ones cannot be supported under >> virtualization with KVM. >> >> Whether that makes the SetMemorySpaceAttributes redundant is not >> entirely clear to me, but it does appear the adding the memory does >> the right thing wrt non-exec permissions if the policy is enabled. So >> perhaps we can simply drop this call? > > Won't that turn off caching for the memory just added? > I think it may not map the memory at all in this case, so we need to do something. It looks like calling mCpu->SetMemoryAttributes() should be sufficient here, and so I wonder whether we violate anything by replacing gDS->SetMemorySpaceAttributes with mCpu->SetMemoryAttributes here.