linux-kernel - Re: [PATCH v3 5/6] platform/x86: intel_tdx_attest: Add TDX Guest attestation interface driver

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]

Message-ID: <bd001b63-403f-b60b-7ca1-28573c8d843b@intel.com>
Date:   Tue, 20 Jul 2021 14:22:15 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Andi Kleen <ak@...ux.intel.com>,
        "Kuppuswamy, Sathyanarayanan" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...nel.org>,
        Hans de Goede <hdegoede@...hat.com>,
        Mark Gross <mgross@...ux.intel.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>
Cc:     Peter H Anvin <hpa@...or.com>, Tony Luck <tony.luck@...el.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
        x86@...nel.org, linux-kernel@...r.kernel.org,
        platform-driver-x86@...r.kernel.org, bpf@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH v3 5/6] platform/x86: intel_tdx_attest: Add TDX Guest
 attestation interface driver

On 7/20/21 2:16 PM, Andi Kleen wrote:
> On 7/20/2021 10:59 AM, Dave Hansen wrote:
>> On 7/20/21 10:52 AM, Kuppuswamy, Sathyanarayanan wrote:
>>>> Why does this need to use the page allocator directly?
>> ^^ You didn't address this question.
> 
> The address needs to be naturally aligned, and I'm not sure all slab
> allocators guarantee 64 byte alignment. So using the page allocator
> seems to be safer. I guess a comment would be good.

The documentation

> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/core-api/memory-allocation.rst#n146

claims:

> The address of a chunk allocated with `kmalloc` is aligned to at least
> ARCH_KMALLOC_MINALIGN bytes.  For sizes which are a power of two, the
> alignment is also guaranteed to be at least the respective size.

This is another case where care in coding these things up, writing good
changelogs and expressing assumptions in comments can save
back-and-forth from a reviewer.

Imagine if this had been:

	/*
	 * tdreport_data needs to be 64-byte aligned.
	 * Full page alignment is more than enough.
	 */
	tdreport_data = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, 0);
	if (!tdreport_data) {
		ret = -ENOMEM;
		goto failed;
	}