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: <20230710002507.dae543b98d1cc1f950a165bd@kernel.org>
Date:   Mon, 10 Jul 2023 00:25:07 +0900
From:   Masami Hiramatsu (Google) <mhiramat@...nel.org>
To:     Petr Pavlu <petr.pavlu@...e.com>
Cc:     Peter Zijlstra <peterz@...radead.org>, tglx@...utronix.de,
        mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
        hpa@...or.com, samitolvanen@...gle.com, x86@...nel.org,
        linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] x86/retpoline,kprobes: Avoid treating rethunk as an
 indirect jump

On Sat, 8 Jul 2023 16:18:29 +0200
Petr Pavlu <petr.pavlu@...e.com> wrote:

> On 7/6/23 13:34, Peter Zijlstra wrote:
> > On Thu, Jul 06, 2023 at 06:00:14PM +0900, Masami Hiramatsu wrote:
> >> On Thu, 6 Jul 2023 09:17:05 +0200
> >> Peter Zijlstra <peterz@...radead.org> wrote:
> >>
> >>> On Thu, Jul 06, 2023 at 09:47:23AM +0900, Masami Hiramatsu wrote:
> >>>
> >>>>>> If I understand correctly, all indirect jump will be replaced with JMP_NOSPEC.
> >>>>>> If you read the insn_jump_into_range, I onlu jecks the jump code, not call.
> >>>>>> So the functions only have indirect call still allow optprobe.
> >>>>>
> >>>>> With the introduction of kCFI JMP_NOSPEC is no longer an equivalent to a
> >>>>> C indirect jump.
> >>>>
> >>>> If I understand correctly, kCFI is enabled by CFI_CLANG, and clang is not
> >>>> using jump-tables by default, so we can focus on gcc. In that case
> >>>> current check still work, correct?
> >>>
> >>> IIRC clang can use jump tables, but like GCC needs RETPOLINE=n and
> >>> IBT=n, so effectively nobody has them.
> >>
> >> So if it requires RETPOLINE=n, current __indirect_thunk_start/end checking
> >> is not required, right? (that code is embraced with "#ifdef CONFIG_RETPOLINE")
> > 
> > Correct.
> 
> Thank you both for the explanation.
> 
> If I understand correctly, it means this second patch can be dropped and
> I can instead replace it with a removal of the mentioned check. That
> will also void the main motivation for the first patch but that one
> should be still at least useful to make the LTO_CLANG=y build lay out
> the code in the same way as with other configurations.

Yes, something like removing __indirect_thunk_start/end check and 
disabling insn_is_indirect_jump() when defined(CONFIG_RETPOLINE) ||
 defined(CONFIG_X86_KERNEL_IBT).

kCFI case is also handled later but another series.

Thank you,

> 
> I will post an updated series with these changes.
> 
> -- Petr
> 


-- 
Masami Hiramatsu (Google) <mhiramat@...nel.org>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ