[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jJWZos+uUgyc6hiHko=ei4b_6aCyZqRLDESfih1ybxR=w@mail.gmail.com>
Date: Thu, 22 Jun 2017 16:57:39 -0700
From: Kees Cook <keescook@...omium.org>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Christoph Hellwig <hch@...radead.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, LKML <linux-kernel@...r.kernel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>, Len Brown <lenb@...nel.org>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>, Linus Torvalds <torvalds@...ux-foundation.org>,
Robert Moore <robert.moore@...el.com>, Lv Zheng <lv.zheng@...el.com>
Subject: Re: [PATCH 3/4] randstruct: Disable randomization of ACPICA structs
On Tue, Jun 20, 2017 at 2:34 PM, Rafael J. Wysocki <rafael@...nel.org> wrote:
> On Tue, Jun 20, 2017 at 10:35 PM, Christoph Hellwig <hch@...radead.org> wrote:
>> On Tue, Jun 20, 2017 at 12:25:53PM -0700, Kees Cook wrote:
>>> Can you send the patch to https://github.com/acpica/acpica ? My change
>>> was finally accepted, so this whole issue will go away on the next
>>> refresh. Until then, I don't want to block the entire automatic
>>> structure selection logic of randstruct on a three-function table. :)
>>
>> I do not have a github account and no such thing is required for kernel
>> development.
>
> It isn't required for the ACPICA material either.
>
> You just need to CC the ACPICA maintainers, as per MAINTAINERS, on
> your ACPICA patches. They pick up stuff that looks good to them.
>
> And we tend to prefer routing ACPICA changes through the upstream,
> because failing to do so usually turns out to be painful in the long
> term. I don't think it is unreasonable to ask for cooperation in that
> respect.
I'd like to unblock randstruct, so what's the easiest way to move
this? My version of changes have already landed upstream in ACPICA,
but I don't know how frequently they get flushed back into the kernel.
I can't turn on randstruct auto-selection in -next without either
ACPICA using (or not needing) designated initializers or just
blacklisting it in the randstruct plugin itself. I would much prefer
the latter as the problem is solved in ACPICA upstream already but
just isn't in the kernel yet, and I want to get testing of the
auto-selection ASAP. Once it's in the kernel I can drop the blacklist.
Christoph: how about a middle ground where randstruct blacklists
ACPICA in -next and if ACPICA is fixed by the time the merge window
opens, I'll drop the blacklist. That gets the testing coverage without
what you see as an ugly hack right now. I just really don't want to
waste any more time on this since there are SO many other randomized
structures I'd like to be sure are getting testing.
Alternatively, if the ACPICA folks Ack Christoph's patch, I can carry
that in the randstruct tree for -next instead?
Thanks,
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
