From: Kees Cook <keescook@chromium.org>
To: Borislav Petkov <bp@alien8.de>
Cc: tglx@linutronix.de, Guixiong Wei <weiguixiong@bytedance.com>,
jgross@suse.com, mingo@redhat.com, dave.hansen@linux.intel.com,
x86@kernel.org, hpa@zytor.com, peterz@infradead.org,
gregkh@linuxfoundation.org, tony.luck@intel.com,
adobriyan@gmail.com, linux-kernel@vger.kernel.org,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH] x86, relocs: Ignore relocations in .notes section on walk_relocs
Date: Mon, 25 Mar 2024 13:23:31 -0700 [thread overview]
Message-ID: <202403251318.EA2603C8@keescook> (raw)
In-Reply-To: <20240323103827.GAZf6xI94u8F9LGBIL@fat_crate.local>
On Sat, Mar 23, 2024 at 11:38:27AM +0100, Borislav Petkov wrote:
> On Fri, Mar 22, 2024 at 04:40:11PM -0700, Kees Cook wrote:
> > The earlier patch, commit aaa8736370db ("x86, relocs: Ignore relocations
> > in .notes section"), landed via my tree. It was sent out on Feb 22nd
> > (v1[1]) and got a suggestion from HPA and a Review from Juergen Gross.
> > I sent v2 Feb 27th[2] and it sat ignored for two weeks.
>
> s/ignored for two weeks/missed in the avalance of patches/
>
> > Since it was a 10 year old kernel address exposure, I sent it to Linus
> > on Mar 12th[3].
>
> So is there some unwritten understanding somewhere which says that you
> should take tip patches through your tree?
>
> Maybe I've missed it.
>
> If there isn't, should we agree on something?
>
> Because there clearly is a need for clarification here...
Yeah, happy to figure this out. How should I handle x86 patches that
maintainers haven't responded to when they have security bug fix
implications? For all the security hardening stuff I usually just ping
every few weeks, but those don't usually tend to be urgent.
In this case, I felt like since it was a trivial fix, HPA had already
implied it was a sensible change, and Juergen had reviewed it, it seemed
like it wouldn't be disruptive to take it, given the timing of the merge
window, etc.
--
Kees Cook
next prev parent reply other threads:[~2024-03-25 20:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-17 15:05 [PATCH] x86, relocs: Ignore relocations in .notes section on walk_relocs Guixiong Wei
2024-03-18 21:40 ` Kees Cook
2024-03-18 21:56 ` Borislav Petkov
2024-03-18 23:45 ` Kees Cook
2024-03-19 8:16 ` Borislav Petkov
2024-03-19 16:56 ` Kees Cook
2024-03-22 19:46 ` Borislav Petkov
2024-03-22 23:40 ` Kees Cook
2024-03-23 10:38 ` Borislav Petkov
2024-03-25 20:23 ` Kees Cook [this message]
2024-03-22 8:45 ` Ingo Molnar
2024-03-22 23:41 ` Kees Cook
2024-03-24 3:57 ` [PATCH] x86/build: Clean up arch/x86/tools/relocs.c a bit Ingo Molnar
2024-03-22 8:56 ` [tip: x86/boot] x86/boot: Ignore relocations in .notes sections in walk_relocs() too tip-bot2 for Guixiong Wei
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=202403251318.EA2603C8@keescook \
--to=keescook@chromium.org \
--cc=adobriyan@gmail.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=weiguixiong@bytedance.com \
--cc=x86@kernel.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.