[PATCH] powerpc/mem: Add back missing header to fix 'no previous prototype' error
Commit b26e8f27253a ("powerpc/mem: Move cache flushing functions into
mm/cacheflush.c") removed asm/sparsemem.h which is required when
CONFIG_MEMORY_HOTPLUG is selected to get the declaration of
create_section_mapping().
Add it back.
Fixes: b26e8f27253a ("powerpc/mem: Move cache flushing functions into
mm/cacheflush.c")
Cc: sta...@vger.kernel.org
Reported-by: kernel test robot
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/mem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 043bbeaf407c..a6b36a40897a 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
--
2.25.0
Re: simplify gendisk and request_queue allocation for blk-mq based drivers
On Fri, Jun 04, 2021 at 11:58:34AM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Jun 02, 2021 at 09:53:15AM +0300, Christoph Hellwig wrote: > > Hi all, > > Hi! > > You wouldn't have a nice git repo to pull so one can test it easily? git://git.infradead.org/users/hch/block.git alloc_disk-part2
Re: [PATCH v2] lockdown,selinux: avoid bogus SELinux lockdown permission checks
On 6/4/2021 5:08 PM, Alexei Starovoitov wrote: > On Fri, Jun 4, 2021 at 4:34 PM Paul Moore wrote: >>> Again, the problem is not limited to BPF at all. kprobes is doing register- >>> the hooks which are equivalent to the one of BPF. Anything in run-time >>> trying to prevent probe_read_kernel by kprobes or BPF is broken by design. >> Not being an expert on kprobes I can't really comment on that, but >> right now I'm focused on trying to make things work for the BPF >> helpers. I suspect that if we can get the SELinux lockdown >> implementation working properly for BPF the solution for kprobes won't >> be far off. > Paul, > > Both kprobe and bpf can call probe_read_kernel==copy_from_kernel_nofault > from all contexts. > Including NMI. Most of audit_log_* is not acceptable. > Just removing a wakeup is not solving anything. > Audit hooks don't belong in NMI. > Audit design needs memory allocation. Hence it's not suitable > for NMI and hardirq. But kprobes and bpf progs do run just fine there. > BPF, for example, only uses pre-allocated memory. You have fallen into a common fallacy. The fact that the "code runs" does not assure that the "system works right". In the security world we face this all the time, often with performance expectations. In this case the BPF design has failed to accommodate the long standing needs of audit and SELinux. Shifting the responsibility for these design flaws to SELinux is inappropriate. Integration of sub-systems is usually the burden of the newcomer, which in this case is BPF. Paul is doing the bulk of your work for you. Maybe you could step up to your responsibility and work with him, not against him.
Re: [PATCH v2] lockdown,selinux: avoid bogus SELinux lockdown permission checks
On Sat, Jun 5, 2021 at 11:11 AM Casey Schaufler wrote: > > You have fallen into a common fallacy. The fact that the "code runs" > does not assure that the "system works right". In the security world > we face this all the time, often with performance expectations. In this > case the BPF design has failed [..] I think it's the lockdown patches that have failed. They did the wrong thing, they didn't work, The report in question is for a regression. THERE ARE NO VALID ARGUMENTS FOR REGRESSIONS. Honestly, security people need to understand that "not working" is not a success case of security. It's a failure case. Yes, "not working" may be secure. But security in that case is *pointless*. Linus
Re: [PATCH v2] lockdown,selinux: avoid bogus SELinux lockdown permission checks
On Fri, Jun 4, 2021 at 8:08 PM Alexei Starovoitov wrote: > On Fri, Jun 4, 2021 at 4:34 PM Paul Moore wrote: > > > > > Again, the problem is not limited to BPF at all. kprobes is doing > > > register- > > > time hooks which are equivalent to the one of BPF. Anything in run-time > > > trying to prevent probe_read_kernel by kprobes or BPF is broken by design. > > > > Not being an expert on kprobes I can't really comment on that, but > > right now I'm focused on trying to make things work for the BPF > > helpers. I suspect that if we can get the SELinux lockdown > > implementation working properly for BPF the solution for kprobes won't > > be far off. > > Paul, Hi Alexei, > Both kprobe and bpf can call probe_read_kernel==copy_from_kernel_nofault > from all contexts. > Including NMI. Thanks, that is helpful. In hindsight it should have been obvious that kprobe/BPF would offer to insert code into the NMI handlers, but I don't recall it earlier in the discussion, it's possible I simply missed the mention. > Most of audit_log_* is not acceptable. > Just removing a wakeup is not solving anything. That's not really fair now is it? Removing the wakeups in audit_log_start() and audit_log_end() does solve some problems, although not all of them (i.e. the NMI problem being the 800lb gorilla). Because of the NMI case we're not going to solve the LSM/audit case anytime soon so it looks like we are going to have to fall back to the patch Daniel proposed. Acked-by: Paul Moore -- paul moore www.paul-moore.com
Re: [PATCH v2] lockdown,selinux: avoid bogus SELinux lockdown permission checks
On Sat, Jun 5, 2021 at 2:17 PM Linus Torvalds wrote: > On Sat, Jun 5, 2021 at 11:11 AM Casey Schaufler > wrote: > > > > You have fallen into a common fallacy. The fact that the "code runs" > > does not assure that the "system works right". In the security world > > we face this all the time, often with performance expectations. In this > > case the BPF design has failed [..] > > I think it's the lockdown patches that have failed. They did the wrong > thing, they didn't work, > > The report in question is for a regression. > > THERE ARE NO VALID ARGUMENTS FOR REGRESSIONS. To think I was worried we might end this thread without a bit of CAPS LOCK, whew! :) I don't think anyone in this discussion, even Casey's last comment, was denying that there was a problem. The discussion and the disagreements were about what a "proper" fix would be, and how one might implement that fix; of course there were different ideas of "proper" and implementations vary even when people agree, so things were a bit of a mess. If you want to get upset and shouty, I think there are a few things spread across the subsystems involved that would be worthy targets, but to say that Casey, myself, or anyone else who plays under security/ denied the problem in this thread is not fair, or correct, in my opinion. > Honestly, security people need to understand that "not working" is not > a success case of security. It's a failure case. I can't pretend to know what all of the "security people" are thinking, but I can say with a good degree of certainty that my goal is not to crash, panic, kill, or otherwise disable a user's system. When it comes to things like the LSM hooks, my goal is to try and make sure we have the right hooks in the right places so that admins and users have the tools they need to control access to their data and systems in the way that they choose. Sometimes this puts us at odds with other subsystems in the kernel, we saw that in this thread, but that's to be expected anytime you have competing priorities. The important part is that eventually we figure out some way to move forward, and the fact that we are still all making progress and putting out new kernel releases is proof that we are finding a way. That's what matters to me, and if I was forced to guess, I would imagine that matters quite a lot to most of us here. -- paul moore www.paul-moore.com
