Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 22 Jun 2017 17:20:31 -0700
From: Kees Cook <>
To: "Rafael J. Wysocki" <>
Cc: Lv Zheng <>, "Rafael J. Wysocki" <>, 
	Christoph Hellwig <>, 
	"" <>, LKML <>, 
	Len Brown <>, ACPI Devel Maling List <>, 
	Linus Torvalds <>, Robert Moore <>
Subject: Re: [PATCH 3/4] randstruct: Disable randomization of ACPICA structs

On Thu, Jun 22, 2017 at 4:59 PM, Rafael J. Wysocki <> wrote:
> On Thursday, June 22, 2017 04:57:39 PM Kees Cook wrote:
>> On Tue, Jun 20, 2017 at 2:34 PM, Rafael J. Wysocki <> wrote:
>> > On Tue, Jun 20, 2017 at 10:35 PM, Christoph Hellwig <> wrote:
>> >> On Tue, Jun 20, 2017 at 12:25:53PM -0700, Kees Cook wrote:
>> >>> Can you send the patch to ? 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.
> Usually, when there's a new ACPICA release, but occasionally that happens
> faster.
> Which commit in upstream ACPICA is this?

>> 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?
> Maybe we can simply forward port the ACPICA commit right away.
> Lv, can you take care of this, please?

That would be great, thanks!


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.