From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) by mx.groups.io with SMTP id smtpd.web10.2617.1689198845348083786 for ; Wed, 12 Jul 2023 14:54:05 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="signature has expired" header.i=@taylorbeebe.com header.s=google header.b=CQTiBC/O; spf=pass (domain: taylorbeebe.com, ip: 209.85.210.182, mailfrom: t@taylorbeebe.com) Received: by mail-pf1-f182.google.com with SMTP id d2e1a72fcca58-668709767b1so49613b3a.2 for ; Wed, 12 Jul 2023 14:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=taylorbeebe.com; s=google; t=1689198844; x=1691790844; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=0howJDYd/AsgKe1Gx/olYlYGT7XzZRoC0/TX1BsibGo=; b=CQTiBC/OdJfSiTZWemJMqvRDoqwQnoRC5C0adZz92JEtnVy2E1W1pJopfgMrH3SP/A 7a3R/F+M3IASpZAmzhjhQ2kDQqocJZfL8WLoGaKW3n6SCAzvhEH4cDv0Q2qwmQDKeVCl Vwyitg7yF1Dyvy7g+SnOAaxveDT0DxVwxJA5/Z/JLJlhDkC79WJGP6T/fgXSZgewG0L1 U0GRmtfuOXe0wj6I/uBfOE2xfhlOy+L59TdchYMzQIen2bo5vBVbV+qIknu3Ty6XxbJ8 Cl8/Rzgus++EOnvOWinyUdhpxZfv2u6GiyR2HZ7jh7/0KMnBWG8y597jzQ2UjSO5mY1C avHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689198844; x=1691790844; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0howJDYd/AsgKe1Gx/olYlYGT7XzZRoC0/TX1BsibGo=; b=WAePriO9F638/7S6/uG+lHte+1SCyW1L7u8zHb7lNTJ4jp7l4C5jwbg9HlPH5tI783 SvN8+3WqDzNOPhFD6XW0h3NbLFDFCEw1CRbbDxSDsM6oJf5ZDT1Y4HZiFjVehua4/jSo jhwMIqcq1RS94do3HOSX+4Hao0Oa4R9gMGiXd8YHjY/qKW/7RO0Rx9di6A4j8BHbKC5R 9UUOeAO5K8hqBkoGvpyEkuuQy/TOHxQSD+8PH/7X5GCuN/q81ByeTIqmpi2LCx1t3YjP 3fueTHLLcxE2KrSAvy/PIqPhKKF5s/9i+xAukTgff95i2siRYI12hCAyxngZtW92kp2q N9bA== X-Gm-Message-State: ABy/qLZNB+5qeTfs8J3Z7Vor6Loq0wNTixNSfpMiFJpum7MhPstIUf0g DJ4cKj/MHvoVHijB39Qw2xm8hg== X-Google-Smtp-Source: APBJJlE/VLgfHQp5kucFEIky4gg1kHgE1rDHBpuDzsW52ZRbH1AaFN7RDWd0K1q1GeqeeaU9j04PIQ== X-Received: by 2002:a05:6a20:9187:b0:12c:28f4:1ca0 with SMTP id v7-20020a056a20918700b0012c28f41ca0mr19806827pzd.38.1689198844580; Wed, 12 Jul 2023 14:54:04 -0700 (PDT) Return-Path: Received: from [192.168.50.162] ([50.46.230.135]) by smtp.gmail.com with ESMTPSA id d11-20020aa78e4b000000b00678159eacecsm4046743pfr.121.2023.07.12.14.54.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Jul 2023 14:54:03 -0700 (PDT) Message-ID: <7cc0ebd1-c847-d98e-68fc-5cb46d71969e@taylorbeebe.com> Date: Wed, 12 Jul 2023 14:54:01 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 From: "Taylor Beebe" Subject: Re: [PATCH 00/14] Implement Dynamic Memory Protections To: Gerd Hoffmann Cc: devel@edk2.groups.io, Jian J Wang , Liming Gao , Dandan Bi , Ard Biesheuvel , Jiewen Yao , Jordan Justen , Leif Lindholm , Sami Mujawar , Andrew Fish , Ray Ni , Eric Dong , Rahul Kumar , Guo Dong , Sean Rhodes , James Lu , Gua Guo References: In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 7/12/2023 3:05 AM, Gerd Hoffmann wrote: > On Tue, Jul 11, 2023 at 04:52:37PM -0700, Taylor Beebe wrote: >> In the past, memory protection settings were configured via FixedAtBuild PCDs, >> which resulted in a build-time configuration of memory mitigations. This >> approach limited the flexibility of applying mitigations to the >> system and made it difficult to update or adjust the settings post-build. > > Can we have both? > > Being able to adjust settings at runtime is great. But being able to > set them at compile time on the command line (via build --pcd), without > patching code, is very useful too. > > I'd suggest to keep the PCDs, create a profile from PCD settings and use > that profile by default. At least for the transition phase and while we > don't have good support (yet) to actually manage profiles. > Hey, Gerd. The idea to keep PCDs around as another method of configuring protections is good, but I don't think there would be a way to tell if a zero-ed PCD value was an explicit setting or just the default without adding another PCD to indicate which value should be used. I think if the HOB is produced by the platform those settings should be used by default. Is that what you're envisioning as well? The flow in this case would be: DxeIpl before handoff will search for the memory protection HOB entry. If it exists, do nothing. If the HOB was not produced, create a HOB entry using the PCD values. I suppose we could also do some sort of hybrid where the logic always uses the PCD values if they are non-zero, but that may be confusing for platform developers. > Speaking of profile management: What is the longer-term vision here? > > Have a configuration form in the uefi firmware setup (aka UiApp)? > > Try adapt settings automatically, for example pick a less strict profile > in case an old/broken bootloader triggers a page fault due to using the > wrong memory type for allocations? > Overall, the idea is to empower platform developers with more configuration and compatibility options to encourage the use of memory protections in debug and production scenarios. On Surface products, we've made certain memory protections a necessary feature of the trusted boot path with the ability to fall back to an unverified boot path if a page fault occurs. We also added a configuration feature to only allow the trusted boot path which can be managed via enterprise policy or through the UEFI menu. There are lots of ways OEMs might want to configure their platform security and I think it's an open question what sorts of profile management tools would be useful to add to EDK2. > For virtual machine firmware it a good idea to allow picking up the > profile configuration from the host. For qemu that can use fw_cfg, > similar to the PcdSetNxForStack option we have today. I don't have much experience using the fw_cfg so I'd need to look into the details, but would it make sense to expand the options which can be passed via fw_cfg to be the gamut of memory protection configuration settings? I can add it to the v2 if you think so. >> This patch series also increases the memory protection level for OvmfPkg and >> ArmVirtPkg. > > Not a good idea, especially not using the 'debug' profile (which turns > on all guard bits) because that slows down firmware boot alot. > I haven't done performance testing, but I don't notice much slowdown. Isn't development the primary use case for these virtual platforms? Is there another profile you think would work better? Thanks for your feedback :) > take care, > Gerd >