linux-kernel - Re: [RFC 03/14] x86/apic: Populate .read()/.write() callbacks of Secure AVIC 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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2f10fdf6-a0c7-4fa4-9180-56a3b35cc147@amd.com>
Date: Fri, 8 Nov 2024 14:29:03 +0530
From: Neeraj Upadhyay <Neeraj.Upadhyay@....com>
To: Borislav Petkov <bp@...en8.de>
Cc: linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
 dave.hansen@...ux.intel.com, Thomas.Lendacky@....com, nikunj@....com,
 Santosh.Shukla@....com, Vasant.Hegde@....com, Suravee.Suthikulpanit@....com,
 David.Kaplan@....com, x86@...nel.org, hpa@...or.com, peterz@...radead.org,
 seanjc@...gle.com, pbonzini@...hat.com, kvm@...r.kernel.org
Subject: Re: [RFC 03/14] x86/apic: Populate .read()/.write() callbacks of
 Secure AVIC driver

On 11/7/2024 7:58 PM, Borislav Petkov wrote:
> On Thu, Nov 07, 2024 at 09:02:16AM +0530, Neeraj Upadhyay wrote:
>> Intention of doing per reg is to be explicit about which registers
>> are accessed from backing page, which from hv and which are not allowed
>> access. As access (and their perms) are per-reg and not range-based, this
>> made sense to me. Also, if ranges are used, I think 16-byte aligned
>> checks are needed for the range. If using ranges looks more logical grouping
>> here, I can update it as per the above range groupings.
> 
> Is this list of registers going to remain or are we going to keep adding to
> it so that the ranges become contiguous?
> 

>From the APIC architecture details in APM and SDM, I see these gaps are reserved
ranges which are present for xapic also. x2apic keeps the register layout consistent.
So, these gaps looks to have have remained reserved for long. I don't have information
on the uarch reasons (if any) for the reserved space layout.

> And yes, there is some merit to explicitly naming them but you can also put
> that in a comment once above those functions too.
> 

I understand your point but, for this specific case, to me, each register as a separate
"switch case" looks clearer and self-describing than keeping a range of different
registers and putting comment about which registers it covers.

In addition, while each APIC register is at 16-byte alignment, they are accessed
using dword size reads/writes. So, as mentioned in previous reply, using ranges
requires alignment checks.

One hypothetical example where using range checks could become klugy is when
the unused 12 bytes of 16 byte  of a register is repurposed for implementation-
specific features and the read/write permissions are different for the architecture
register and the implementation-defined one. Secure AVIC uses (IRRn + 4) address
for ALLOWED_IRRn. However, the r/w permissions are same for IRRn and ALLOWED_IRRn.
So, using ranges for IRR register space works fine. However, it may not work
if similar register-space-repurposing happens for other features in future. I
understand this could be considered as speculative and hand-wavy reasoning. So,
I would ask, does above reasoning convince you with the current switch-case layout
or you want it to be range-based?

- Neeraj