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  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]
Date:   Fri, 29 May 2020 10:05:05 +1000
From:   Michael Ellerman <>
To:     Daniel Borkmann <>,
        Petr Mladek <>
Cc:     Miroslav Benes <>,
        Benjamin Herrenschmidt <>,
        Paul Mackerras <>,,,
        Alexei Starovoitov <>,
        Masami Hiramatsu <>,
        Brendan Gregg <>,
        Christoph Hellwig <>,
Subject: Re: [PATCH] powerpc/bpf: Enable bpf_probe_read{, str}() on powerpc again

Daniel Borkmann <> writes:
> On 5/28/20 2:23 PM, Michael Ellerman wrote:
>> Petr Mladek <> writes:
>>> On Thu 2020-05-28 11:03:43, Michael Ellerman wrote:
>>>> Petr Mladek <> writes:
>>>>> The commit 0ebeea8ca8a4d1d453a ("bpf: Restrict bpf_probe_read{, str}() only
>>>>> to archs where they work") caused that bpf_probe_read{, str}() functions
>>>>> were not longer available on architectures where the same logical address
>>>>> might have different content in kernel and user memory mapping. These
>>>>> architectures should use probe_read_{user,kernel}_str helpers.
>>>>> For backward compatibility, the problematic functions are still available
>>>>> on architectures where the user and kernel address spaces are not
>>>>> overlapping. This is defined CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE.
>>>>> At the moment, these backward compatible functions are enabled only
>>>>> on x86_64, arm, and arm64. Let's do it also on powerpc that has
>>>>> the non overlapping address space as well.
>>>>> Signed-off-by: Petr Mladek <>
>>>> This seems like it should have a Fixes: tag and go into v5.7?
>>> Good point:
>>> Fixes: commit 0ebeea8ca8a4d1d4 ("bpf: Restrict bpf_probe_read{, str}() only to archs where they work")
>>> And yes, it should ideally go into v5.7 either directly or via stable.
>>> Should I resend the patch with Fixes and
>>> Cc: #v45.7 lines, please?
>> If it goes into v5.7 then it doesn't need a Cc: stable, and I guess a
>> Fixes: tag is nice to have but not so important as it already mentions
>> the commit that caused the problem. So a resend probably isn't
>> necessary.
>> Acked-by: Michael Ellerman <>
>> Daniel can you pick this up, or should I?
> Yeah I'll take it into bpf tree for v5.7.



Powered by blists - more mailing lists