linux-kernel - Re: [PATCH 1/4] x86/sgx: Add total number of EPC pages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z-Zg5elc0xTwoxat@kernel.org>
Date: Fri, 28 Mar 2025 10:42:13 +0200
From: Jarkko Sakkinen <jarkko@...nel.org>
To: "Reshetova, Elena" <elena.reshetova@...el.com>
Cc: "Hansen, Dave" <dave.hansen@...el.com>,
	"linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>,
	"Mallick, Asit K" <asit.k.mallick@...el.com>,
	"Scarlata, Vincent R" <vincent.r.scarlata@...el.com>,
	"Cai, Chong" <chongc@...gle.com>,
	"Aktas, Erdem" <erdemaktas@...gle.com>,
	"Annapurve, Vishal" <vannapurve@...gle.com>,
	"dionnaglaze@...gle.com" <dionnaglaze@...gle.com>,
	"bondarn@...gle.com" <bondarn@...gle.com>,
	"Raynor, Scott" <scott.raynor@...el.com>,
	"Shutemov, Kirill" <kirill.shutemov@...el.com>
Subject: Re: [PATCH 1/4] x86/sgx: Add total number of EPC pages

On Fri, Mar 28, 2025 at 08:07:24AM +0000, Reshetova, Elena wrote:
> > Yes but obviously I cannot promise that I'll accept this as it is
> > until I see the final version
> 
> Are you saying you prefer *this version with spinlock* vs. 
> simpler version that utilizes the fact that sgx_nr_free_pages is changed
> into tracking of number of used pages? 

I don't know really what I do prefer.

Maybe +1 version would make sense where you keep with the approach
you've chosen (used pages) and better rationalize why it is mandatory,
and why free pages would be worse?

> 
> > 
> > Also you probably should use mutex given the loop where we cannot
> > temporarily exit the lock (like e.g. in keyrings gc we can).
> 
> Not sure I understand this, could you please elaborate why do I need an
> additional mutex here? Or are you suggesting switching spinlock to mutex? 

In your code example you had a loop inside spinlock, which was based on
a return code of an opcode, i.e. potentially infinite loop.

I'd like to remind you that the hardware I have is NUC7 from 2018 so
you really have to nail how things will work semantically as I can
only think these things only in theoretical level ;-) [1]


> 
> Best Regards,
> Elena.
> 

[1] https://social.kernel.org/notice/AsUbsYH0T4bTcUSdUW

BR, Jarkko