All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Kees Cook <keescook@chromium.org>, Lv Zheng <lv.zheng@intel.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Christoph Hellwig <hch@infradead.org>,
	"kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>,
	LKML <linux-kernel@vger.kernel.org>, Len Brown <lenb@kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Robert Moore <robert.moore@intel.com>
Subject: [kernel-hardening] Re: [PATCH 3/4] randstruct: Disable randomization of ACPICA structs
Date: Fri, 23 Jun 2017 01:59:37 +0200	[thread overview]
Message-ID: <3395263.N2PfeMfNmG@aspire.rjw.lan> (raw)
In-Reply-To: <CAGXu5jJWZos+uUgyc6hiHko=ei4b_6aCyZqRLDESfih1ybxR=w@mail.gmail.com>

On Thursday, June 22, 2017 04:57:39 PM Kees Cook wrote:
> On Tue, Jun 20, 2017 at 2:34 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > On Tue, Jun 20, 2017 at 10:35 PM, Christoph Hellwig <hch@infradead.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.

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?

Thanks,
Rafael

WARNING: multiple messages have this Message-ID (diff)
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Kees Cook <keescook@chromium.org>, Lv Zheng <lv.zheng@intel.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Christoph Hellwig <hch@infradead.org>,
	"kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>,
	LKML <linux-kernel@vger.kernel.org>, Len Brown <lenb@kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Robert Moore <robert.moore@intel.com>
Subject: Re: [PATCH 3/4] randstruct: Disable randomization of ACPICA structs
Date: Fri, 23 Jun 2017 01:59:37 +0200	[thread overview]
Message-ID: <3395263.N2PfeMfNmG@aspire.rjw.lan> (raw)
In-Reply-To: <CAGXu5jJWZos+uUgyc6hiHko=ei4b_6aCyZqRLDESfih1ybxR=w@mail.gmail.com>

On Thursday, June 22, 2017 04:57:39 PM Kees Cook wrote:
> On Tue, Jun 20, 2017 at 2:34 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > On Tue, Jun 20, 2017 at 10:35 PM, Christoph Hellwig <hch@infradead.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.

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?

Thanks,
Rafael


  reply	other threads:[~2017-06-22 23:59 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-19 20:56 [kernel-hardening] [PATCH v3 0/4] randstruct: Enable function pointer struct detection Kees Cook
2017-06-19 20:56 ` Kees Cook
2017-06-19 20:56 ` [kernel-hardening] [PATCH 1/4] task_struct: Allow randomized layout Kees Cook
2017-06-19 20:56   ` Kees Cook
2018-03-26 11:52   ` Peter Zijlstra
2018-03-26 12:03     ` Peter Zijlstra
2018-03-26 17:43       ` Kees Cook
2017-06-19 20:56 ` [kernel-hardening] [PATCH 2/4] randstruct: opt-out externally exposed function pointer structs Kees Cook
2017-06-19 20:56   ` Kees Cook
2017-06-19 20:56 ` [kernel-hardening] [PATCH 3/4] randstruct: Disable randomization of ACPICA structs Kees Cook
2017-06-19 20:56   ` Kees Cook
2017-06-20  6:56   ` [kernel-hardening] " Christoph Hellwig
2017-06-20  6:56     ` Christoph Hellwig
2017-06-20 19:25     ` [kernel-hardening] " Kees Cook
2017-06-20 19:25       ` Kees Cook
2017-06-20 20:35       ` [kernel-hardening] " Christoph Hellwig
2017-06-20 20:35         ` Christoph Hellwig
2017-06-20 20:52         ` [kernel-hardening] " Rafael J. Wysocki
2017-06-20 20:52           ` Rafael J. Wysocki
2017-06-20 21:34         ` [kernel-hardening] " Rafael J. Wysocki
2017-06-20 21:34           ` Rafael J. Wysocki
2017-06-22 23:57           ` [kernel-hardening] " Kees Cook
2017-06-22 23:57             ` Kees Cook
2017-06-22 23:59             ` Rafael J. Wysocki [this message]
2017-06-22 23:59               ` Rafael J. Wysocki
2017-06-23  0:20               ` [kernel-hardening] " Kees Cook
2017-06-23  0:20                 ` Kees Cook
2017-06-19 20:56 ` [kernel-hardening] [PATCH 4/4] randstruct: Enable function pointer struct detection Kees Cook
2017-06-19 20:56   ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3395263.N2PfeMfNmG@aspire.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=hch@infradead.org \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lv.zheng@intel.com \
    --cc=rafael@kernel.org \
    --cc=robert.moore@intel.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.