From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail05.groups.io (mail05.groups.io [45.79.224.7]) by spool.mail.gandi.net (Postfix) with ESMTPS id 0EC4C7803D0 for ; Wed, 24 Apr 2024 12:35:29 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=t79Awj1wWxWtoKIjsgtS1D78cUWvxtVZWOQpT3SR/XY=; c=relaxed/simple; d=groups.io; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Resent-From:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Disposition; s=20240206; t=1713962128; v=1; b=hNGYPPsQwxDn88KGjSkZxOpLM21ZoO0nK90Edl4m1vnba6taqbSNFGvHJKQIQz4VUCkGXtEb xkuDtMe0zJR1GUcJ2jg1p6koSFNF1bYfntnpV7SaD3IZbDgdtFQseOvGu9fB9HYn7HBZnPX6DsM oz5MmnBB8K5Sqq+xDotEzshlGo+u1mwmQQDulMEqAVbojtQqh28uz4paMZBdNygKP5MsNDmitbY wN0YsVFB1HTuNffd/OfapAHuWIhwJBOT9cjK1ANKxMhk3a6tI1in75ovR+/HyecTStQ6XigBVpx Fmdw3HfHcjVY6dQF5PNagGCnPcj5Wq7FebDU6aUdqSKPQ== X-Received: by 127.0.0.2 with SMTP id V8UEYY7687511xLWy6PtbcuE; Wed, 24 Apr 2024 05:35:28 -0700 X-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.15320.1713962127565339830 for ; Wed, 24 Apr 2024 05:35:27 -0700 X-Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-660-vplX56RkMnG_exlwvFIRZA-1; Wed, 24 Apr 2024 08:35:21 -0400 X-MC-Unique: vplX56RkMnG_exlwvFIRZA-1 X-Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4466D1C0C64C; Wed, 24 Apr 2024 12:35:21 +0000 (UTC) X-Received: from dobby.home.kraxel.org (unknown [10.39.192.254]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 01659C01595; Wed, 24 Apr 2024 12:35:20 +0000 (UTC) X-Received: by dobby.home.kraxel.org (Postfix, from userid 1000) id 6D850F6368; Wed, 24 Apr 2024 14:35:19 +0200 (CEST) Date: Wed, 24 Apr 2024 14:35:19 +0200 From: "Gerd Hoffmann" To: "Wu, Jiaxin" Cc: "devel@edk2.groups.io" , Ard Biesheuvel , "Yao, Jiewen" , "Ni, Ray" Subject: Re: [edk2-devel] [PATCH v3 08/13] OvmfPkg/PlatformInitLib: Create gEfiSmmSmramMemoryGuid Message-ID: <74uoxthjxoztfpmnt552eysn2u2blko6tkllnk3a76ax46yf5d@y34m4b4h6t57> References: <20240418065556.5696-1-jiaxin.wu@intel.com> <20240418065556.5696-9-jiaxin.wu@intel.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Resent-Date: Wed, 24 Apr 2024 05:35:27 -0700 Resent-From: kraxel@redhat.com Reply-To: devel@edk2.groups.io,kraxel@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: bx3IS9m04Yxia4UobOWPRAtmx7686176AA= Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240206 header.b=hNGYPPsQ; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 45.79.224.7 as permitted sender) smtp.mailfrom=bounce@groups.io Hi, > > First, smram allocation doesn't work that way. Have a look at > > OvmfPkg/SmmAccess. I guess that easily explains why this series > > breaks S3 suspend. > > Oh? Could you explain a bit more for 1) how smram allocation works? 2) what's the possible reason break the S3? I haven't check yet. SmramInternal.c handles that. It creates two regions, one is a page at the start of SMRAM where S3 state is stored (and marked as allocated), one is all the rest. So, if you need some smram to initialize SMM in PEI I'd suggest to either add a third region, or make the first region larger. It's not clear to me why you put the logic upside down and introduce that HOB in the first place. > > Second, storing these descriptors in a HOB (which is PEI memory) > > is questionable from a security point of view. > > HOB is only to expose the SMRAM address and size, not the contents in smram, what's the security concern? Storing anything SMM related outside SMRAM makes me nervous. I'd strongly suggest to avoid that. It might be that in this specific case it is not a problem. But it needs very careful review of the implications (which I have not done) and you have to hope you don't miss a possible attack vector, such as someone modifying the HOB and the firmware then storing SMM data + code outside SMRAM. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#118212): https://edk2.groups.io/g/devel/message/118212 Mute This Topic: https://groups.io/mt/105593577/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-