On 64-bit platforms, the pfn_to_kaddr() macro requires that the input
value is 64-bits in order to ensure that valid address bits don't get
lost when shifting that input by PAGE_SHIFT to calculate the physical
address to provide a virtual address for.
One such example is in pvalidate_pages() (used by SEV-SNP guests), where
the GFN in the struct used for page-state change requests is a 40-bit
bit-field, so attempts to pass this GFN field directly into
pfn_to_kaddr() ends up causing guest crashes when dealing with addresses
above the 1TB range due to the above.
Fix this issue with SEV-SNP guests, as well as any similar cases that
might cause issues in current/future code, by casting the input to
pfn_to_kaddr() to a 64-bit type prior to performing the shift operation.
While it might be argued that the issue is on the caller side, other
archs/macros have taken similar approaches to deal with instances like
this, such as commit e48866647b48 ("ARM: 8396/1: use phys_addr_t in
pfn_to_kaddr()").
Suggested-by: Dave Hansen <[email protected]>
Fixes: 6c3211796326 ("x86/sev: Add SNP-specific unaccepted memory support")
Signed-off-by: Michael Roth <[email protected]>
---
v2:
- Move the cast down into pfn_to_kaddr() to fix other possible
instances (Dave)
- Rename from "x86/sev: Fix overflow when computing address for
PVALIDATE"
arch/x86/include/asm/page.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/page.h b/arch/x86/include/asm/page.h
index d18e5c332cb9..bc8d023fe78d 100644
--- a/arch/x86/include/asm/page.h
+++ b/arch/x86/include/asm/page.h
@@ -66,7 +66,7 @@ static inline void copy_user_page(void *to, void *from, unsigned long vaddr,
* virt_addr_valid(kaddr) returns true.
*/
#define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
-#define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
+#define pfn_to_kaddr(pfn) __va((unsigned long)(pfn) << PAGE_SHIFT)
extern bool __virt_addr_valid(unsigned long kaddr);
#define virt_addr_valid(kaddr) __virt_addr_valid((unsigned long) (kaddr))
--
2.25.1
On 11/15/23 12:14, Michael Roth wrote:
> While it might be argued that the issue is on the caller side, other
> archs/macros have taken similar approaches to deal with instances like
> this, such as commit e48866647b48 ("ARM: 8396/1: use phys_addr_t in
> pfn_to_kaddr()").
Gah, I really hope nobody is arguing that for real, or is even thinking
about this as a valid argument.
The helper should, well, help the caller. It makes zero sense to me
that every single call site would need to know if the argument's type
was big enough to hold the _return_ value. This nonsense can only even
happen with macros. Type promotion would just do the right thing for
any sanely declared actual helper function.
On Wed, Nov 15, 2023 at 12:48:58PM -0800, Dave Hansen wrote:
> On 11/15/23 12:14, Michael Roth wrote:
> > While it might be argued that the issue is on the caller side, other
> > archs/macros have taken similar approaches to deal with instances like
> > this, such as commit e48866647b48 ("ARM: 8396/1: use phys_addr_t in
> > pfn_to_kaddr()").
>
> Gah, I really hope nobody is arguing that for real, or is even thinking
> about this as a valid argument.
Not that I'm aware, but I did have my own doubts initially, which is
why I thought it warranted a note in the commit just in case it came up
from someone else.
>
> The helper should, well, help the caller. It makes zero sense to me
> that every single call site would need to know if the argument's type
> was big enough to hold the _return_ value. This nonsense can only even
> happen with macros. Type promotion would just do the right thing for
> any sanely declared actual helper function.
My thought was that it is easier to expect developers to know the pitfalls
of bit-field types, since it is universally applicable to all C code,
whereas expecting developers to anticipate such issues when writing similar
macros is potentially harder to enforce/audit and could lead to similar
issues popping up as things are refactored over time and new macros get
added that don't take such usages into account.
But neither argument seems to hold up in reality. Experienced developers
obviously do fall victim to the subtleties of of bit-field types, and
kernel devs obviously do tend to address these instances in more robust
ways based on the various pfn-related macros I looked through.
-Mike
On November 15, 2023 5:42:31 PM EST, Michael Roth <[email protected]> wrote:
>On Wed, Nov 15, 2023 at 12:48:58PM -0800, Dave Hansen wrote:
>> On 11/15/23 12:14, Michael Roth wrote:
>> > While it might be argued that the issue is on the caller side, other
>> > archs/macros have taken similar approaches to deal with instances like
>> > this, such as commit e48866647b48 ("ARM: 8396/1: use phys_addr_t in
>> > pfn_to_kaddr()").
>>
>> Gah, I really hope nobody is arguing that for real, or is even thinking
>> about this as a valid argument.
>
>Not that I'm aware, but I did have my own doubts initially, which is
>why I thought it warranted a note in the commit just in case it came up
>from someone else.
>
>>
>> The helper should, well, help the caller. It makes zero sense to me
>> that every single call site would need to know if the argument's type
>> was big enough to hold the _return_ value. This nonsense can only even
>> happen with macros. Type promotion would just do the right thing for
>> any sanely declared actual helper function.
>
>My thought was that it is easier to expect developers to know the pitfalls
>of bit-field types, since it is universally applicable to all C code,
>whereas expecting developers to anticipate such issues when writing similar
>macros is potentially harder to enforce/audit and could lead to similar
>issues popping up as things are refactored over time and new macros get
>added that don't take such usages into account.
>
>But neither argument seems to hold up in reality. Experienced developers
>obviously do fall victim to the subtleties of of bit-field types, and
>kernel devs obviously do tend to address these instances in more robust
>ways based on the various pfn-related macros I looked through.
>
>-Mike
Now, if you are doing a cast, you are making the macro unusable for assembly anyway; any reason not to make it an inline function at that point?