Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220830233129.30610-1-samitolvanen@google.com> <YxEh+pLyOyPalW1u@dev-arch.thelio-3990X>
In-Reply-To: <YxEh+pLyOyPalW1u@dev-arch.thelio-3990X>
From:   Sami Tolvanen <samitolvanen@google.com>
Date:   Thu, 1 Sep 2022 17:33:29 -0700
Message-ID: <CABCJKucP5nXGiCTTCEPUGYo5Z9A9qaQkJ6_kXTOfw-o-=TYH0g@mail.gmail.com>
Subject: Re: [PATCH v4 00/21] KCFI support
To:     Nathan Chancellor <nathan@kernel.org>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Kees Cook <keescook@chromium.org>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>, X86 ML <x86@kernel.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Joao Moreira <joao@overdrivepizza.com>,
        Sedat Dilek <sedat.dilek@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        linux-hardening@vger.kernel.org,
        linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
        llvm@lists.linux.dev
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Nathan,

On Thu, Sep 1, 2022 at 2:19 PM Nathan Chancellor <nathan@kernel.org> wrote:
> I took this series for a spin on arm64 and x86_64.

Thanks for testing!

> I did not see any runtime issues on my arm64 or AMD test machines but I
> do see a set of failures on my two Intel test machines when accessing
> the files in /sys/devices/pci0000:00/0000:00:02.0/drm/card0/gt/gt0:

Yes, I suspect there are a few sysfs type mismatches left to fix
still. I believe Kees was looking into these earlier.

> The source of those is drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c. I
> have not looked too closely yet but the fix should be something along
> the lines of commit 58606220a2f1 ("drm/i915: Fix CFI violation with
> show_dynamic_id()").

I don't have hardware for testing this driver, but that looks like a
typical kobj_attribute / device_attribute mismatch, which happens to
work because struct device starts with a kobject and the attribute
structure is identical. I can take a look at this next week.

> Interestingly, I do not see the KVM failure [1] that I reported anymore.
> I do not see an obvious fix for it in this series or -next though, could
> it have been an issue with an earlier revision of kCFI on the compiler
> side?

Most likely the compiler either converted it into a direct call, or
inlined it. There are a few type mismatches in the kernel still that
don't trip KCFI because they're optimized into direct calls.

> I do see a few new objtool warnings as well:
>
> vmlinux.o: warning: objtool: apply_relocate_add+0x34: relocation to !ENDBR: memcpy+0x0
> vmlinux.o: warning: objtool: ___ksymtab+__memcpy+0x0: data relocation to !ENDBR: memcpy+0x0
> vmlinux.o: warning: objtool: ___ksymtab+memcpy+0x0: data relocation to !ENDBR: memcpy+0x0

That's interesting. I can only reproduce this warning with
allmodconfig+LTO, even though the relocation exists in all builds (the
code makes an indirect call to memcpy) and memcpy (aliased to
__memcpy) doesn't start with endbr. I'll have to take a closer look at
why this warning only appears with LTO.

Sami