Received-SPF: pass (google.com: domain of linux-kernel+bounces-147190-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Tue, 16 Apr 2024 08:57:59 -0700
From: Dan Williams <dan.j.williams@intel.com>
To: Tom Lendacky <thomas.lendacky@amd.com>, Dan Williams
	<dan.j.williams@intel.com>, <linux-kernel@vger.kernel.org>, <x86@kernel.org>,
	<linux-coco@lists.linux.dev>, <svsm-devel@coconut-svsm.dev>
CC: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Andy Lutomirski <luto@kernel.org>, "Peter
 Zijlstra" <peterz@infradead.org>, Michael Roth <michael.roth@amd.com>, Ashish
 Kalra <ashish.kalra@amd.com>
Subject: Re: [PATCH v3 10/14] configfs-tsm: Allow the privlevel_floor
 attribute to be updated
Message-ID: <661ea007d1844_4d5612948c@dwillia2-mobl3.amr.corp.intel.com.notmuch>
References: <cover.1711405593.git.thomas.lendacky@amd.com>
 <bb088b1409283cd323515138feda224759a247ec.1711405593.git.thomas.lendacky@amd.com>
 <661e04cd345af_4d56129468@dwillia2-mobl3.amr.corp.intel.com.notmuch>
 <061802e1-7c95-f1f0-b462-3aca27583d76@amd.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <061802e1-7c95-f1f0-b462-3aca27583d76@amd.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?MqRiBqqVMNHItc5IkRZjjqKW97tn9xzwX0G891lysbHKaHzXYB+yLFyx+l+s?=
 =?us-ascii?Q?SyejBbfN+di9/uTk4VsYXJdtxAl0qsdrS5wEaHZPIKD16YR4WDDduNn6RktY?=
 =?us-ascii?Q?zpo4uUnYyfh6meB3GKTjxtldkOHgt0kFAIwoJc9It6ox61RxTWNldCk/GDda?=
 =?us-ascii?Q?hXgi9PL1vHm91oTyl8xzTLpH2vc3fVh3Fw/3n6sc0ImPfYEiiw9yaXiETFEX?=
 =?us-ascii?Q?cxuCg494RF4CflhvDiegbGrpIBN+RtV+8ZGv7b1eWms8ZMlkJ2eEgAd+OAzq?=
 =?us-ascii?Q?3Cn3fmY9CiVAiE0GNSdxmQMIvcjZQJcIzUmXi3d4CR8Wx8gRaEgQZQ2sD10y?=
 =?us-ascii?Q?WGdzSbHmtsOsB9QCkrMArMr17nopINSZ5B7z82TDXzcfpnqOSxZ87N/aywQp?=
 =?us-ascii?Q?qMXCU9X926JRvg0T7GsAuhAZqfrcJeh9PQhj4k6AcuXjjO4AM/UKb9e0tXq7?=
 =?us-ascii?Q?xZvxzuF7TusaWP+t0jPeaUVUey4kSZ1KhX8/Z7sfdvFK3I4mPLVPHaDsruFp?=
 =?us-ascii?Q?8bCTviaPKrSwyfzxCztq1Wvh7QRHBk3q8NwdpMtu8znqlnAU7o/oQkVNOBa8?=
 =?us-ascii?Q?wCeAvJAEZzz0qjUAPFXZ+MMpXe9VzuER1P5tSqFhJ6KV8suKwt6CZCWNPmaq?=
 =?us-ascii?Q?kJDjkAlFdL1ZNdiH32FP8OKNoGKvfrKUITVWbp5BiHIVmPpDJkrl5IuwrmZ4?=
 =?us-ascii?Q?/pgOM9vnZ3WmUm6hmdXgujjWvy5d3Glq6gMQ9kDXe43fllLy+vtnpkEEmmUb?=
 =?us-ascii?Q?jIFu2iyCQUeWgT9i1pLREEb88dvkiaG7e9BS9YTVboO4ymWqyuzYceGy4BWU?=
 =?us-ascii?Q?1It2xOdwjn6J9lKHwjwH+vsvN5UN/8VxqFPQskasEIiBHz6TWK4PWjPfkz/A?=
 =?us-ascii?Q?h7G6zbTvz7yNMNOMVRQSyNjeZZj8BaIPe078XfKwwYpHTUdeV5NWJVGXoqb6?=
 =?us-ascii?Q?pFUEla2oXCW80U7FifQw3oGGvIhEIEo3xu8pz52H6l7XbY/mFNWJQzgAswot?=
 =?us-ascii?Q?VUV/P4R14PaY7XzVqfknLU7Tt8Toz90hEGCamsstMaDUYz0iF7sqMglWMsv/?=
 =?us-ascii?Q?osWTAR3EWp5lLGX4zvesgN9D8TLDQgN1PGeueanH6lfHkjVvhdapWxd2rR6i?=
 =?us-ascii?Q?tt8XnWQQsupzvFPU0V0qGZsODursxfiRmnjsdGqZdjwmPceLC5S8jou8RkT5?=
 =?us-ascii?Q?tTd6aAHqDDcL7x8dDxTRGbYm11A2taHQ0PjQaFUfG0wvkxpcSaDrCvkvdLlc?=
 =?us-ascii?Q?yMD4MiOMj32ucK3LJRhoHf3UkgJW8HieqHsWW43m5uacFd4fKu+XGXd7DUBW?=
 =?us-ascii?Q?AcIUIaiY908CxCQlUXmoZ7coVqnGRnAUcNmto9nKHJb05X1AzqV9lLwsLIu7?=
 =?us-ascii?Q?SxF6Sp6H8bU+bGUJwsSWJfzWc+T1ZckDNlAuqAmOrUK1yP2FB1tTYCCFLMgq?=
 =?us-ascii?Q?gnfDm/f+NOQjok5mRAakVaCLzQW/lM3W2TQHUbw55AW9NQV9tS862MPfaOTI?=
 =?us-ascii?Q?pwxcGOEw/yPPdaT6IqSlvO+m6067cGPnrUMQsYzG9qSu2zB1Xk8OS07M+Z3M?=
 =?us-ascii?Q?g51R1ejvobD1F9oLpx1WU4TiRpkdx5vj4D6gi5ofs/q51OhT9hMCT+LD959M?=
 =?us-ascii?Q?Lg=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 9544c3a2-6c03-4eb1-3231-08dc5e2dff22
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2024 15:58:02.7832
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 8tuGNzSA4TQ7wS3PgZf6ZSFtPN97BLhXpPMm2PiV/UgRflBjq7jy14XtJsi63y1yxOaqoi+iwTjDqV5oEXHS7KcBeLzq9cWHIUOCKaM9c90=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR11MB8743
X-OriginatorOrg: intel.com

Tom Lendacky wrote:
> On 4/15/24 23:55, Dan Williams wrote:
> > Tom Lendacky wrote:
> >> With the introduction of an SVSM, Linux will be running at a non-zero
> >> VMPL. Any request for an attestation report at a higher priviledge VMPL
> >> than what Linux is currently running will result in an error. Allow for
> >> the privlevel_floor attribute to be updated dynamically so that the
> >> attribute may be set dynamically.
> >>
> >> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> >> ---
> >>   drivers/virt/coco/sev-guest/sev-guest.c | 5 ++++-
> >>   include/linux/tsm.h                     | 2 +-
> >>   2 files changed, 5 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/virt/coco/sev-guest/sev-guest.c b/drivers/virt/coco/sev-guest/sev-guest.c
> >> index 1ff897913bf4..bba6531cb606 100644
> >> --- a/drivers/virt/coco/sev-guest/sev-guest.c
> >> +++ b/drivers/virt/coco/sev-guest/sev-guest.c
> >> @@ -885,7 +885,7 @@ static int sev_report_new(struct tsm_report *report, void *data)
> >>   	return 0;
> >>   }
> >>   
> >> -static const struct tsm_ops sev_tsm_ops = {
> >> +static struct tsm_ops sev_tsm_ops = {
> >>   	.name = KBUILD_MODNAME,
> >>   	.report_new = sev_report_new,
> >>   };
> >> @@ -972,6 +972,9 @@ static int __init sev_guest_probe(struct platform_device *pdev)
> >>   	snp_dev->input.resp_gpa = __pa(snp_dev->response);
> >>   	snp_dev->input.data_gpa = __pa(snp_dev->certs_data);
> >>   
> >> +	/* Set the privlevel_floor attribute based on the current VMPL */
> >> +	sev_tsm_ops.privlevel_floor = snp_get_vmpl();
> > 
> > Why is this not vmpck_id?
> 
> Good catch, this probably should be pulled out separately and submitted 
> as a Fixes: against the current support. If you think it's important 
> enough, I can do that and put this at the beginning of the series. Or I 
> can just modify this to use the vmpck_id value. Any preference?

I dunno, you tell me. What breaks if privlevel_floor is mismatched vs
vmpl and/or vmpck_id? If it warrants a "Fixes:" it should probably be
broken out.

However, I *guess* it is just adding some sanity checking precision to
userspace requests and makes some input validation not catch errors when
userspace tries to generate reports from the wrong level, right? I.e.
privlevel_floor may be lower than expected, but userspace should not be
depending on that since the report generation will fail.