linux-kernel - [PATCH 0/3] Regset cleanups

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

Message-Id: <20220315201706.7576-1-rick.p.edgecombe@intel.com>
Date:   Tue, 15 Mar 2022 13:17:03 -0700
From:   Rick Edgecombe <rick.p.edgecombe@...el.com>
To:     dave.hansen@...el.com, len.brown@...el.com, tony.luck@...el.com,
        rafael.j.wysocki@...el.com, reinette.chatre@...el.com,
        dan.j.williams@...el.com, viro@...iv.linux.org.uk,
        ebiederm@...ssion.com, keescook@...omium.org
Cc:     Rick Edgecombe <rick.p.edgecombe@...el.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH 0/3] Regset cleanups

Hi,

I’m looking for ack’s from Intel reviewer’s before this is ready for official
submission to x86 maintainers. Patch 3 is in core code, so also including
relevant MAINTAINERS file people for that one. If you are not an Intel reviewer,
feel free to ignore this until it has had more review. Glad for any feedback all
the same. I’m also, wondering if this is something that could go through the x86
tree all together or I should split it out.

While working on CET ptrace support, I found some suggested cleanups [0] [1] on
past postings of that patch. So this small series is doing those cleanups and
some related changes.

Way back then, it was noticed that CET ptrace patches were aliasing names in the
enum that indexes the regsets. It turns out this was partly because of a
limitation in core dump code that reads the registers for dumping. But excluding
gaps in the regset array also allows them to be smaller, so just fixing the core
dump code doesn’t remove all need for the specially crafted enum. So series
changes the way the enums are defined such that enum has to be less carefully
crafted, and also fixes the core dump code.

Patch 1 is improving the enums in x86 ptrace code.

Patch 2 is some x86 ptrace code formatting changes suggested by Ingo. [0]

Patch 3 is the fix to the core dump code. Just to be clear, there is no actual
bug fixed. It would only overflow an array if the regset views were not laid out
just so. But the regsets appear to be laid out so that the brittle code is not
broken, from a quick scan of the archs.

Testing consisted of doing some core dumps and seeing that notes were in the
same position, and verifying that the enum’s generated the same ints using
printks.

Thanks,

Rick

[0] https://lore.kernel.org/lkml/20180711102035.GB8574@gmail.com/
[1] https://lore.kernel.org/lkml/A7775E11-8837-4727-921A-C88566FA01AF@amacapital.net/

Rick Edgecombe (3):
  x86: Separate out x86_regset for 32 and 64 bit
  x86: Improve formatting of user_regset arrays
  elf: Don't write past end of notes for regset gap

 arch/x86/kernel/ptrace.c | 165 ++++++++++++++++++++++++---------------
 fs/binfmt_elf.c          |  15 ++--
 2 files changed, 111 insertions(+), 69 deletions(-)

base-commit: 09688c0166e76ce2fb85e86b9d99be8b0084cdf9
-- 
2.17.1