linux-kernel - Re: [PATCH v2 2/2] x86/sgx: Add sgx_nr_{all, free}

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]

Date:   Thu, 8 Apr 2021 12:13:21 +0300
From:   Jarkko Sakkinen <jarkko@...nel.org>
To:     Borislav Petkov <bp@...en8.de>
Cc:     linux-sgx@...r.kernel.org,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] x86/sgx: Add sgx_nr_{all, free}_pages to the
 debugfs

On Thu, Apr 08, 2021 at 11:52:40AM +0300, Jarkko Sakkinen wrote:
> On Wed, Apr 07, 2021 at 06:15:33PM +0200, Borislav Petkov wrote:
> > On Wed, Apr 07, 2021 at 07:09:11PM +0300, Jarkko Sakkinen wrote:
> > > I left out "epc" because they are already prefixed with "sgx_".
> > 
> > Are there any other "page" types which are going to be figurating in
> > some pseudofs or is "sgx" == "epc" in this case?
> > 
> > > debugfs was my first shot, but for sure these could be sysfs.
> > 
> > Ok, let's keep it in debugfs for now, it can always be made an ABI later
> > and moved to sysfs. But pls document what those are and what they do and
> > that when in debugfs, there are no guarantees that these interfaces will
> > be there in the future.
> 
> I think these attributes are quite useful information to have available so
> I'd go actually doing sysfs attributes and create
> Documentation/ABI/stable/sysfs-driver-sgx to document them.
> 
> Given that they would go then to the sysfs directory of the driver, then
> probably the legit names for the attributes ought to be:
> 
> - nr_all_epc_pages
> - nr_free_epc_pages
> 
> What do you think?

Actually I think read-only sysctl attributes would be a better idea.

The rationale for this is that we have two misc devices sgx_enclave and
sgx_provision, and these are global attributes even applicable to KVM.

It does not matter functionality-wise, but API-wise it'd look stupid to
directly associate to sgx_enclave.

I.e. I'd add something along the lines of 

static struct ctl_path x86_sysctl_path[] = {
        { .procname = "kernel", },
	{ .procname = "x86", },
	{ }
};

static struct ctl_table x86_sysctl_table[] = {
	{
		.procname       = "sgx_nr_all_pages",
		.mode           = 0444,
                /* rest ... */
	},
	{
		.procname       = "sgx_nr_free_pages",
		.mode           = 0444,
                /* rest ... */
	},
	{ }
};

And write Documentation/x86/proc.rst.

/Jarkko