public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Rick Edgecombe <rick.p.edgecombe@intel.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org, ebiederm@xmission.com
Subject: Re: [PATCH 1/2] x86: Separate out x86_regset for 32 and 64 bit
Date: Fri, 21 Oct 2022 16:55:24 -0700	[thread overview]
Message-ID: <202210211655.65734A3F@keescook> (raw)
In-Reply-To: <20221021221803.10910-2-rick.p.edgecombe@intel.com>

On Fri, Oct 21, 2022 at 03:18:02PM -0700, Rick Edgecombe wrote:
> In fill_thread_core_info() the ptrace accessible registers are collected
> for a core file to be written out as notes. The note array is allocated
> from a size calculated by iterating the user regset view, and counting the
> regsets that have a non-zero core_note_type. However, this only allows for
> there to be non-zero core_note_type at the end of the regset view. If
> there are any in the middle, fill_thread_core_info() will overflow the
> note allocation, as it iterates over the size of the view and the
> allocation would be smaller than that.
> 
> To apparently avoid this problem, x86_32_regsets and x86_64_regsets need
> to be constructed in a special way. They both draw their indices from a
> shared enum x86_regset, but 32 bit and 64 bit don't all support the same
> regsets and can be compiled in at the same time in the case of
> IA32_EMULATION. So this enum has to be laid out in a special way such that
> there are no gaps for both x86_32_regsets and x86_64_regsets. This
> involves ordering them just right by creating aliases for enum’s that
> are only in one view or the other, or creating multiple versions like
> REGSET32_IOPERM/REGSET64_IOPERM.
> 
> So the collection of the registers tries to minimize the size of the
> allocation, but it doesn’t quite work. Then the x86 ptrace side works
> around it by constructing the enum just right to avoid a problem. In the
> end there is no functional problem, but it is somewhat strange and
> fragile.
> 
> It could also be improved like this [1], by better utilizing the smaller
> array, but this still wastes space in the regset array’s if they are not
> carefully crafted to avoid gaps. Instead, just fully separate out the
> enums and give them separate 32 and 64 enum names. Add some bitsize-free
> defines for REGSET_GENERAL and REGSET_FP since they are the only two
> referred to in bitsize generic code.
> 
> While introducing a bunch of new 32/64 enums, change the pattern of the
> name from REGSET_FOO32 to REGSET32_FOO to better indicate that the 32 is
> in reference to the CPU mode and not the register size, as suggested by
> Eric Biederman.
> 
> This should have no functional change and is only changing how constants
> are generated and referred to.
> 
> [1] https://lore.kernel.org/lkml/20180717162502.32274-1-yu-cheng.yu@intel.com/
> 
> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

  reply	other threads:[~2022-10-21 23:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-21 22:18 [PATCH 0/2] Regset cleanups Rick Edgecombe
2022-10-21 22:18 ` [PATCH 1/2] x86: Separate out x86_regset for 32 and 64 bit Rick Edgecombe
2022-10-21 23:55   ` Kees Cook [this message]
2022-10-21 22:18 ` [PATCH 2/2] x86: Improve formatting of user_regset arrays Rick Edgecombe
2022-10-21 23:56   ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202210211655.65734A3F@keescook \
    --to=keescook@chromium.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox