From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.120])
 by mx.groups.io with SMTP id smtpd.web09.6017.1578479772411944444
 for <devel@edk2.groups.io>;
 Wed, 08 Jan 2020 02:36:12 -0800
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=EqLoZ1Rh;
 spf=pass (domain: redhat.com, ip: 205.139.110.120, mailfrom: lersek@redhat.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1578479771;
	h=from:from:reply-to: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=7YhfKMhwV81QRK8gg0ZGh7BY5b1R4+iRY1dpnTzA1WY=;
	b=EqLoZ1Rh3MFh/yqNs3uFNrvZnEDdjCMh7uDR7tOL4k/6Cxb8tz8Rl3cj0N4qnvKfyBvVt0
	X/gfqttUFqepW3eaas2se43NmQFNg0DMG1Y6f+QWyD8eJVAQwQDM8p9ST/BBERVtyosQcu
	0pfkPRXQem2badWAI6j8xT3l5xbhkTU=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-28-6TZe6FYiOq64nKjIPTH99A-1; Wed, 08 Jan 2020 05:36:08 -0500
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DC17A107ACC4;
	Wed,  8 Jan 2020 10:36:06 +0000 (UTC)
Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-37.ams2.redhat.com [10.36.117.37])
	by smtp.corp.redhat.com (Postfix) with ESMTP id 4BB9E5D9E1;
	Wed,  8 Jan 2020 10:36:05 +0000 (UTC)
Subject: Re: [edk2-devel] [Patch 0/2] Shadow microcode patch according to FIT microcode table.
From: "Laszlo Ersek" <lersek@redhat.com>
To: Siyuan Fu <siyuan.fu@intel.com>, devel@edk2.groups.io
Cc: michael.d.kinney@intel.com, liming.gao@intel.com, eric.dong@intel.com,
 ray.ni@intel.com, Tom Lendacky <thomas.lendacky@amd.com>
Reply-To: devel@edk2.groups.io, lersek@redhat.com
References: <20200108042525.408-1-siyuan.fu@intel.com>
 <27dad7c9-0b89-4edb-6b5b-a47820068fe4@redhat.com>
Message-ID: <46741ce3-6d78-d4a4-8f3d-822b1d49cd07@redhat.com>
Date: Wed, 8 Jan 2020 11:36:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <27dad7c9-0b89-4edb-6b5b-a47820068fe4@redhat.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
X-MC-Unique: 6TZe6FYiOq64nKjIPTH99A-1
X-Mimecast-Spam-Score: 0
Content-Language: en-US
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

On 01/08/20 10:42, Laszlo Ersek wrote:

> In closing: it seems short-sighted that the FIT specification placed a
> "naked" pointer at a fixed offset in flash, rather than a three-field
> structure consisting of:
> - a GUID,
> - preceded by a structure size,
> - preceded by the FIT pointer.
> 
> Because, using a GUID-ed approach, the chance to *incorrectly* deduce
> "yes FIT" would be 1 in (2^128) -- all 128-bit values except one magic
> value would indicate "no FIT". That's good.
> 
> Whereas, with the spec's current "naked pointer" approach, the chance to
> *correctly* deduce "yes FIT" is 3 in (2^64) -- all 64-bit values except
> three magic values indicate "yes FIT". Not good.

Sorry I messed up the first half of the last paragraph. I meant:

With the spec's current "naked pointer" approach, the chance to
incorrectly deduce "yes FIT" is ((2^64)-3) in (2^64). So an incorrect
decision is almost certain.

Thanks
Laszlo