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.web08.3562.1654671185767821064 for ; Tue, 07 Jun 2022 23:53:06 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=MeAQjjQh; 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=1654671184; 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: in-reply-to:in-reply-to:references:references; bh=yP/seWyKvp8xX7zvSiR66jKYm1/z5MeGQOriO+8/st8=; b=MeAQjjQh2c2cA9VwFYAd24H8rfAXSvXwHdmf8FlgF6m1ehgo8t/ngch4JqUn1HXtnYLDRW Cm8cqLKzWJsPwo9w3PRJMFFoAGZ5O6QjttIuLTWcEwq1yDbxPd1wU6tm7Ujr/bhwFvIplQ ZgmZUqKF8C8Nfj2RwewQlmwbw2gdbqw= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-396-_D_VMUWhOvSCZdIMTUWurQ-1; Wed, 08 Jun 2022 02:53:01 -0400 X-MC-Unique: _D_VMUWhOvSCZdIMTUWurQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 07E788027EE; Wed, 8 Jun 2022 06:53:01 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.40]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A91CA2026D64; Wed, 8 Jun 2022 06:53:00 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 2CD0018003AA; Wed, 8 Jun 2022 08:52:59 +0200 (CEST) Date: Wed, 8 Jun 2022 08:52:59 +0200 From: "Gerd Hoffmann" To: "Ni, Ray" Cc: "devel@edk2.groups.io" , "Liu, Zhiguang" , "Dong, Guo" , "You, Benjamin" , "Rhodes, Sean" Subject: Re: [edk2-devel] [PATCH] UefiPayloadPkg: Always split page table entry to 4K if it covers stack. Message-ID: <20220608065259.xfl3o22hgoq3r6wi@sirius.home.kraxel.org> References: <20220531053937.19696-1-zhiguang.liu@intel.com> <20220531074513.fciegyxkrgiwwqem@sirius.home.kraxel.org> <20220531112147.pvy4d6vetsgsqduu@sirius.home.kraxel.org> <20220531153206.fkq442gz4divb6xa@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > > > But I still have some doubts about using linux-style page split. > > > Because it's marked as not present: > > > 1. Active code should not access data in the 2M region (stack is in the 2M region in our case) > > > 2. Active code should not in the 2M region (how to guarantee that?) > > > > > > How does Linux guarantee the above two points? > > > > Easy. It's kernel code changing mappings for userspace, so no need to > > worry about code removing its own mappings in the first place. It's a > > different story for edk2 though ... > > > > Can this be covered by the page fault handler? Update the entry like > > the current code does, except for clearing the present bit, then flush > > tlb, then set the present bit. In case we take a page fault the only > > action the handler must do is enable the present bit, which might even > > be possible to do without additional state tracking. > > It's a bit heavy from my perspective. > I prefer to split the page to 4K in the very beginning of stack setup. > It also guarantees such issue doesn't appear. Yes, avoiding hugepages being created in the first place will surely fix that specific case. The commit message should describe the problem better, otherwise I'm fine with the patch. But I think there are more cases where edk2 splits huge pages. HeapGuard comes to mind for example. So I'm wondering whenever there are more simliar problems in the code base. take care, Gerd