From: Kees Cook <keescook@chromium.org>
To: Scott Branden <scott.branden@broadcom.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Stephen Boyd <stephen.boyd@linaro.org>,
Mimi Zohar <zohar@linux.ibm.com>,
David Howells <dhowells@redhat.com>,
Peter Jones <pjones@redhat.com>,
"Joel Fernandes (Google)" <joel@joelfernandes.org>,
linux-security-module@vger.kernel.org,
Paul Moore <paul@paul-moore.com>,
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
Matthew Garrett <matthewgarrett@google.com>,
James Morris <jmorris@namei.org>,
Matthew Wilcox <willy@infradead.org>,
KP Singh <kpsingh@google.com>,
"Serge E. Hallyn" <serge@hallyn.com>,
selinux@vger.kernel.org, Jessica Yu <jeyu@kernel.org>,
Hans de Goede <hdegoede@redhat.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-integrity@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Stephen Smalley <stephen.smalley.work@gmail.com>,
Randy Dunlap <rdunlap@infradead.org>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
Luis Chamberlain <mcgrof@kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Dave Olsthoorn <dave@bewaar.me>,
Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
Casey Schaufler <casey@schaufler-ca.com>,
linux-fsdevel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 00/13] Introduce partial kernel_read_file() support
Date: Fri, 17 Jul 2020 15:10:28 -0700 [thread overview]
Message-ID: <202007171506.CCE3902A9@keescook> (raw)
In-Reply-To: <8de85fc3-9f31-fc59-abc1-29f43fb90988@broadcom.com>
On Fri, Jul 17, 2020 at 12:17:02PM -0700, Scott Branden wrote:
> Thanks for sending out. This looks different than your other patch series.
Yes, it mutated in my head as I considered how all of this should hang
together, which is why I wanted to get it sent before the weekend. I'm
still trying to figure out why the fireware testsuite fails for me, etc.
> We should get the first 5 patches accepted now though as they are
> simple cleanups and fixes. That will reduce the number of outstanding
> patches in the series.
Agreed. I'd like to get some more eyes on it, but I can get it ready for
-next.
> At first glance the issue with the changes after that is the existing
> API assumes it has read the whole file and failed if it did not.
> Now, if the file is larger than the amount requested there is no indication?
The intention is to have old API users unchanged and new users can use
a pre-allocated buf (with buf_size) along with file_size to examine
their partial read progress. If I broke the old API, that's a bug and I
need to fix it, but that's why I wanted to start with the firmware test
suite (basic things like module loading work fine after this series, but
I wanted to really exercise the corners that the firmware suite pokes
at).
--
Kees Cook
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Scott Branden <scott.branden@broadcom.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>,
Matthew Wilcox <willy@infradead.org>,
James Morris <jmorris@namei.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Jessica Yu <jeyu@kernel.org>,
Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
"Serge E. Hallyn" <serge@hallyn.com>,
Casey Schaufler <casey@schaufler-ca.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Peter Zijlstra <peterz@infradead.org>,
Matthew Garrett <matthewgarrett@google.com>,
David Howells <dhowells@redhat.com>,
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
Randy Dunlap <rdunlap@infradead.org>,
"Joel Fernandes (Google)" <joel@joelfernandes.org>,
KP Singh <kpsingh@google.com>, Dave Olsthoorn <dave@bewaar.me>,
Hans de Goede <hdegoede@redhat.com>,
Peter Jones <pjones@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Stephen Boyd <stephen.boyd@linaro.org>,
Paul Moore <paul@paul-moore.com>,
Stephen Smalley <stephen.smalley.work@gmail.com>,
linux-security-module@vger.kernel.org,
linux-integrity@vger.kernel.org, selinux@vger.kernel.org,
linux-fsdevel@vger.kernel.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/13] Introduce partial kernel_read_file() support
Date: Fri, 17 Jul 2020 15:10:28 -0700 [thread overview]
Message-ID: <202007171506.CCE3902A9@keescook> (raw)
In-Reply-To: <8de85fc3-9f31-fc59-abc1-29f43fb90988@broadcom.com>
On Fri, Jul 17, 2020 at 12:17:02PM -0700, Scott Branden wrote:
> Thanks for sending out. This looks different than your other patch series.
Yes, it mutated in my head as I considered how all of this should hang
together, which is why I wanted to get it sent before the weekend. I'm
still trying to figure out why the fireware testsuite fails for me, etc.
> We should get the first 5 patches accepted now though as they are
> simple cleanups and fixes. That will reduce the number of outstanding
> patches in the series.
Agreed. I'd like to get some more eyes on it, but I can get it ready for
-next.
> At first glance the issue with the changes after that is the existing
> API assumes it has read the whole file and failed if it did not.
> Now, if the file is larger than the amount requested there is no indication?
The intention is to have old API users unchanged and new users can use
a pre-allocated buf (with buf_size) along with file_size to examine
their partial read progress. If I broke the old API, that's a bug and I
need to fix it, but that's why I wanted to start with the firmware test
suite (basic things like module loading work fine after this series, but
I wanted to really exercise the corners that the firmware suite pokes
at).
--
Kees Cook
next prev parent reply other threads:[~2020-07-17 22:10 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-17 17:42 [PATCH 00/13] Introduce partial kernel_read_file() support Kees Cook
2020-07-17 17:42 ` Kees Cook
2020-07-17 17:42 ` [PATCH 01/13] firmware_loader: EFI firmware loader must handle pre-allocated buffer Kees Cook
2020-07-17 17:42 ` Kees Cook
2020-07-17 19:08 ` Scott Branden
2020-07-17 19:08 ` Scott Branden
2020-07-17 17:42 ` [PATCH 02/13] fs/kernel_read_file: Remove FIRMWARE_PREALLOC_BUFFER enum Kees Cook
2020-07-17 17:42 ` Kees Cook
2020-07-17 19:09 ` Scott Branden
2020-07-17 19:09 ` Scott Branden
2020-07-17 17:42 ` [PATCH 03/13] fs/kernel_read_file: Remove FIRMWARE_EFI_EMBEDDED enum Kees Cook
2020-07-17 17:42 ` Kees Cook
2020-07-17 19:10 ` Scott Branden
2020-07-17 19:10 ` Scott Branden
2020-07-17 17:42 ` [PATCH 04/13] fs/kernel_read_file: Split into separate include file Kees Cook
2020-07-17 17:42 ` Kees Cook
2020-07-17 17:43 ` [PATCH 05/13] fs/kernel_read_file: Split into separate source file Kees Cook
2020-07-17 17:43 ` Kees Cook
2020-07-17 19:11 ` Scott Branden
2020-07-17 19:11 ` Scott Branden
2020-07-17 17:43 ` [PATCH 06/13] fs/kernel_read_file: Remove redundant size argument Kees Cook
2020-07-17 17:43 ` Kees Cook
2020-07-17 19:04 ` Scott Branden
2020-07-17 19:04 ` Scott Branden
2020-07-17 19:55 ` Scott Branden
2020-07-17 19:55 ` Scott Branden
2020-07-17 22:06 ` Kees Cook
2020-07-17 22:06 ` Kees Cook
2020-07-18 5:44 ` Scott Branden
2020-07-18 5:44 ` Scott Branden
2020-07-21 21:43 ` Scott Branden
2020-07-21 21:43 ` Scott Branden
2020-07-21 21:50 ` Kees Cook
2020-07-21 21:50 ` Kees Cook
2020-07-17 17:43 ` [PATCH 07/13] fs/kernel_read_file: Switch buffer size arg to size_t Kees Cook
2020-07-17 17:43 ` Kees Cook
2020-07-20 8:34 ` David Laight
2020-07-20 8:34 ` David Laight
2020-07-17 17:43 ` [PATCH 08/13] fs/kernel_read_file: Add file_size output argument Kees Cook
2020-07-17 17:43 ` Kees Cook
2020-07-17 17:43 ` [PATCH 09/13] LSM: Introduce kernel_post_load_data() hook Kees Cook
2020-07-17 17:43 ` Kees Cook
2020-07-17 17:43 ` [PATCH 10/13] firmware_loader: Use security_post_load_data() Kees Cook
2020-07-17 17:43 ` Kees Cook
2020-07-17 17:43 ` [PATCH 11/13] module: Call security_kernel_post_load_data() Kees Cook
2020-07-17 17:43 ` Kees Cook
2020-07-17 17:43 ` [PATCH 12/13] LSM: Add "contents" flag to kernel_read_file hook Kees Cook
2020-07-17 17:43 ` Kees Cook
2020-07-17 17:43 ` [PATCH 13/13] fs/kernel_file_read: Add "offset" arg for partial reads Kees Cook
2020-07-17 17:43 ` Kees Cook
2020-07-17 19:17 ` [PATCH 00/13] Introduce partial kernel_read_file() support Scott Branden
2020-07-17 19:17 ` Scott Branden
2020-07-17 22:10 ` Kees Cook [this message]
2020-07-17 22:10 ` 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=202007171506.CCE3902A9@keescook \
--to=keescook@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=casey@schaufler-ca.com \
--cc=dave@bewaar.me \
--cc=dhowells@redhat.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=ebiederm@xmission.com \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=jeyu@kernel.org \
--cc=jmorris@namei.org \
--cc=joel@joelfernandes.org \
--cc=kexec@lists.infradead.org \
--cc=kpsingh@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=matthewgarrett@google.com \
--cc=mcgrof@kernel.org \
--cc=mchehab+huawei@kernel.org \
--cc=paul@paul-moore.com \
--cc=peterz@infradead.org \
--cc=pjones@redhat.com \
--cc=rafael@kernel.org \
--cc=rdunlap@infradead.org \
--cc=scott.branden@broadcom.com \
--cc=selinux@vger.kernel.org \
--cc=serge@hallyn.com \
--cc=stephen.boyd@linaro.org \
--cc=stephen.smalley.work@gmail.com \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
--cc=zohar@linux.ibm.com \
/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.