linux-kernel - Re: [PATCH] x86: add hintable NOPs emulation

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: <2e7029bd-5e3b-4c4b-b969-b1a3794b2fec@orca.pet>
Date: Thu, 21 Aug 2025 17:11:20 +0200
From: Marcos Del Sol Vives <marcos@...a.pet>
To: David Laight <david.laight.linux@...il.com>,
 Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
 Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
 Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
 "H. Peter Anvin" <hpa@...or.com>, Brian Gerst <brgerst@...il.com>,
 Uros Bizjak <ubizjak@...il.com>, Ard Biesheuvel <ardb@...nel.org>,
 David Kaplan <david.kaplan@....com>, "Ahmed S. Darwish"
 <darwi@...utronix.de>, Kees Cook <kees@...nel.org>,
 Andrew Cooper <andrew.cooper3@...rix.com>, Oleg Nesterov <oleg@...hat.com>,
 "Xin Li (Intel)" <xin@...or.com>, Sabyrzhan Tasbolatov <snovitoll@...il.com>
Subject: Re: [PATCH] x86: add hintable NOPs emulation

El 21/08/2025 a las 14:28, David Laight escribió:
>> This is going to be terribly slow if there's a significant number of
>> traps (like with endbr32), but yeah, this ought to work.
> 
> Could you patch the memory resident page to contain a supported nop?
> (without marking it 'dirty')
> Then the same function wouldn't trap until the code page was reloaded
> from the source file.
> 

While I had thought of that, to be honest I'm not knowledgeable enough
in kernel development to pull that off without being 100% sure I did not
introduce any compatibility or security issues, so I preferred for the
time being to play it safe.

Anyhow, I made a simple benchmark running "sudo" with NOPASSWD as provided
by Debian bookworm i686, and another version compiled without ENDBR32s, and
the overhead does not seem to be too high:

# time for i in {1..100}; do ./sudo-nocet echo "" >/dev/null; done
real    0m6,001s
user    0m3,664s
sys     0m1,576s

# time for i in {1..100}; do sudo echo "" >/dev/null; done
real    0m5,983s
user    0m3,546s
sys     0m1,717s

The original binary has 203 "endbr32"s, and they result in a 0.3% slowdown
for this binary in particular, which is totally acceptable IMO.

Greetings,
Marcos