X-Received: by 2002:a17:90a:aa0e:b0:1bc:dbe9:1b20 with SMTP id k14-20020a17090aaa0e00b001bcdbe91b20mr998742pjq.214.1645720797406; Thu, 24 Feb 2022 08:39:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645720797; cv=none; d=google.com; s=arc-20160816; b=cE/H2n8M5GJzRndPlVBxbVCOe/E4yxrzQWY+S4Q/l6S+4MNPKxSWl1WKakhsI9Zqba /qA/0auDM+bn1+POTnQOq+AFXQkJADV/frDWFewAWQInq8k/wlnqeNgKbNjtFrMQ+33R svd88XQjuDDtmC1ZdlHXXIoAHem2wW2uYTidSmebniK2HTK9lj3KBGq58HYlpZpH+0Hz 5+0/p51pTcNW7klDvHKd9So9BvM9d1kzBbkl3lWCKuOk/MOenRTDwZSd/sSklrHBdXDR 1vFQva3j8ipESgQzjME9AxevZihqDuG0irGdo3nESPCbz20eQ/0/vyJ13ewkNe9SzP3G wUOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=DT5IMHFZ3KDaEtsX9PE91X6QzCW9Hum5wpSsTnsLsQc=; b=iyklqtspHXyLu7hmQDsfOBXTmYWAlcksqt+ZX+7PTRaUsXVCm9EDpGM3iYbiLiTPCY 0nYKrN4klBSCvHNWRxes81nQpXxrHREmU6ZOZBTxwUj0Ksxo7FehTAIC0SpAVQHBzbI1 2RPFSkPbMfL5HGerHxQ9dcIKRBQUdvezCE4HtN8qaT0WKv9Xtp4jPDArgKjbTDL0hTUc YpW7Hxg8ugJ9vtTl6t5+6WDaDyurW2XeP3B8gbRexs/mSWVDcTl2r/iuaa34pYsjXJF3 CWMzVLzlRtVdulooBP0W5aPGBb3SyHwryQO5iHbiTHCmeemTMtlDK8qV9P+kY66pgc4g +p+w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ispras.ru Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id h12si2999032pfc.297.2022.02.24.08.39.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Feb 2022 08:39:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ispras.ru Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 68E79104A74; Thu, 24 Feb 2022 08:21:47 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236540AbiBXPz2 (ORCPT + 99 others); Thu, 24 Feb 2022 10:55:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39942 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233573AbiBXPz1 (ORCPT ); Thu, 24 Feb 2022 10:55:27 -0500 X-Greylist: delayed 597 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Thu, 24 Feb 2022 07:54:56 PST Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C452116DADC; Thu, 24 Feb 2022 07:54:56 -0800 (PST) Received: from localhost.localdomain (unknown [80.240.223.29]) by mail.ispras.ru (Postfix) with ESMTPSA id A1B6240D403E; Thu, 24 Feb 2022 15:44:52 +0000 (UTC) From: Baskov Evgeniy To: Ard Biesheuvel Cc: Baskov Evgeniy , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH RFC v2 0/2] Handle UEFI NX-restricted page tables Date: Thu, 24 Feb 2022 18:43:28 +0300 Message-Id: <20220224154330.26564-1-baskov@ispras.ru> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is another implementation of this patch. It uses DXE services to change memory protection flags as you suggested earlier. As I mentioned, you can reproduce this issue with any firmware, including OVMF by setting the PcdDxeNxMemoryProtectionPolicy policy: gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy|0x7FD4 Restricting the user from creating executable pages is not an goal, but restricting one from creating both executable and writable pages is a goal, which is enforced in the firmware we use. We cannot allow allocating pages of any type that have RWX permissions. gDS->SetMemorySpaceAttributes() is technically part of the UEFI PI specification, so it is not too bad to rely on it. However: - DXE services is not something designed to be used by an UEFI application. - From what we know, no other operating system uses this interface, which means that it can easily break in production firmware on the boards we do not control before anyone could even notice. We do not strictly mind experimenting with this route, but it would be preferable for this interface to become more standard in this case: move it to UEFI Boot Services or a separate protocol and include it in UEFI conformance suite. It will also help if we enable this feature in Linux by default. Baskov Evgeniy (2): efi: declare DXE services table libstub: ensure allocated memory to be executable arch/x86/include/asm/efi.h | 5 ++ drivers/firmware/efi/libstub/efistub.h | 53 ++++++++++++++++++++ drivers/firmware/efi/libstub/x86-stub.c | 73 ++++++++++++++++++++++++++-- include/linux/efi.h | 2 + 4 files changed, 128 insertions(+), 5 deletions(-)