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: <D6E1C9DD-3E07-4D96-AA94-1A23085169CA@infradead.org>
Date: Tue, 17 Dec 2024 11:47:15 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Ard Biesheuvel <ardb@...nel.org>
CC: 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>,
 Eric Biederman <ebiederm@...ssion.com>, David Woodhouse <dwmw@...zon.co.uk>,
 Sourabh Jain <sourabhjain@...ux.ibm.com>,
 Hari Bathini <hbathini@...ux.ibm.com>, Michael Ellerman <mpe@...erman.id.au>,
 Thomas Zimmermann <tzimmermann@...e.de>,
 Andrew Morton <akpm@...ux-foundation.org>, Baoquan He <bhe@...hat.com>,
 Yuntao Wang <ytcoode@...il.com>, David Kaplan <david.kaplan@....com>,
 Tao Liu <ltao@...hat.com>,
 "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
 Kai Huang <kai.huang@...el.com>, Josh Poimboeuf <jpoimboe@...nel.org>,
 Breno Leitao <leitao@...ian.org>, Wei Yang <richard.weiyang@...il.com>,
 Rong Xu <xur@...gle.com>,
 Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
 linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
 Simon Horman <horms@...nel.org>, Dave Young <dyoung@...hat.com>,
 Peter Zijlstra <peterz@...radead.org>, bsz@...zon.de, nathan@...nel.org
Subject: Re: [PATCH 9/9] x86/kexec: Use typedef for relocate_kernel_fn function prototype

On 17 December 2024 11:14:29 CET, Ard Biesheuvel <ardb@...nel.org> wrote:
>On Tue, 17 Dec 2024 at 11:07, David Woodhouse <dwmw2@...radead.org> wrote:
>>
>> On 17 December 2024 10:54:19 CET, Ard Biesheuvel <ardb@...nel.org> wrote:
>> >On Tue, 17 Dec 2024 at 10:42, David Woodhouse <dwmw2@...radead.org> wrote:
>> >> Hm, I am perfectly happy to believe that my memory is failing me, especially when it comes to specifics of i386 assembler code. But are you also telling me that
>> >> <https://kernelnewbies.org/FAQ/asmlinkage> is a lie?
>> >>
>> >
>> >It seems wildly out of date, at least.
>> >
>> >Commit 96a388de5dc53a8b2 from 2007 removed the asmlinkage definition
>> >containing regparm(0) from include/asm-i386/linkage.h, and I'm not
>> >convinced it was ever sound to conflate linkage with calling
>> >convention like that. Today, asmlinkage evaluates to 'extern "C"' when
>> >using a C++ compiler, which is also not part of the type.
>> >
>> >However, I failed to notice that this just moves code around, and only
>> >applies to 32-bit in the first place. So I won't waste any more of
>> >your time obsessing over this.
>>
>> Too late :)
>>
>> You've already made me concerned about what the calling convention *is* for relocate_kernel() on i386. Because if asmlinkage doesn't mean regparm(0) any more and the i386 kernel is still built with -mregparm=3, then how does the asm code (which seems to believe all its arguments are on the stack) actually work?
>>
>> It seems slightly unlikely that kexec on i386 has just been broken since 2007 but I'm not sure I'd completely rule it out.
>>
>> So now I guess I have to actually build a 32-bit userspace test case and *test* it.
>>
>> And that means I no longer have any excuse for not doing all the same cleanups in the i386 version of the code that I've done for x86_64...
>>
>> Thanks for that :)
>>
>
>Actually, asmlinkage still means regparm(0) on i386, so I'm going to
>have to apologise again, for my poor git foo this time.

Heh, no problem.

I'm pleased to find my memory wasn't failing me after all, so I might have a bit more time left before they put me out to pasture.

I'll take that win :)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ