>
> As a _singlular_ argument, "it's for out-of-tree code" is weak. As an
> _additional_
> argument, it has value. Saying "this only helps out-of-tree code" doesn't
> carry
> much weight. Saying "this helps kernel security, even for out-of-tree code" is
> perfectly valid. And a wrinkle in this
M
> > > To: Roberts, William C
> > > Cc: kernel-harden...@lists.openwall.com; cor...@lwn.net; linux-
> > > d...@vger.kernel.org; linux-ker...@vger.kernel.org
> > > Subject: Re: [PATCH] printk: introduce kptr_restrict level 3
> > >
> > >
On Thu, Oct 6, 2016 at 2:19 PM, Joe Perches wrote:
> On Thu, 2016-10-06 at 14:00 -0700, Kees Cook wrote:
>
>> And based on my read of this thread, we all appear to be in violent
>> agreement. :) "always protect %p" is absolutely the goal, and we can
>> figure out the best way to get there.
>
> I p
On Thu, 2016-10-06 at 14:00 -0700, Kees Cook wrote:
> And based on my read of this thread, we all appear to be in violent
> agreement. :) "always protect %p" is absolutely the goal, and we can
> figure out the best way to get there.
I proposed emitting pointers from the const and text sections by
On Thu, Oct 6, 2016 at 6:56 AM, Christoph Hellwig wrote:
> On Thu, Oct 06, 2016 at 01:47:47PM +, Roberts, William C wrote:
> > On Thu, Oct 6, 2016 at 6:31 AM, Christoph Hellwig
> > wrote:
> > > So what? We a) don't care about out of tree modules and b) you could
> > > just triviall
> > > f
er...@vger.kernel.org
> Subject: Re: [PATCH] printk: introduce kptr_restrict level 3
>
> On Thu, Oct 06, 2016 at 01:47:47PM +, Roberts, William C wrote:
> > Out of tree modules still affect core kernel security.
>
> So don't use them.
>
> > I would also bet mon
M
> > > To: Roberts, William C
> > > Cc: kernel-harden...@lists.openwall.com; cor...@lwn.net; linux-
> > > d...@vger.kernel.org; linux-ker...@vger.kernel.org
> > > Subject: Re: [PATCH] printk: introduce kptr_restrict level 3
> > >
> > >
all.com; cor...@lwn.net; linux-
> > d...@vger.kernel.org; linux-ker...@vger.kernel.org
> > Subject: Re: [PATCH] printk: introduce kptr_restrict level 3
> >
> > On Wed, Oct 05, 2016 at 02:04:46PM -0400, william.c.robe...@intel.com wrote:
> > > From: William Roberts
>
On Thu, Oct 06, 2016 at 01:47:47PM +, Roberts, William C wrote:
> Out of tree modules still affect core kernel security.
So don't use them.
> I would also bet money, that somewhere
> In-tree someone has put a %p when they wanted a %pK.
So fix them.
> So this method is just quite error
> pro
; Subject: Re: [PATCH] printk: introduce kptr_restrict level 3
>
> On Wed, Oct 05, 2016 at 02:04:46PM -0400, william.c.robe...@intel.com wrote:
> > From: William Roberts
> >
> > Some out-of-tree modules do not use %pK and just use %p, as it's the
> > common C paradigm f
On Wed, Oct 05, 2016 at 02:04:46PM -0400, william.c.robe...@intel.com wrote:
> From: William Roberts
>
> Some out-of-tree modules do not use %pK and just use %p, as it's
> the common C paradigm for printing pointers. Because of this,
> kptr_restrict has no affect on the output and thus, no way to
; Nick
> Desaulniers ; Dave Weinstein
> Subject: Re: [PATCH] printk: introduce kptr_restrict level 3
>
> On Wed, Oct 5, 2016 at 11:04 AM, wrote:
> > From: William Roberts
> >
> > Some out-of-tree modules do not use %pK and just use %p, as it's the
>
.org
> Subject: Re: [PATCH] printk: introduce kptr_restrict level 3
>
> On Wed, Oct 05 2016, william.c.robe...@intel.com wrote:
>
> > From: William Roberts
> >
> > Some out-of-tree modules do not use %pK and just use %p, as it's the
> > common C paradigm for p
On Wed, Oct 05 2016, william.c.robe...@intel.com wrote:
> From: William Roberts
>
> Some out-of-tree modules do not use %pK and just use %p, as it's
> the common C paradigm for printing pointers. Because of this,
> kptr_restrict has no affect on the output and thus, no way to
> contain the kernel
On Wed, Oct 5, 2016 at 11:04 AM, wrote:
> From: William Roberts
>
> Some out-of-tree modules do not use %pK and just use %p, as it's
> the common C paradigm for printing pointers. Because of this,
> kptr_restrict has no affect on the output and thus, no way to
> contain the kernel address leak.
15 matches
Mail list logo
