On Tue, Aug 31, 2021 at 6:53 AM Paul Moore [off-list ref] wrote:

On Tue, Aug 31, 2021 at 5:09 AM Ondrej Mosnacek [off-list ref] wrote:

quoted

On Sat, Jun 19, 2021 at 12:18 AM Dan Williams [off-list ref] wrote:

quoted

On Wed, Jun 16, 2021 at 1:51 AM Ondrej Mosnacek [off-list ref] wrote:

...

quoted

quoted

quoted

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 <redacted>

...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.

Yes, apologies, I should have sent the fix shortly after noticing the
problem. I'll get the CXL bug fix out of the way so Ondrej can move
this along.