* [kernel-hardening] Project convention on configuration options
@ 2015-12-11 17:57 Schaufler, Casey
2015-12-11 18:47 ` Kees Cook
2015-12-11 20:24 ` HacKurx
0 siblings, 2 replies; 12+ messages in thread
From: Schaufler, Casey @ 2015-12-11 17:57 UTC (permalink / raw)
To: kernel-hardening
[-- Attachment #1: Type: text/plain, Size: 251 bytes --]
I'm starting to look at PAX_USERCOPY and immediately hit
the question of what to do about configuration option name.
I assume that retaining PAX_USERCOPY is not the right thing
to do, but what should be used instead? HARD_USERCOPY?
Thanks.
[-- Attachment #2: Type: text/html, Size: 2049 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [kernel-hardening] Project convention on configuration options
2015-12-11 17:57 [kernel-hardening] Project convention on configuration options Schaufler, Casey
@ 2015-12-11 18:47 ` Kees Cook
2015-12-11 19:17 ` Daniel Micay
2015-12-11 20:24 ` HacKurx
1 sibling, 1 reply; 12+ messages in thread
From: Kees Cook @ 2015-12-11 18:47 UTC (permalink / raw)
To: kernel-hardening
On Fri, Dec 11, 2015 at 9:57 AM, Schaufler, Casey
<casey.schaufler@intel.com> wrote:
> I’m starting to look at PAX_USERCOPY and immediately hit
> the question of what to do about configuration option name.
> I assume that retaining PAX_USERCOPY is not the right thing
> to do, but what should be used instead? HARD_USERCOPY?
I think there will be plenty of bike-shedding, so pick whatever you
like for now. :)
There is already the (disabled due to gcc bugs)
DEBUG_STRICT_USER_COPY_CHECKS (which should lose the "DEBUG" name
too). IIRC, it works by tracking memory regions? Maybe TRACK_USERCOPY?
I'm sure it'll get renamed, so no big deal. In fact, you could just
leave it as PAX_USERCOPY too for the initial extraction.
-Kees
--
Kees Cook
Chrome OS & Brillo Security
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [kernel-hardening] Project convention on configuration options
2015-12-11 17:57 [kernel-hardening] Project convention on configuration options Schaufler, Casey
2015-12-11 18:47 ` Kees Cook
@ 2015-12-11 20:24 ` HacKurx
2015-12-11 21:06 ` Kees Cook
2015-12-11 21:09 ` Schaufler, Casey
1 sibling, 2 replies; 12+ messages in thread
From: HacKurx @ 2015-12-11 20:24 UTC (permalink / raw)
To: kernel-hardening
First, respect the work of others...
https://twitter.com/ioerror/status/636677916365996032
So I hope you are not here for nothing...
Sorry for such a comment here but I don't like attitude of your enterprise.
2015-12-11 18:57 GMT+01:00 Schaufler, Casey <casey.schaufler@intel.com>:
>
>
> I’m starting to look at PAX_USERCOPY and immediately hit
> the question of what to do about configuration option name.
> I assume that retaining PAX_USERCOPY is not the right thing
> to do, but what should be used instead? HARD_USERCOPY?
>
> Thanks.
>
>
--
Best regards,
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [kernel-hardening] Project convention on configuration options
2015-12-11 20:24 ` HacKurx
@ 2015-12-11 21:06 ` Kees Cook
2015-12-11 21:09 ` Schaufler, Casey
1 sibling, 0 replies; 12+ messages in thread
From: Kees Cook @ 2015-12-11 21:06 UTC (permalink / raw)
To: kernel-hardening
On Fri, Dec 11, 2015 at 12:24 PM, HacKurx <hackurx@gmail.com> wrote:
> First, respect the work of others...
> https://twitter.com/ioerror/status/636677916365996032
What? You might want to read through the archives. We, of course, give
credit. Just look at my attempts to port __read_only. PaX and
Grsecurity are credited. Emese is actively involved in getting CII
funding for upstream porting work, and PaX Team will comment now and
then too. I see no lack of respect.
> So I hope you are not here for nothing...
> Sorry for such a comment here but I don't like attitude of your enterprise.
I'm sorry you feel that way. What led you to thinking we had a bad
attitude about our efforts to bring PaX and Grsecurity features into
mainline?
-Kees
--
Kees Cook
Chrome OS & Brillo Security
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [kernel-hardening] Project convention on configuration options
2015-12-11 20:24 ` HacKurx
2015-12-11 21:06 ` Kees Cook
@ 2015-12-11 21:09 ` Schaufler, Casey
2015-12-11 21:48 ` HacKurx
1 sibling, 1 reply; 12+ messages in thread
From: Schaufler, Casey @ 2015-12-11 21:09 UTC (permalink / raw)
To: kernel-hardening
> -----Original Message-----
> From: HacKurx [mailto:hackurx@gmail.com]
> Sent: Friday, December 11, 2015 12:25 PM
> To: kernel-hardening@lists.openwall.com
> Subject: Re: [kernel-hardening] Project convention on configuration options
>
> First, respect the work of others...
> https://twitter.com/ioerror/status/636677916365996032
>
> So I hope you are not here for nothing...
> Sorry for such a comment here but I don't like attitude of your enterprise.
Noted.
So, on the topic at hand, what would you suggest? I see real
value in retaining as much of what's been proposed before as
possible.
>
> 2015-12-11 18:57 GMT+01:00 Schaufler, Casey <casey.schaufler@intel.com>:
> >
> >
> > I’m starting to look at PAX_USERCOPY and immediately hit
> > the question of what to do about configuration option name.
> > I assume that retaining PAX_USERCOPY is not the right thing
> > to do, but what should be used instead? HARD_USERCOPY?
> >
> > Thanks.
> >
> >
>
> --
> Best regards,
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [kernel-hardening] Project convention on configuration options
2015-12-11 21:09 ` Schaufler, Casey
@ 2015-12-11 21:48 ` HacKurx
2015-12-11 21:57 ` Kees Cook
2015-12-11 22:59 ` Valdis.Kletnieks
0 siblings, 2 replies; 12+ messages in thread
From: HacKurx @ 2015-12-11 21:48 UTC (permalink / raw)
To: kernel-hardening
2015-12-11 22:09 GMT+01:00 Schaufler, Casey <casey.schaufler@intel.com>:
> Noted.
>
> So, on the topic at hand, what would you suggest? I see real
> value in retaining as much of what's been proposed before as
> possible.
I don't understand why Intel and the Core Infrastructure Initiative
does not sponsor grsecurity.
Grsecurity is just as important as OpenSSL.
They need help to continue!
--
Best regards,
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [kernel-hardening] Project convention on configuration options
2015-12-11 21:48 ` HacKurx
@ 2015-12-11 21:57 ` Kees Cook
2015-12-11 22:46 ` HacKurx
2015-12-11 22:59 ` Valdis.Kletnieks
1 sibling, 1 reply; 12+ messages in thread
From: Kees Cook @ 2015-12-11 21:57 UTC (permalink / raw)
To: kernel-hardening
On Fri, Dec 11, 2015 at 1:48 PM, HacKurx <hackurx@gmail.com> wrote:
> 2015-12-11 22:09 GMT+01:00 Schaufler, Casey <casey.schaufler@intel.com>:
>> Noted.
>>
>> So, on the topic at hand, what would you suggest? I see real
>> value in retaining as much of what's been proposed before as
>> possible.
>
> I don't understand why Intel and the Core Infrastructure Initiative
> does not sponsor grsecurity.
> Grsecurity is just as important as OpenSSL.
> They need help to continue!
I can't speak for Intel or CII directly, but I'd point out that CII
*is* involved in a funding proposal from Emese, who is the author of
several of the PaX GCC plugins. If you'd like to help with some part
of bringing PaX and Grsecurity features to upstream, please discuss
what you'd like to do here and then bring another proposal to CII for
consideration.
-Kees
--
Kees Cook
Chrome OS & Brillo Security
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [kernel-hardening] Project convention on configuration options
2015-12-11 21:57 ` Kees Cook
@ 2015-12-11 22:46 ` HacKurx
0 siblings, 0 replies; 12+ messages in thread
From: HacKurx @ 2015-12-11 22:46 UTC (permalink / raw)
To: kernel-hardening
2015-12-11 22:57 GMT+01:00 Kees Cook <keescook@chromium.org>:
> I can't speak for Intel or CII directly, but I'd point out that CII
> *is* involved in a funding proposal from Emese, who is the author of
> several of the PaX GCC plugins. If you'd like to help with some part
> of bringing PaX and Grsecurity features to upstream, please discuss
> what you'd like to do here and then bring another proposal to CII for
> consideration.
That's a good point for Emese. Your work to bring PaX and Grsecurity
features into mainline is also remarkable, thanks.
I stop to bother you and I really hope I haven't offended anyone.
--
Best regards,
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [kernel-hardening] Project convention on configuration options
2015-12-11 21:48 ` HacKurx
2015-12-11 21:57 ` Kees Cook
@ 2015-12-11 22:59 ` Valdis.Kletnieks
2015-12-12 9:17 ` HacKurx
1 sibling, 1 reply; 12+ messages in thread
From: Valdis.Kletnieks @ 2015-12-11 22:59 UTC (permalink / raw)
To: kernel-hardening
[-- Attachment #1: Type: text/plain, Size: 659 bytes --]
On Fri, 11 Dec 2015 22:48:34 +0100, HacKurx said:
> I don't understand why Intel and the Core Infrastructure Initiative
> does not sponsor grsecurity.
> Grsecurity is just as important as OpenSSL.
> They need help to continue!
The problem is that there's a *lot* of stuff that's just as security-relevant
as OpenSSL, but which hasn't gotten the support it should - things like
NTP (which Eric S Raymond has been cleaning in his spare time), GnuPG, and
probably a raft of other infrastructure.
But it's not clear that it's Intel's problem to support all of it by
itself, and the CII can only do sponsorship to the level that they themselves
have funding...
[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2015-12-13 16:36 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-11 17:57 [kernel-hardening] Project convention on configuration options Schaufler, Casey
2015-12-11 18:47 ` Kees Cook
2015-12-11 19:17 ` Daniel Micay
2015-12-11 20:24 ` HacKurx
2015-12-11 21:06 ` Kees Cook
2015-12-11 21:09 ` Schaufler, Casey
2015-12-11 21:48 ` HacKurx
2015-12-11 21:57 ` Kees Cook
2015-12-11 22:46 ` HacKurx
2015-12-11 22:59 ` Valdis.Kletnieks
2015-12-12 9:17 ` HacKurx
2015-12-13 16:36 ` Kees Cook
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.