From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mx.groups.io with SMTP id smtpd.web11.34226.1599208601990270451 for ; Fri, 04 Sep 2020 01:36:42 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=RisDyzV7; spf=pass (domain: redhat.com, ip: 63.128.21.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1599208601; 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=RSr4zXQ2Uls/IhV3O5bskKi/H8sSn3SIlZIJzKUK87U=; b=RisDyzV7LjI3fz8R5f85WO3R58xwGeI+zC347mkYNJh1asN2AeSiK1NrNjLdi/SEnomJpD tyRXdQh4N91z9p4iaddOIKdcGR+gWFhnNAEm4JugJOoWuz+4RReQI66HWBVsui4GnRztzd 9fYPga/b12UFADdWXgs6jQ1SN0Focxc= 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-30-0MhCVOXFPnS8cVWHT-JDGA-1; Fri, 04 Sep 2020 04:36:37 -0400 X-MC-Unique: 0MhCVOXFPnS8cVWHT-JDGA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0F6541005E67; Fri, 4 Sep 2020 08:36:36 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-161.ams2.redhat.com [10.36.112.161]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7673C7E417; Fri, 4 Sep 2020 08:36:33 +0000 (UTC) Subject: =?UTF-8?B?UmU6IOWbnuWkjTogW2VkazItZGV2ZWxdIFtQQVRDSCB2Ml0gVWVmaUNwdVBrZy9NcEluaXRMaWI6IEFkZCBjaGVjayBmb3IgQ1IzL0dEVC9JRFQu?= To: "Yao, Jiewen" , "devel@edk2.groups.io" , "vanjeff_919@hotmail.com" , "Dong, Eric" , "Ni, Ray" Cc: "Lou, Yun" References: <20200903151147.1196-1-eric.dong@intel.com> <9c9d8289-4f8e-75d8-2816-750195a54842@redhat.com> From: "Laszlo Ersek" Message-ID: Date: Fri, 4 Sep 2020 10:36:32 +0200 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0.002 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US On 09/04/20 10:06, Yao, Jiewen wrote: > When we say “validate”, we need get clear on what is the contract between caller and callee, and what is the expectation of the validation. > > For example, in this case, the validation is limited to 4G or not 4G. Why? > This function does not verify following, why? > > 1. if the GDT table is valid. > 2. if the IDT table is valid > 3. if the exception handler is valid > 4. if the timer handler still works > 5. if the page table is valid > 6. if the page table is 1:1 mapping > 7. if the page table still enforce the expected protection, such as RO, NX > 8. …… Yes, very good point; it has crossed my mind before too. The currently proposed checks verify the CR3 (but not the end of the root page directory). They also don't try to walk the whole forest of page tables and check every entry against 4GB (or, as you say, for 1:1 mapping). The check covers the GDT and the IDT, but not the GDT and IDT entries (segment granularity? direction of growth?) I'm OK with the proposed rudimentary checks because in my mind they are supposed to catch only one idiosyncratic UEFI application. > If an application creates a crazy state, CpuDxe may pass the validation with below 4G page table, but still fail to wake up APs. Yes, absolutely. > > If it is the app’s responsibility to ensure the system in good state, the validation is unnecessary. > If it is the CpuDxe’s responsibility to ensure the system in good state, the validation is insufficient. Agreed on both counts. I'm just under the impression that Eric has some internal use case that doesn't let him fix the application -- or maybe there's no time left for them for fixing the application. > > I think we should wait. I am working with Eric to collect the requirement on why test case is designed in this way. Sounds good, thanks! > > DebugAgentDxe is a good case. It is for debug purpose. > I believe there must be contract between CPU driver and DebugAgentDxe that which status DebugAgentDxe may modify and which state DebugAgentDxe may not. > It is DebugAgentDxe’s responsibility to ensure the new system state is correct and compatible with the CPU driver. Agreed 100% > With the contract, I don’t think CPU driver need validate the system state changed by DebugAgentDxe. > If DebugAgentDxe put system in a wrong state, CPUDriver has no chance to run. Agreed again. Thanks Laszlo