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] [day] [month] [year] [list]
Message-ID: <469a7dc3-b4de-4d2b-9068-381a250273d3@zytor.com>
Date: Mon, 26 Aug 2024 10:32:31 -0700
From: Xin Li <xin@...or.com>
To: linux-kernel@...r.kernel.org
Cc: luto@...nel.org, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
        peterz@...radead.org, brgerst@...il.com
Subject: Re: [PATCH v1 0/3] x86: Allow variable-sized event frame

On 6/17/2024 1:45 AM, Xin Li (Intel) wrote:
> This was initially posted as part of the FRED patch series and turned
> down due to its unacceptable quality:
>    https://lore.kernel.org/lkml/20230410081438.1750-31-xin3.li@intel.com/
> 
> And this is another attempt to meet the bar.
> 

I'm expecting to get some review comments on this patch set :-)

> 
> a FRED event frame could contain different amount of information for
> different event types, e.g., #MCE could push extra bytes of information,
> or perhaps even for different instances of the same event type. Thus
> the size of an event frame pushed by a FRED CPU is not fixed and the
> address of a pt_regs structure that is used to save the user level
> context of current task is not at a fixed offset from top of current
> task kernel stack.
> 
> This patch set adds a new field named 'user_pt_regs' in the thread_info
> structure to save the address of user level context pt_regs structure,
> thus to eliminate the need of any advance information of event frame
> size and allow a FRED CPU to push variable-sized event frame.
> 
> With the above change, we can
> 1) Remove the padding space at top of the init stack because there is
>     no user level context for init task.
> 2) Get rid of TOP_OF_KERNEL_STACK_PADDING on x86_64, which was defined
>     to 0 for IDT to keep the code consistent with 32bit.
> 
> 
> Xin Li (Intel) (3):
>    x86/fred: Allow variable-sized event frame
>    x86: Remove the padding space at top of the init stack
>    x86: Get rid of TOP_OF_KERNEL_STACK_PADDING on x86_64
> 
>   arch/x86/entry/entry_fred.c        | 22 +++++++++++++++++
>   arch/x86/include/asm/processor.h   | 38 +++++++++++++++++++++++-------
>   arch/x86/include/asm/switch_to.h   |  2 +-
>   arch/x86/include/asm/thread_info.h | 19 +++++----------
>   arch/x86/kernel/process.c          | 21 +++++++++++++++++
>   arch/x86/kernel/vmlinux.lds.S      | 18 ++++++++++++--
>   include/linux/thread_info.h        |  1 +
>   kernel/fork.c                      |  6 +++++
>   8 files changed, 102 insertions(+), 25 deletions(-)
> 
> 
> base-commit: 49b33979e3bf0a5424420d14f026de12f34e8b1e


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ