On Mon, Mar 5, 2018 at 1:21 PM, Alexander Popov <alex.po...@linux.com> wrote: > On 05.03.2018 23:25, Peter Zijlstra wrote: >> On Mon, Mar 05, 2018 at 11:43:19AM -0800, Laura Abbott wrote: >>> On 03/05/2018 08:41 AM, Dave Hansen wrote: >>>> On 03/03/2018 12:00 PM, Alexander Popov wrote: >>>>> Documentation/x86/x86_64/mm.txt | 2 + >>>>> arch/Kconfig | 27 ++++++++++ >>>>> arch/x86/Kconfig | 1 + >>>>> arch/x86/entry/entry_32.S | 88 +++++++++++++++++++++++++++++++ >>>>> arch/x86/entry/entry_64.S | 108 >>>>> +++++++++++++++++++++++++++++++++++++++ >>>>> arch/x86/entry/entry_64_compat.S | 11 ++++ >>>> >>>> This is a *lot* of assembly. I wonder if you tried at all to get more >>>> of this into C or whether you just inherited the assembly from the >>>> original code? >>>> >>> >>> This came up previously >>> http://www.openwall.com/lists/kernel-hardening/2017/10/23/5 >>> there were concerns about trusting C to do the right thing as well as >>> speed. >> >> And therefore the answer to this obvious question should've been part of >> the Changelog :-) >> >> Dave is last in a long line of people asking this same question. > > Yes, actually the changelog in the cover letter contains that: > > After some experiments, kept the asm implementation of erase_kstack(), > because it gives a full control over the stack for clearing it neatly > and doesn't offend KASAN. > > Moreover, later erase_kstack() on x86_64 became different from one on x86_32.
Maybe explicitly mention the C experiments in future change log? -Kees -- Kees Cook Pixel Security
