linux-kernel - Re: [RESEND PATCH v2 1/3] x86/fred: Allow variable-sized event frame

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] [day] [month] [year] [list]

Message-ID: <67c39641-8474-4497-8c67-eb3792730611@zytor.com>
Date: Wed, 19 Mar 2025 09:34:58 -0700
From: Xin Li <xin@...or.com>
To: Brian Gerst <brgerst@...il.com>
Cc: linux-kernel@...r.kernel.org, luto@...nel.org, tglx@...utronix.de,
        mingo@...nel.org, bp@...en8.de, dave.hansen@...ux.intel.com,
        x86@...nel.org, hpa@...or.com, peterz@...radead.org
Subject: Re: [RESEND PATCH v2 1/3] x86/fred: Allow variable-sized event frame

On 3/19/2025 6:55 AM, Brian Gerst wrote:
>>>>
>>>> +/*
>>>> + * Initialize thread_info.user_pt_regs for IDT event delivery.
>>>> + *
>>>> + * For IDT user level event delivery, a pt_regs structure is pushed by both
>>>> + * hardware and software and always resides at a fixed offset from top of
>>>> + * current task kernel stack, thus thread_info.user_pt_regs is a per-task
>>>> + * constant and NEVER changes after initialization.
>>>> + *
>>>> + * While for FRED user level event delivery, user_pt_regs is updated in
>>>> + * fred_entry_from_user() immediately after user level event delivery.
>>>> + *
>>>> + * Note: thread_info.user_pt_regs of the init task is initialized at build
>>>> + * time.
>>>> + */
>>>> +void arch_init_user_pt_regs(struct task_struct *tsk)
>>>> +{
>>>> +       unsigned long top_of_stack = (unsigned long)task_stack_page(tsk) + THREAD_SIZE;
>>>> +
>>>> +       top_of_stack -= TOP_OF_KERNEL_STACK_PADDING;
>>>> +       tsk->thread_info.user_pt_regs = (struct pt_regs *)top_of_stack - 1;
>>>> +}
>>>
>>> Can this be put into arch_dup_task_struct() instead of creating another hook?
>>
>> I wanted to do it at the beginning but task stack is no longer part of
>> the task_struct on x86.  Make sense?
> 
> I see that now.  My concern here is that using a weak function makes
> all other arches pay the cost of an empty function call.  That's why
> many hooks are static linlines or macros, especially if the default is
> a no-op.
> 

Same here.

As you have gone through the code and logic, mind to give a RB?

Thanks!
     Xin