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: <5823af8a-7dbb-dbb0-5ea2-d9846aa2a36a@intel.com>
Date:   Wed, 4 Aug 2021 12:27:15 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Tianyu Lan <ltykernel@...il.com>, kys@...rosoft.com,
        haiyangz@...rosoft.com, sthemmin@...rosoft.com, wei.liu@...nel.org,
        decui@...rosoft.com, tglx@...utronix.de, mingo@...hat.com,
        bp@...en8.de, x86@...nel.org, hpa@...or.com,
        dave.hansen@...ux.intel.com, luto@...nel.org, peterz@...radead.org,
        konrad.wilk@...cle.com, boris.ostrovsky@...cle.com,
        jgross@...e.com, sstabellini@...nel.org, joro@...tes.org,
        will@...nel.org, davem@...emloft.net, kuba@...nel.org,
        jejb@...ux.ibm.com, martin.petersen@...cle.com, arnd@...db.de,
        hch@....de, m.szyprowski@...sung.com, robin.murphy@....com,
        Tianyu.Lan@...rosoft.com, rppt@...nel.org,
        kirill.shutemov@...ux.intel.com, akpm@...ux-foundation.org,
        brijesh.singh@....com, thomas.lendacky@....com, pgonda@...gle.com,
        david@...hat.com, krish.sadhukhan@...cle.com, saravanand@...com,
        aneesh.kumar@...ux.ibm.com, xen-devel@...ts.xenproject.org,
        martin.b.radev@...il.com, ardb@...nel.org, rientjes@...gle.com,
        tj@...nel.org, keescook@...omium.org,
        michael.h.kelley@...rosoft.com
Cc:     iommu@...ts.linux-foundation.org, linux-arch@...r.kernel.org,
        linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-scsi@...r.kernel.org, netdev@...r.kernel.org,
        vkuznets@...hat.com, parri.andrea@...il.com
Subject: Re: [PATCH V2 03/14] x86/set_memory: Add x86_set_memory_enc static
 call support

On 8/4/21 11:44 AM, Tianyu Lan wrote:
> +static int default_set_memory_enc(unsigned long addr, int numpages, bool enc);
> +DEFINE_STATIC_CALL(x86_set_memory_enc, default_set_memory_enc);
> +
>  #define CPA_FLUSHTLB 1
>  #define CPA_ARRAY 2
>  #define CPA_PAGES_ARRAY 4
> @@ -1981,6 +1985,11 @@ int set_memory_global(unsigned long addr, int numpages)
>  }
>  
>  static int __set_memory_enc_dec(unsigned long addr, int numpages, bool enc)
> +{
> +	return static_call(x86_set_memory_enc)(addr, numpages, enc);
> +}
> +
> +static int default_set_memory_enc(unsigned long addr, int numpages, bool enc)
>  {
>  	struct cpa_data cpa;
>  	int ret;

It doesn't make a lot of difference to add this infrastructure and then
ignore it for the existing in-tree user:

> static int __set_memory_enc_dec(unsigned long addr, int numpages, bool enc)
> {
>         struct cpa_data cpa;
>         int ret;
> 
>         /* Nothing to do if memory encryption is not active */
>         if (!mem_encrypt_active())
>                 return 0;

Shouldn't the default be to just "return 0"?  Then on
mem_encrypt_active() systems, do the bulk of what is in
__set_memory_enc_dec() today.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ