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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 03 Nov 2021 23:54:50 +0200
From:   Jarkko Sakkinen <jarkko@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>, reinette.chatre@...el.com,
        tony.luck@...el.com, nathaniel@...fian.com,
        linux-kernel@...r.kernel.org, linux-sgx@...r.kernel.org
Subject: Re: [PATCH v11 2/2] x86/sgx: Add an attribute for the amount of SGX
 memory in a NUMA node

On Wed, 2021-11-03 at 23:49 +0200, Jarkko Sakkinen wrote:
> On Wed, 2021-11-03 at 09:22 +0100, Greg Kroah-Hartman wrote:
> > That's not the proper thing to do here at all, these values should be
> > part of the device structure that this attribute lives on, in order to
> > properly handle all of these reference counting and locking issues
> > automatically.
> 
> The attribute group is part of the device structure, so in that sense
> it is already like this. And I think that all NUMA node specific data
> (most of which is unrelated to device sysfs) is best kept in the private
> struct.

If you are concerned that the SGX driver might go away when NUMA code
calls it, I can address that concern too.

The memory management code if arch/x86/kernel/cpu/sgx is not associated
with the user space facing driver. E.g. you can use memory manager with
KVM without having the driver even enabled in the kernel.

This include the numa code in the SGX subsystem. It's life-cycle is the
same as the power-cycle. It is guaranteed that any possible time during
the power cycle, when that sysfs callback is called, all the data is valid.
That's why it is safe to be part of the attribute groups of the NUMA
device.


/Jarkko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ