linux-kernel - Re: [RFC][PATCH 00/17] Fix up the recent SRSO patches

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: <20240326222134.GNZgNKbgdBUsAU98RV@fat_crate.local>
Date: Tue, 26 Mar 2024 23:21:34 +0100
From: Borislav Petkov <bp@...en8.de>
To: a-development@...teo.de
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, peterz@...radead.org,
	David.Kaplan@....com, Andrew.Cooper3@...rix.com,
	jpoimboe@...nel.org, gregkh@...uxfoundation.org
Subject: Re: [RFC][PATCH 00/17] Fix up the recent SRSO patches

Whoops, 

this fell through the cracks. Sorry about that.

On Mon, Jan 29, 2024 at 06:18:00PM +0000, a-development@...teo.de wrote:
> I have the feeling that something else is amiss.
> Currently under 6.7.2-2-cachyos with srso=off.
> https://0x0.st/HDqP.txt

Yah, your tasks refuse to freeze on suspend and they have this fuse
stuff in the stacktrace:

[ 6346.492593] task:btop            state:D stack:0     pid:279617 tgid:1548  ppid:1531   flags:0x00004006
[ 6346.492600] Call Trace:
[ 6346.492602]  <TASK>
[ 6346.492607]  __schedule+0xd44/0x1af0
[ 6346.492614]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 6346.492617]  ? __wake_up+0x9d/0xc0
[ 6346.492622]  schedule+0x32/0xd0
[ 6346.492627]  request_wait_answer+0xd0/0x2a0 [fuse db37c699d94393e946cf93306449ea0f307959a1]
[ 6346.492638]  ? __pfx_autoremove_wake_function+0x10/0x10
[ 6346.492643]  fuse_simple_request+0x21c/0x390 [fuse db37c699d94393e946cf93306449ea0f307959a1]
[ 6346.492653]  fuse_statfs+0xf2/0x160 [fuse db37c699d94393e946cf93306449ea0f307959a1]
[ 6346.492667]  statfs_by_dentry+0x67/0x90

> 
> Now I feel, further communication is rather selfish, as a clean environment
> is hard to provide.
> In any case, my FUSE arguments are sshfs -o kernel_cache -o auto_cache -o
> reconnect \
>                -o compression=yes -o cache_timeout=600 -o
> ServerAliveInterval=30 \
>                "$source" "$target" -o idmap=user
> 
> With this line, I somehow managed to have the FUSE mount infinitely mounted,
> even if the device was offline for couple of days.
> A followed suspend would fail to freeze.
> srso=off would reproducibly work.

Not in your example above. It would fail after a couple of suspend
cycles.

And looking at your splats

[ 6366.524953]  ? switch_fpu_return+0x50/0xe0
[ 6366.524956]  ? srso_alias_return_thunk+0x5/0xfbef5
		  ^^^^^^^^^^^^^^^^^^^^^^^^
[ 6366.524958]  ? exit_to_user_mode_prepare+0x132/0x1f

the right cmdline option to disable it is:

spec_rstack_overflow=off

not

srso=off

:-)

> Please provide me a specific version of a kernel I should try in my
> configuration to try and reproduce.
> I'd prefer a pre-compiled one; if not tell me...
> I use archlinux.

Just build the latest released kernel, which is 6.8 now. Take your
config and use it to build it. The net is full of tutorials how to do
so.

And then try with spec_rstack_overflow=off and let's see what that does.

> Please give me a reason to not feel bad about myself.

Don't worry - it's just a machine. :)

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette