From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124])
 by mx.groups.io with SMTP id smtpd.web10.50348.1680254191431895413
 for <devel@edk2.groups.io>;
 Fri, 31 Mar 2023 02:16:31 -0700
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=XGcUa9QO;
 spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1680254189;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=iaucaz/gwlyjgIhgb+CHx0lLdlRhZBh1ZninI/b0oto=;
	b=XGcUa9QOR+l4oUQiw68xCePAg7V6C6LpZlChkwSeRF5CjeHfyyaSWtTqiBHTNeAzeaM3Dc
	ZWi1D6Z6yOsDfaOUt7kFQNLVmjDMmoPN/atSwNozbpKzfOPXT3N5NAsLwDgtt5oPcCU9YP
	ypI+kK13wJqXJ5TcFjv+Cjbob93laJo=
Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com
 [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 us-mta-156-AOwgGgB0NPiqp1SBmbkpRQ-1; Fri, 31 Mar 2023 05:16:28 -0400
X-MC-Unique: AOwgGgB0NPiqp1SBmbkpRQ-1
Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mimecast-mx02.redhat.com (Postfix) with ESMTPS id BBD33280A325;
	Fri, 31 Mar 2023 09:16:27 +0000 (UTC)
Received: from sirius.home.kraxel.org (unknown [10.39.193.100])
	by smtp.corp.redhat.com (Postfix) with ESMTPS id 7147A14171B6;
	Fri, 31 Mar 2023 09:16:27 +0000 (UTC)
Received: by sirius.home.kraxel.org (Postfix, from userid 1000)
	id 7857618000A3; Fri, 31 Mar 2023 11:16:25 +0200 (CEST)
Date: Fri, 31 Mar 2023 11:16:25 +0200
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: Marvin =?utf-8?Q?H=C3=A4user?= <mhaeuser@posteo.de>
Cc: Ard Biesheuvel <ardb@kernel.org>, devel@edk2.groups.io, 
	Rebecca Cran <rebecca@bsdio.com>, Andrew Fish <afish@apple.com>
Subject: Re: [edk2-devel] [RFT PATCH v2 1/6] BaseTools/tools_def XCODE: Link X64 with -read_only_relocs suppress
Message-ID: <pcbx5cug2wz2t2ct5zysi34szjgrjayzkhl7vvzxrbkkwmkgsd@pzomno2xjjlt>
References: <CAMj1kXG5AAzRE4gBCm3i8MxkP65Ji4XOEjwox5Lr3s_xRQg1wg@mail.gmail.com>
 <943BFDDF-6EF6-42BD-9173-E3D26DCE0E0A@posteo.de>
MIME-Version: 1.0
In-Reply-To: <943BFDDF-6EF6-42BD-9173-E3D26DCE0E0A@posteo.de>
X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

  Hi,

> > - modify the SecPei version of CpuExceptionHandlerLib to put the
> > vector templates in .data, as I proposed before. This works around the
> > issue, and given that SEC/PEI is assumed to be read-only anyway (as it
> > may execute in place from flash) and does not use page alignment for
> > the sections due to size constraints, it is reasonable to assume that
> > .text and .data will be mapped executable anyway.
> 
> Well, that assumption is more than fair to make for the status quo
> platforms, but this is just another rock in the way of doing things
> the right way (even if it’s just VMs).
> 
> Cc Gerd for an OVMF security perspective. Is PEI-time memory
> protection something you’d be interested in in the future?

Given that PEI is expected to be able to run from read-only storage
the easiest way to apply X^W rules would be to just map the whole
PEI firmware volume as R-X when executing from RAM (which is the case
for OVMF).

I've fixed OVMF PEI modules last year to *not* use global variables,
so OVMF is not a special case any more and mapping OVMF PEI readonly
should work just fine.

So Ard's approach looks sane to me.

take care,
  Gerd