[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jJ9_mNhsZr_ozj3P_BAYcy9LHbHZeDbPMX_rBmX-9uQ-g@mail.gmail.com>
Date: Wed, 17 Apr 2019 10:29:56 -0500
From: Kees Cook <keescook@...omium.org>
To: Shyam Saini <mayhs11saini@...il.com>
Cc: Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: Re: willing to involve in KSPP
On Wed, Apr 17, 2019 at 9:22 AM Shyam Saini <mayhs11saini@...il.com> wrote:
>
>
> > On Mon, Apr 15, 2019 at 10:44 PM Shyam Saini <mayhs11saini@...il.com> wrote:
> > > As you may already know that I've submitted the patch as per your
> > > suggestion but I'm still not
> >
> > Thanks, i saw that! I'm hoping akpm will take it.
>
> Would you please acknowledge these patches ?
Other folks had questions about them -- I was assuming you would
answer those questions, etc. It sounded like people wanted to see the
series reduced to a single patch to do everything at once, so a v2
might be a good idea.
> Could you please suggest me series of more tasks so that I don't have to bother you
> each and every time for new task. :-)
Sure! Here are two:
- WARN on kfree() of ERR_PTR range
(or ignore them, as if it were NULL)
Right now kfree() only checks for NULL and zero sized allocations.
It'd be nice if it would WARN() (and skip) freeing the ERR_PTR range
(the -1 through -4095 addresses). The clever thing grsecurity did was
redefine the ZERO_SIZE allocation pointer to be -4096, and update the
ZERO_OR_NULL_PTR check[1]:
-#define ZERO_SIZE_PTR ((void *)16)
+#define ZERO_SIZE_PTR \
+({ \
+ BUILD_BUG_ON(!(MAX_ERRNO & ~PAGE_MASK));\
+ (void *)(-MAX_ERRNO-1L); \
+})
-#define ZERO_OR_NULL_PTR(x) ((unsigned long)(x) <= \
- (unsigned long)ZERO_SIZE_PTR)
+#define ZERO_OR_NULL_PTR(x) ((unsigned long)(x) - 1 >= (unsigned
long)ZERO_SIZE_PTR - 1)
So while the change is small (and be sure to give them credit[2]), it
might take some convincing various memory allocation folks that this
change makes sense. (I like it because it moves the ZERO_SIZE_PTR out
of userspace -- technically it was still in the NULL page, but better
to collect it up in unmapped memory at the top of the address space.)
This change should make a bunch of bugs around mishandling of ERR_PTRs
stand out better. People I would Cc:
Matthew Wilcox <willy@...radead.org>
Christoph Lameter <cl@...ux.com>
Another one that needs some checking is:
- audit and fix all misuse of NLA_STRING
This is a following up on noticing the misuse of NLA_STRING (no NUL
terminator), getting used with regular string functions (that expect a
NUL termination):
https://lore.kernel.org/lkml/1519329289.2637.12.camel@sipsolutions.net/T/#u
It'd be nice if someone could inspect all the NLA_STRING
representations and find if there are any other problems like this
(and see if there was a good way to systemically fix the problem).
-Kees
[1] https://github.com/linux-scraping/linux-grsecurity/blame/grsec-test/include/linux/slab.h#L127
[2] https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Get_Involved
--
Kees Cook
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.
