linux-kernel - Re: [PATCH v4 5/6] x86/sgx: Hook sgx_memory

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: <0ef0a180-ff10-1c43-476a-41953fe2383c@intel.com>
Date:   Wed, 8 Sep 2021 09:49:58 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     "Luck, Tony" <tony.luck@...el.com>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Sean Christopherson <seanjc@...gle.com>
Cc:     "Zhang, Cathy" <cathy.zhang@...el.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 5/6] x86/sgx: Hook sgx_memory_failure() into mainline
 code

On 9/7/21 5:59 PM, Luck, Tony wrote:
> +#ifdef CONFIG_X86_SGX
> +int arch_memory_failure(unsigned long pfn, int flags);
> +#define arch_memory_failure arch_memory_failure
> +
> +bool arch_is_platform_page(u64 paddr);
> +#define arch_is_platform_page arch_is_platform_page
> +#endif
> 
> and in include/linux/mm.h
> 
> +#ifndef arch_memory_failure
> +static inline int arch_memory_failure(unsigned long pfn, int flags)
> +{
> +       return -ENXIO;
> +}
> +#endif
> +#ifndef arch_is_platform_page
> +static inline bool arch_is_platform_page(u64 paddr)
> +{
> +       return false;
> +}
> +#endif
> 
> Dave: Is that what you wanted?  If so I can fold these bits back into the
> appropriate bits of the series. Address other comments. and post v5.

Looks good to me.

These can *also* be done with a

config ARCH_HAS_SPECIAL_MEMORY_FAILURE
	bool

in mm/Kconfig.h, and then:

	select ARCH_HAS_SPECIAL_MEMORY_FAILURE

in the SGX Kconfig instead of the ifndef's.  I prefer the configs
personally because they are less ambiguous and can't be screwed up my
missing #includes or weird #include ordering problems.  But, some folks
prefer to avoid polluting the CONFIG_* space.

That's just pure personal preference though.  Either way is fine.