From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on072e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe44::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id EC8FE1A1ED0 for ; Thu, 13 Oct 2016 06:20:12 -0700 (PDT) Received: from AT5PR84MB0276.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.22) by AT5PR84MB0273.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Thu, 13 Oct 2016 13:20:11 +0000 Received: from AT5PR84MB0276.NAMPRD84.PROD.OUTLOOK.COM ([10.162.138.22]) by AT5PR84MB0276.NAMPRD84.PROD.OUTLOOK.COM ([10.162.138.22]) with mapi id 15.01.0659.020; Thu, 13 Oct 2016 13:20:11 +0000 From: "Anbazhagan, Baraneedharan" To: Paolo Bonzini , Laszlo Ersek CC: "edk2-devel@lists.01.org" Thread-Topic: [edk2] SmmCommunicationCommunicate question? Thread-Index: AdIlA3HcA9E3oGk2RRupWmjny+OfugALdM+AAAekXwAAARd7wA== Date: Thu, 13 Oct 2016 13:20:11 +0000 Message-ID: References: <1c6dc322-d226-4146-e38b-5aa280659ce5@redhat.com> In-Reply-To: <1c6dc322-d226-4146-e38b-5aa280659ce5@redhat.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=anbazhagan@hp.com; x-originating-ip: [66.135.176.178] x-ms-office365-filtering-correlation-id: 805cafc8-44e1-4be3-87c0-08d3f36ba923 x-microsoft-exchange-diagnostics: 1; AT5PR84MB0273; 6:QniRDEaqhbFwPGaprsnXMropylLgXPBq0G8Yy3sk789R2e/5JAD7aMd+bmKPVHaIRKbBsx0mXD3CLFvM2UkCHtj5uFAOMeH4Zv61zBIAJGnCQ9FGhJWIWs2dikKGmlPUEMturlk+8K7jpK8hVh3VnV9r+UpMZi9biYpxBTI5r3RUpWcAgtLyl8ZT641GVS17GW9UvMXp02o+JsagiGJa7l4n3BgdkoRi4073VwPfpGbix1Fbm5rVdmGbnB6J3nSjoYR4RXi+iONIAt/BFwomFl16OGWNA3pxk1g6jCpc6E7hns1ZZ73inrx3TlAk/ZHV; 5:3pAMRX99cX02mmpFy3ft0Vk3D1qJzt606K/5RUrNR1JLm65xBIelApDImyFTnGuiBGsfvorQcHpNjC7Rssjf3TKAa3tyYpa6ffpYnZzgGGQ1wUHjCgVft7qLK4TaTO/75QATaz8ZXHwRLGNxZRO41ouiqOOdRNeJmtu3hWAy8tI=; 24:GkxP6PPRxtfjCm6jSYsxSrOD28t/K8GNodS9xhHfNIgwXwUJLG5bjjSUsDLrYGFYTPwMFWKM/3Wy6rtasXARRYudyM4Mtgo2duQm7A4Dhfk=; 7:2AzjAk3pYcX4xt1wg8JZ/8A92KaEUVQ3VKIf9KvNlRiHfC7HYkE+RjFol0uWT3Zi9LfuDpQ6dwqT96hz83dY1viJdKAU9TTADEeY4wr4dUM0E6WPmCycn4igrNP8+0Kfvsv1xzQFhLTB2N/k4s00I9qSyxttKPyq6wJkybo8ogHYJ6RTId7VsYBebx5QspAd3MhWR9QOeIWYeMw+OS/UK174P7AfbaHdVeuoDqhc1E8jvRox+5+ZXywMHvoV4X45uuSKIgnzNuVGLNaErDj0ePa3HkhWUrV6MnoJGIWsfQ5TJ+UitsMRdonMXMqc8QHFE7tIc3hoA80E8wfIVVjwGtakiGyEYoKju4kV0STrDiE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AT5PR84MB0273; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AT5PR84MB0273; BCL:0; PCL:0; RULEID:; SRVR:AT5PR84MB0273; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(6602003)(24454002)(189002)(5001770100001)(5002640100001)(7846002)(2906002)(8676002)(5660300001)(7696004)(8936002)(4326007)(2950100002)(9686002)(77096005)(87936001)(81156014)(7736002)(81166006)(86362001)(6116002)(54356999)(105586002)(2900100001)(106356001)(99286002)(102836003)(3846002)(11100500001)(19580395003)(68736007)(586003)(3280700002)(101416001)(19580405001)(305945005)(33656002)(76176999)(50986999)(97736004)(74316002)(92566002)(189998001)(3660700001)(10400500002)(66066001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:AT5PR84MB0273; H:AT5PR84MB0276.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: hp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: hp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2016 13:20:11.2879 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ca7981a2-785a-463d-b82a-3db87dfc3ce6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR84MB0273 Subject: Re: SmmCommunicationCommunicate question? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 13:20:13 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo B= onzini >=20 > On 13/10/2016 11:07, Laszlo Ersek wrote: > > > > Instead, once the first CPU enters SMM, it brings all the other CPUs > > into SMM as well, where they will be executing known, secure code -- > > i.e., the first CPU to enter SMM forces the other CPUs to temporarily > > abandon any (possibly malicious) code the runtime OS may have prepared. > > Only *then* will the verification of the communication buffer commence. > > If the malicious code managed to race the unpriv part of the service > > successfully, now the privileged part will catch that, undisturbed. >=20 > Even this is not strictly necessary if you can set aside some memory in S= MRAM for a > copy the communication buffer. Then you can do: >=20 > tmp =3D comm buffer size > if tmp > sizeof(privileged buffer) > return error > copy tmp bytes from comm buffer to privileged buffer >=20 > and not look anymore at the buffer provided by the user. >=20 > Of course, "bring all CPUs into SMM" can double as a poor man's mutex, so= there > may be reasons to do that anyway. >=20 > Paolo Am thinking in BDS phase - if a module have periodic callback and uses SmmC= ommunicate within the callback, then it could potentially overwrite those g= SmmCorePrivate pointer while another module trying to use SmmCommunicate.