linux-kernel - Re: [RFC v2-fix-v2 1/1] x86: Introduce generic protected guest abstraction

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:   Wed, 9 Jun 2021 07:56:14 -0700
From:   "Kuppuswamy, Sathyanarayanan" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Tony Luck <tony.luck@...el.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
        Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Raj Ashok <ashok.raj@...el.com>,
        Sean Christopherson <seanjc@...gle.com>,
        linux-kernel@...r.kernel.org,
        Tom Lendacky <thomas.lendacky@....com>
Subject: Re: [RFC v2-fix-v2 1/1] x86: Introduce generic protected guest
 abstraction



On 6/9/21 7:32 AM, Borislav Petkov wrote:
> On Wed, Jun 09, 2021 at 07:01:13AM -0700, Kuppuswamy, Sathyanarayanan wrote:
>> I am still not clear. What happens when a driver which includes
>> linux/protected-guest.h is compiled for non-x86 arch (s390 or arm64)?
> 
> I was wondering what felt weird: why is prot{ected,}_guest_has() in a
> generic linux/ namespace header and not in an asm/ one?
> 
> I think the proper way is for the other arches should be to provide
> their own prot_guest_has() implementation which generic code uses and
> the generic header would contain only the PR_GUEST_* defines.
> 
> Take ioremap() as an example:
> 
> arch/x86/include/asm/io.h
> arch/arm64/include/asm/io.h
> arch/s390/include/asm/io.h
> ...
> 
> and pretty much every arch has that arch-specific io.h header which
> defines ioremap() and generic code includes include/linux/io.h which
> includes the respective asm/io.h header so that users can call the
> respective ioremap() implementation.
> 
> prot_guest_has() sounds just the same to me.

ioremap() is required for all architectures. So I think adding support for it
and creating io.h for every arch seems valid. But are you sure every arch cares
about protected guest support?

IMHO, its better to leave it to arch maintainers to decide if they want
to support protected guest or not.

This can be easily achieved by defining generic arch independent config
option ARCH_HAS_PORTECTED_GUEST.

And any arch which wants to support prot_guest_has() can enable above
config option and create their own asm/protected_guest.h

This model is similar to linux/mem_encrypt.h.

With above suggested change, header file will look like below. And we
don't need implement asm/protected_guest.h for every available arch.

--- a/include/linux/protected_guest.h
+++ b/include/linux/protected_guest.h

#ifndef _LINUX_PROTECTED_GUEST_H
#define _LINUX_PROTECTED_GUEST_H 1

/* Protected Guest Feature Flags (leave 0-0xff for arch specific flags) */

/* Support for guest encryption */
#define PR_GUEST_MEM_ENCRYPT			0x100
/* Encryption support is active */
#define PR_GUEST_MEM_ENCRYPT_ACTIVE		0x101
/* Support for unrolled string IO */
#define PR_GUEST_UNROLL_STRING_IO		0x102
/* Support for host memory encryption */
#define PR_GUEST_HOST_MEM_ENCRYPT		0x103
/* Support for shared mapping initialization (after early init) */
#define PR_GUEST_SHARED_MAPPING_INIT		0x104

#ifdef ARCH_HAS_PROTECTED_GUEST
#include <asm/protected_guest.h>
#else
static inline bool prot_guest_has(unsigned long flag) { return false; }
#endif

#endif /* _LINUX_PROTECTED_GUEST_H */


> 
> Better?
> 

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer