On Tue, Aug 31, 2021 at 5:09 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > On Sat, Jun 19, 2021 at 12:18 AM Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > > On Wed, Jun 16, 2021 at 1:51 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: ... > > > diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c > > > index 2acc6173da36..c1747b6555c7 100644 > > > --- a/drivers/cxl/mem.c > > > +++ b/drivers/cxl/mem.c > > > @@ -568,7 +568,7 @@ static bool cxl_mem_raw_command_allowed(u16 opcode) > > > if (!IS_ENABLED(CONFIG_CXL_MEM_RAW_COMMANDS)) > > > return false; > > > > > > - if (security_locked_down(LOCKDOWN_NONE)) > > > + if (security_locked_down(current_cred(), LOCKDOWN_NONE)) > > > > Acked-by: Dan Williams <dan.j.williams@xxxxxxxxx> > > > > ...however that usage looks wrong. The expectation is that if kernel > > integrity protections are enabled then raw command access should be > > disabled. So I think that should be equivalent to LOCKDOWN_PCI_ACCESS > > in terms of the command capabilities to filter. > > Yes, the LOCKDOWN_NONE seems wrong here... but it's a pre-existing bug > and I didn't want to go down yet another rabbit hole trying to fix it. > I'll look at this again once this patch is settled - it may indeed be > as simple as replacing LOCKDOWN_NONE with LOCKDOWN_PCI_ACCESS. At this point you should be well aware of my distaste for merging patches that have known bugs in them. Yes, this is a pre-existing condition, but it seems well within the scope of this work to address it as well. This isn't something that is going to get merged while the merge window is open, so at the very least you've got almost two weeks to sort this out - please do that. -- paul moore www.paul-moore.com
