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] [thread-next>] [day] [month] [year] [list]
Message-ID: <061a4299-114f-96e0-86a4-6ab255778498@huawei.com>
Date:   Tue, 24 May 2022 22:24:55 +0800
From:   Chen Zhongjin <chenzhongjin@...wei.com>
To:     <madvenka@...ux.microsoft.com>, <jpoimboe@...hat.com>,
        <peterz@...radead.org>, <mark.rutland@....com>,
        <broonie@...nel.org>, <nobuta.keiya@...itsu.com>,
        <sjitindarsingh@...il.com>, <catalin.marinas@....com>,
        <will@...nel.org>, <jamorris@...ux.microsoft.com>,
        <linux-arm-kernel@...ts.infradead.org>,
        <live-patching@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2 00/20] arm64: livepatch: Use ORC for dynamic frame
 pointer validation

Hi Madvenka,

I have a brief look at your patch and the idea that using CFA metadata to
validate FP is reasonable to me. And I found a problem when I used 'pv dump' to
check the orc value and I replied your commit 11/20 for that.

I think it's not necessary that you rewrite the arm64 decoder(there is already a
decoder in my patch) and insn check(objtool check can just make it) by yourself.
Especially it is too duplicated to have two check in objtool.

For me it's also a trouble that objtool runs too much unnecessary work. I advise
that we should move some check for x86 as arch specific and refactor the cmdline
options, they doesn't turn off everything perfectly now.

Other than that I have an advise: We only use orc for reliable stacktrace and
normal FP unwind doesn't depends on it. Should we only load these data for
livepatch (or other scenario needs reliable stacktrace)? It can save the memory
and time consuming for kernel.

That's all. And if you don't mind, can I incorporate some commit into my set?
Appreciate for it.

Best,
Chen

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ