All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Tianlin Li <tli@digitalocean.com>
Cc: kernel-hardening@lists.openwall.com
Subject: Re: Introduction and get involved
Date: Thu, 26 Sep 2019 15:10:05 -0700	[thread overview]
Message-ID: <201909261505.9A58F60D@keescook> (raw)
In-Reply-To: <7D98C4BB-62FA-4393-B24A-E213FB340A94@digitalocean.com>

On Thu, Sep 26, 2019 at 09:57:58AM -0500, Tianlin Li wrote:
> > On Sep 24, 2019, at 6:12 PM, Kees Cook <keescook@chromium.org> wrote:
> > I've been keeping a (rather terse) TODO list here:
> > https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Work#Specific_TODO_Items
> > 
> > But I'd like to turn that into an actual bug list on github or the like.

I've (slowly) started this process now:
https://github.com/KSPP/linux/issues/

> > I wonder if working on something like this:
> > - set_memory_*() needs __must_check and/or atomicity
> > would be interesting?
> > 
> > The idea there is that set_memory_*() calls can fail, so callers should
> > likely be handling errors correctly. Adding the "__must_check" attribute
> > and fixing all the callers would be nice (and certainly touches the
> > memory management code!)
> 
> This is a great starting task for me. So for this task, basically I need to add __must_check attribute to set_memory_*() functions and fix all the callers to make sure they check the return values. Do I understand correctly?

Yup, that's right. I've added that issue with some more details now:
https://github.com/KSPP/linux/issues/7

> Also I have some other questions:
> Is there any requirement for the patches? e.g. based on which kernel version? how many individual patches?

I recommend basing your patches on either the last full release (v5.3
currently) or, if you need something newer, on the -rc2 of the next
release (v5.4-rc2). We are, however, in the middle of the merge window,
so -rc2 doesn't exist yet. :)

The general details on submitting patches apply:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html

Feel free to post "RFC" patches here to this list first if you want some
initial feedback. (Though I recommend still including maintainers in Cc
to get their feedback too.)

-- 
Kees Cook

      reply	other threads:[~2019-09-26 22:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-20 18:59 Introduction and get involved Tianlin Li
2019-09-24 23:12 ` Kees Cook
2019-09-26 14:57   ` Tianlin Li
2019-09-26 22:10     ` Kees Cook [this message]

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=201909261505.9A58F60D@keescook \
    --to=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=tli@digitalocean.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.