linux-kernel - Re: commit 7ffb791423c7 breaks steam game

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: <20b5823e-247a-456a-bb55-d50f212a9f5a@nvidia.com>
Date: Thu, 13 Mar 2025 21:40:40 +1100
From: Balbir Singh <balbirs@...dia.com>
To: Bert Karwatzki <spasswolf@....de>
Cc: Ingo Molnar <mingo@...nel.org>, Kees Cook <kees@...nel.org>,
 Bjorn Helgaas <bhelgaas@...gle.com>,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 Peter Zijlstra <peterz@...radead.org>, Andy Lutomirski <luto@...nel.org>,
 linux-kernel@...r.kernel.org
Subject: Re: commit 7ffb791423c7 breaks steam game

On 3/13/25 20:22, Bert Karwatzki wrote:
> Am Mittwoch, dem 12.03.2025 um 12:24 +1100 schrieb Balbir Singh:
>>>>
>>>>>
>>>>> As a sidenote, I've tested several kernel with nokaslr as command line parameter
>>>>> (6.1.128, 6.8.12, 6.12.17 (the debian sid distributional kernel)) and nokaslr is
>>>>> not recognized as a command line parameter in any of them
>>>>>
>>>>
>>>> Please see my comment above about booting. How did you check if nokaslr is being
>>>> recognized, is it via looking up dmesg?
>>>>
>>> When I boot with nokaslr I get the following messages in dmesg
>>> [    T0] Unknown kernel command line parameters "nokaslr
>>> BOOT_IMAGE=/boot/vmlinuz-6.14.0-rc5-next-20250307-master", will be passed to
>>> user space.
>>>
>>> This also happens when I use the debian kernel with standard .config
>>
>> That is quite strange, I can see nokaslr handling in choose_random_location() in
>> arch/x86/boot/compressed/kaslr.c (which depends on CONFIG_RANDOMIZE_BASE)
>>
>> Thanks,
>> Balbir
> 
> The command line parameter nokaslr does actually work, I tested that by booting
> the kernel with and without nokaslr and checked /proc/iomem for the physical
> address of the kernel. With nokalsr it's always at 0x1200000.
> 
> The warning message in the code
> 	if (cmdline_find_option_bool("nokaslr")) {
> 		warn("KASLR disabled: 'nokaslr' on cmdline.");
> 		return;
> 	}
> on the other hand is not shown, because warn is basically __putstr() which
> outputs to the serial console and the screen, not the log buffer (Which we do
> not have this early in boot anyway, I assume).
> 
> So with this solved I tested stellaris with a kernel without CONFIG_PCI_P2PDMA
> and nokaslr and found the same buggy behaviour (i.e. laggy input while stellaris
> is running).
> 
Thanks, the system/game is not working correctly accessing memory at 64 TiB

I am beginning to wonder what your physical address bits are set to?
I can't figure out from lspci, the capabilities of the iommu on your laptop

Could you please share your full dmesg/lspci before and after the patch/nokaslr
command line. 

Here is the what I know so far and based on some search I did, I could find
your laptop might have a CPU like this one
https://openbenchmarking.org/s/AMD+Ryzen+7+3750H

It has 43 bits of physical address and sev supported and IIRC sev can change the
amount of physical memory accessible, but I am surprised to see that 0xaff...
which is the 10TiB range is accessible (44 bits) and the 64 TiB may not be.
I am keen to know if the system works or is it just the game that is sluggiesh?
Does graphics work in general, do other games work?

The arch/x86/mm code assumes we have 46 or 52 bits of physically addressable
bits. There are experts who can correct me if I missed anything in my
analysis.

It seems like kaslr has been hiding the issue that exists on your laptop.

Balbir

PS: We could try some other experiments once we have the full dmesg and also get
help from other experts.