Re: kpatch and kasan

[Dmitry Vyukov]

On Wed, 18 Jan 2023 at 17:10, Joe Lawrence <joe.la...@redhat.com> wrote:
>
> On 1/18/23 10:21, Dmitry Vyukov wrote:
> > On Wed, 18 Jan 2023 at 14:45, Joe Lawrence <joe.la...@redhat.com> wrote:
> >>
> >> On 1/18/23 02:21, Dmitry Vyukov wrote:
> >>> On Tue, 17 Jan 2023 at 17:50, Kostya Serebryany <k...@google.com> wrote:
> >>>>
> >>>> +kernel-dynamic-tools
> >>>>
> >>>> On Tue, Jan 17, 2023 at 6:32 AM Joe Lawrence <joe.la...@redhat.com> wrote:
> >>>>>
> >>>>> Hi Kostya,
> >>>>>
> >>>>> I work on the kernel livepatching Kpatch project [1] and was hoping to
> >>>>> learn some info about compiler-generated (k)asan ELF sections. If you
> >>>>> can point me to any references or folks who might entertain questions,
> >>>>> we would be much appreciated.
> >>>>>
> >>>>> The tl/dr; is that we would like to build kasan-enabled debug kernels
> >>>>> and then kpatches for them to help verify CVE mitigations.
> >>>>>
> >>>>> If you are unfamiliar with kpatch, it accepts an input .patch file,
> >>>>> builds a reference and patched kernel (with -ffunction-sections and
> >>>>> -fdata-sections) ... then performs a binary comparison between
> >>>>> reference/patched ELF sections. New or changed ELF sections are
> >>>>> extracted into a new object file. Boilerplate code is then added to
> >>>>> create a livepatch kernel module from that.
> >>>>>
> >>>>> The devil is in details, of course, so our kpatch-build tool needs to
> >>>>> know whether it should omit, copy, or re-generate an ELF section
> >>>>> depending on its purpose. The kernel is rife with interesting sections
> >>>>> like para-virt instructions, jump labels, static call sites, etc.
> >>>>>
> >>>>> So, before trying to reverse engineer sections like .data..LASANLOC1 and
> >>>>> data..LASAN0 from the gcc source code, I was wondering if these were
> >>>>> documented somewhere?
> >>>>>
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> [1] https://github.com/dynup/kpatch
> >>>>> --
> >>>>> Joe
> >>>
> >>> +kasan-dev
> >>>
> >>> Hi Joe,
> >>>
> >>> But why not just build a new KASAN kernel and re-test? This looks so
> >>> much simpler.
> >>>
> >>
> >> Hi Dmitry,
> >>
> >> Well yes, testing an ordinary (fixed) kernel build is much easier, however:
> >>
> >> 1 - Sometimes kpatches deviate from their kernel counterparts. Examples
> >> include ABI changes, fixups in initialization code, etc.
> >
> > This does not prevent testing in a normal way, right? In fact I would
> > send the patch to the normal CI as the first thing.
> >
>
> Exactly. At Red Hat, we typically wait for a corresponding kernel fix
> to pass tests before starting on our kpatch conversion (emergency CVEs
> aside) ... that way we're usually confident with the overall changes
> before we even start our work.
>
> In cases where the kernel fixes are verified via reproducer and KASAN
> enabled config, as long as our version is mostly 1:1 we can still be
> confident. Giving our QA team a similar obvious verification with KASAN
> enabled kpatch would be bonus.

I meant the source patch used to create the kpatch, not some other patch.
Kpatch is also based on some normal source code patch, right? If so,
that exact patch used to create kpatch can be testing as a normal
patch, right?

Back to your actual question. I think sections like .data..LASANLOC1
and data..LASAN0 should be treated just as normal .data/.rodata
sections. git grep "ASANLOC" in llvm does not give me anything, but I
would assume these contain string descriptions used in KASAN reports.