subject:"ASLR"

Re: man elfctl vs. elfctl -l : man has +aslr example but elfctl -l lists onlt naslr style for ASLR control

2022-02-04 Thread Ed Maste

On Fri, 4 Feb 2022 at 20:24, Mark Millard  wrote:
>
> EXAMPLES
>  The following is an example of a typical usage of the elfctl command:
>
>elfctl file
>    elfctl -e +aslr file

Fixed in dbc7364b1840ef3f36994952d085add5d161775d

man elfctl vs. elfctl -l : man has +aslr example but elfctl -l lists onlt naslr style for ASLR control

2022-02-04 Thread Mark Millard

EXAMPLES
 The following is an example of a typical usage of the elfctl command:

   elfctl file
   elfctl -e +aslr file

vs.:

# elfctl -l
Known features are:
noaslr  Disable ASLR
noprotmax   Disable implicit PROT_MAX
nostackgap  Disable stack gap
wxneededRequires W+X mappings
la48amd64: Limit user VA to 48bit
noaslrstkgapDisable ASLR stack gap

===
Mark Millard
marklmi at yahoo.com

Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main

2021-12-10 Thread Mark Johnston

On Fri, Dec 10, 2021 at 06:35:47PM +0100, Marcin Wojtas wrote:
> Hi Daniel
> 
> 
> pt., 10 gru 2021 o 10:16 Daniel O'Connor  napisał(a):
> >
> >
> >
> > > On 17 Nov 2021, at 09:00, Marcin Wojtas  wrote:
> > > As of b014e0f15bc7 the ASLR (Address Space Layout
> > > Randomization) feature becomes enabled for the all 64-bit
> > > binaries by default.
> >
> > Firstly, thank your for your efforts here, it is appreciated :)
> >
> > I am finding that the lang/sdcc port is crashing with a seg fault and the 
> > core dump is no help to me at all:
> > [freebsd14 7:06] /usr/ports/lang/sdcc/work/sdcc-4.0.0/device/lib >sudo gdb 
> > ../../bin/sdcc sdcc.core
> > GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]
> > 
> > Reading symbols from ../../bin/sdcc...
> > [New LWP 100122]
> > Core was generated by `../../bin/sdcc -I../../device/include 
> > -I../../device/include/mcs51 -mds390 --nos'.
> > Program terminated with signal SIGSEGV, Segmentation fault.
> > Invalid permissions for mapped object.
> > #0  0x000804e3fbc0 in setrlimit () from /lib/libc.so.7
> > (gdb) info thread
> >   Id   Target Id Frame
> > * 1LWP 1001220x000804e3fbc0 in setrlimit () from 
> > /lib/libc.so.7
> > (gdb) bt
> > #0  0x000804e3fbc0 in setrlimit () from /lib/libc.so.7
> > Backtrace stopped: Cannot access memory at address 0x7f87fd08
> >
> > If I disable ASLR (via proccontrol) then it does not crash, but I am not 
> > sure how I can debug it further.
> >
> > I've raised a bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260303 
> > if you (or anyone else) has suggestions for what to try.
> >
> 
> Thanks for filing the ticket. Let's continue the conversation there.

I left a comment there.  The gist of it is that there are several
lingering problems with the stack gap implementation, and I think we
should re-disable it on main until there's some consensus on how to
proceed.

Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main

2021-12-10 Thread Marcin Wojtas

Hi Daniel


pt., 10 gru 2021 o 10:16 Daniel O'Connor  napisał(a):
>
>
>
> > On 17 Nov 2021, at 09:00, Marcin Wojtas  wrote:
> > As of b014e0f15bc7 the ASLR (Address Space Layout
> > Randomization) feature becomes enabled for the all 64-bit
> > binaries by default.
>
> Firstly, thank your for your efforts here, it is appreciated :)
>
> I am finding that the lang/sdcc port is crashing with a seg fault and the 
> core dump is no help to me at all:
> [freebsd14 7:06] /usr/ports/lang/sdcc/work/sdcc-4.0.0/device/lib >sudo gdb 
> ../../bin/sdcc sdcc.core
> GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]
> 
> Reading symbols from ../../bin/sdcc...
> [New LWP 100122]
> Core was generated by `../../bin/sdcc -I../../device/include 
> -I../../device/include/mcs51 -mds390 --nos'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> Invalid permissions for mapped object.
> #0  0x000804e3fbc0 in setrlimit () from /lib/libc.so.7
> (gdb) info thread
>   Id   Target Id Frame
> * 1LWP 1001220x000804e3fbc0 in setrlimit () from 
> /lib/libc.so.7
> (gdb) bt
> #0  0x000804e3fbc0 in setrlimit () from /lib/libc.so.7
> Backtrace stopped: Cannot access memory at address 0x7f87fd08
>
> If I disable ASLR (via proccontrol) then it does not crash, but I am not sure 
> how I can debug it further.
>
> I've raised a bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260303 if 
> you (or anyone else) has suggestions for what to try.
>

Thanks for filing the ticket. Let's continue the conversation there.

Best regards,
Marcin

Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main

2021-12-10 Thread Daniel O'Connor via freebsd-current




> On 17 Nov 2021, at 09:00, Marcin Wojtas  wrote:
> As of b014e0f15bc7 the ASLR (Address Space Layout
> Randomization) feature becomes enabled for the all 64-bit
> binaries by default.

Firstly, thank your for your efforts here, it is appreciated :)

I am finding that the lang/sdcc port is crashing with a seg fault and the core 
dump is no help to me at all:
[freebsd14 7:06] /usr/ports/lang/sdcc/work/sdcc-4.0.0/device/lib >sudo gdb 
../../bin/sdcc sdcc.core
GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]

Reading symbols from ../../bin/sdcc...
[New LWP 100122]
Core was generated by `../../bin/sdcc -I../../device/include 
-I../../device/include/mcs51 -mds390 --nos'.
Program terminated with signal SIGSEGV, Segmentation fault.
Invalid permissions for mapped object.
#0  0x000804e3fbc0 in setrlimit () from /lib/libc.so.7
(gdb) info thread
  Id   Target Id Frame
* 1LWP 1001220x000804e3fbc0 in setrlimit () from /lib/libc.so.7
(gdb) bt
#0  0x000804e3fbc0 in setrlimit () from /lib/libc.so.7
Backtrace stopped: Cannot access memory at address 0x7f87fd08

If I disable ASLR (via proccontrol) then it does not crash, but I am not sure 
how I can debug it further.

I've raised a bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260303 if 
you (or anyone else) has suggestions for what to try.

Thanks.

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum

Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main

2021-11-21 Thread Ed Maste

On Sat, 20 Nov 2021 at 20:00, Ed Maste  wrote:
>
> On Thu, 18 Nov 2021 at 13:09, Li-Wen Hsu  wrote:
> >
> > The mkimg ones are a bit tricky, it seems the output is changed in
> > each run. We may need a way to generate reproducible results..
>
> Hopefully fixed by 036af1053acd6cae68c5fb6bed30508f2e40be13.

The mkimg failures are indeed fixed by the above commit - it was just
a latent bug in mkimg.

I've opened PR 259968 as a tracking bug for outstanding issues found
as a result of enabling ASLR by default, and submitted a PR for each
of the three outstanding issues.

Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main

2021-11-20 Thread Ed Maste

On Thu, 18 Nov 2021 at 13:09, Li-Wen Hsu  wrote:
>
> The mkimg ones are a bit tricky, it seems the output is changed in
> each run. We may need a way to generate reproducible results..

Hopefully fixed by 036af1053acd6cae68c5fb6bed30508f2e40be13.

Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main

2021-11-19 Thread Kristof Provost



> On 18 Nov 2021, at 11:43, Marcin Wojtas  wrote:
> czw., 18 lis 2021 o 19:07 Li-Wen Hsu  napisał(a):
>> 
>>> On Wed, Nov 17, 2021 at 6:30 AM Marcin Wojtas  wrote:
>>> 
>>> As of b014e0f15bc7 the ASLR (Address Space Layout
>>> Randomization) feature becomes enabled for the all 64-bit
>>> binaries by default.
>>> 
>>> Address Space Layout Randomization (ASLR) is an exploit mitigation
>>> technique implemented in the majority of modern operating systems.
>>> It involves randomly positioning the base address of an executable
>>> and the position of libraries, heap, and stack, in a process's address
>>> space. Although over the years ASLR proved to not guarantee full OS
>>> security on its own, this mechanism can make exploitation more difficult
>>> (especially when combined with other methods, such as W^X).
>>> 
>>> Tests on the tier 1 64-bit architectures demonstrated that the ASLR is
>>> stable and does not result in noticeable performance degradation,
>>> therefore it is considered safe to enable this mechanism by default.
>>> Moreover its effectiveness is increased for PIE (Position Independent
>>> Executable) binaries. Thanks to commit 9a227a2fd642 ("Enable PIE by
>>> default on 64-bit architectures"), building from src is not necessary
>>> to have PIE binaries and it is enough to control usage of ASLR in the
>>> OS solely by setting the appropriate sysctls. The defaults were toggled
>>> for the 64-bit PIE and non-PIE executables.
>>> 
>>> As for the drawbacks, a consequence of using the ASLR is more
>>> significant VM fragmentation, hence the issues may be encountered
>>> in the systems with a limited address space in high memory consumption
>>> cases, such as buildworld. As a result, although the tests on 32-bit
>>> architectures with ASLR enabled were mostly on par with what was
>>> observed on 64-bit ones, the defaults for the former are not changed
>>> at this time. Also, for the sake of safety the feature remains disabled
>>> for 32-bit executables on 64-bit machines, too.
>>> 
>>> The committed change affects the overall OS operation, so the
>>> following should be taken into consideration:
>>> * Address space fragmentation.
>>> * A changed ABI due to modified layout of address space.
>>> * More complicated debugging due to:
>>>  * Non-reproducible address space layout between runs.
>>>  * Some debuggers automatically disable ASLR for spawned processes,
>>>making target's environment different between debug and
>>>non-debug runs.
>>> 
>>> The known issues (such as PR239873 or PR253208) have been fixed in
>>> HEAD up front, however please pay attention to the system behavior after
>>> upgrading the kernel to the newest revisions.
>>> In order to confirm/rule-out the dependency of any encountered issue
>>> on ASLR it is strongly advised to re-run the test with the feature
>>> disabled - it can be done by setting the following sysctls
>>> in the /etc/sysctl.conf file:
>>> kern.elf64.aslr.enable=0
>>> kern.elf64.aslr.pie_enable=0
>>> 
>>> The change is a result of combined efforts under the auspices
>>> of the FreeBSD Foundation and the Semihalf team sponsored
>>> by Stormshield.
>>> 
>>> Best regards,
>>> Marcin
>> 
>> Thanks very much for working on this. FYI, there are some test cases
>> seem to be affected by this:
>> 
>> https://ci.freebsd.org/job/FreeBSD-main-amd64-test/19828/testReport/
>> 
>> The mkimg ones are a bit tricky, it seems the output is changed in
>> each run. We may need a way to generate reproducible results..
>> 
>> I'm still checking them, but hope more people can join and fix them.
>> 
> 
> Thanks for bringing this up! Apart from
> sys.netpfil.common.dummynet.pf_nat other are 23 are new.

I’ve just managed to reproduce that one locally (it only happens if ipfw is 
also loaded) and will dig in soon. It’s not going to be aslr related. You can 
ignore that failure. 

Kristof

Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main

2021-11-18 Thread Marcin Wojtas

Hi,

czw., 18 lis 2021 o 19:07 Li-Wen Hsu  napisał(a):
>
> On Wed, Nov 17, 2021 at 6:30 AM Marcin Wojtas  wrote:
> >
> > As of b014e0f15bc7 the ASLR (Address Space Layout
> > Randomization) feature becomes enabled for the all 64-bit
> > binaries by default.
> >
> > Address Space Layout Randomization (ASLR) is an exploit mitigation
> > technique implemented in the majority of modern operating systems.
> > It involves randomly positioning the base address of an executable
> > and the position of libraries, heap, and stack, in a process's address
> > space. Although over the years ASLR proved to not guarantee full OS
> > security on its own, this mechanism can make exploitation more difficult
> > (especially when combined with other methods, such as W^X).
> >
> > Tests on the tier 1 64-bit architectures demonstrated that the ASLR is
> > stable and does not result in noticeable performance degradation,
> > therefore it is considered safe to enable this mechanism by default.
> > Moreover its effectiveness is increased for PIE (Position Independent
> > Executable) binaries. Thanks to commit 9a227a2fd642 ("Enable PIE by
> > default on 64-bit architectures"), building from src is not necessary
> > to have PIE binaries and it is enough to control usage of ASLR in the
> > OS solely by setting the appropriate sysctls. The defaults were toggled
> > for the 64-bit PIE and non-PIE executables.
> >
> > As for the drawbacks, a consequence of using the ASLR is more
> > significant VM fragmentation, hence the issues may be encountered
> > in the systems with a limited address space in high memory consumption
> > cases, such as buildworld. As a result, although the tests on 32-bit
> > architectures with ASLR enabled were mostly on par with what was
> > observed on 64-bit ones, the defaults for the former are not changed
> > at this time. Also, for the sake of safety the feature remains disabled
> > for 32-bit executables on 64-bit machines, too.
> >
> > The committed change affects the overall OS operation, so the
> > following should be taken into consideration:
> > * Address space fragmentation.
> > * A changed ABI due to modified layout of address space.
> > * More complicated debugging due to:
> >   * Non-reproducible address space layout between runs.
> >   * Some debuggers automatically disable ASLR for spawned processes,
> > making target's environment different between debug and
> > non-debug runs.
> >
> > The known issues (such as PR239873 or PR253208) have been fixed in
> > HEAD up front, however please pay attention to the system behavior after
> > upgrading the kernel to the newest revisions.
> > In order to confirm/rule-out the dependency of any encountered issue
> > on ASLR it is strongly advised to re-run the test with the feature
> > disabled - it can be done by setting the following sysctls
> > in the /etc/sysctl.conf file:
> > kern.elf64.aslr.enable=0
> > kern.elf64.aslr.pie_enable=0
> >
> > The change is a result of combined efforts under the auspices
> > of the FreeBSD Foundation and the Semihalf team sponsored
> > by Stormshield.
> >
> > Best regards,
> > Marcin
>
> Thanks very much for working on this. FYI, there are some test cases
> seem to be affected by this:
>
> https://ci.freebsd.org/job/FreeBSD-main-amd64-test/19828/testReport/
>
> The mkimg ones are a bit tricky, it seems the output is changed in
> each run. We may need a way to generate reproducible results..
>
> I'm still checking them, but hope more people can join and fix them.
>

Thanks for bringing this up! Apart from
sys.netpfil.common.dummynet.pf_nat other are 23 are new. I checked a
couple of next builds and the results seems to be consistent. There
are:

lib.libc.sys.setrlimit_test.setrlimit_stack
lib.libc.regex.exhaust_test.regcomp_too_big
sys.kern.coredump_phnum_test.coredump_phnum
and 20 of usr.bin.mkimg.*

We will also check and try to fix the new issues (however any help
would be appreciated), it may be also worth to create dedicated
tickets in bugzilla.

Best regards,
Marcin

Re: HEADS-UP: ASLR for 64-bit executables enabled by default on main

2021-11-18 Thread Li-Wen Hsu

On Wed, Nov 17, 2021 at 6:30 AM Marcin Wojtas  wrote:
>
> As of b014e0f15bc7 the ASLR (Address Space Layout
> Randomization) feature becomes enabled for the all 64-bit
> binaries by default.
>
> Address Space Layout Randomization (ASLR) is an exploit mitigation
> technique implemented in the majority of modern operating systems.
> It involves randomly positioning the base address of an executable
> and the position of libraries, heap, and stack, in a process's address
> space. Although over the years ASLR proved to not guarantee full OS
> security on its own, this mechanism can make exploitation more difficult
> (especially when combined with other methods, such as W^X).
>
> Tests on the tier 1 64-bit architectures demonstrated that the ASLR is
> stable and does not result in noticeable performance degradation,
> therefore it is considered safe to enable this mechanism by default.
> Moreover its effectiveness is increased for PIE (Position Independent
> Executable) binaries. Thanks to commit 9a227a2fd642 ("Enable PIE by
> default on 64-bit architectures"), building from src is not necessary
> to have PIE binaries and it is enough to control usage of ASLR in the
> OS solely by setting the appropriate sysctls. The defaults were toggled
> for the 64-bit PIE and non-PIE executables.
>
> As for the drawbacks, a consequence of using the ASLR is more
> significant VM fragmentation, hence the issues may be encountered
> in the systems with a limited address space in high memory consumption
> cases, such as buildworld. As a result, although the tests on 32-bit
> architectures with ASLR enabled were mostly on par with what was
> observed on 64-bit ones, the defaults for the former are not changed
> at this time. Also, for the sake of safety the feature remains disabled
> for 32-bit executables on 64-bit machines, too.
>
> The committed change affects the overall OS operation, so the
> following should be taken into consideration:
> * Address space fragmentation.
> * A changed ABI due to modified layout of address space.
> * More complicated debugging due to:
>   * Non-reproducible address space layout between runs.
>   * Some debuggers automatically disable ASLR for spawned processes,
> making target's environment different between debug and
> non-debug runs.
>
> The known issues (such as PR239873 or PR253208) have been fixed in
> HEAD up front, however please pay attention to the system behavior after
> upgrading the kernel to the newest revisions.
> In order to confirm/rule-out the dependency of any encountered issue
> on ASLR it is strongly advised to re-run the test with the feature
> disabled - it can be done by setting the following sysctls
> in the /etc/sysctl.conf file:
> kern.elf64.aslr.enable=0
> kern.elf64.aslr.pie_enable=0
>
> The change is a result of combined efforts under the auspices
> of the FreeBSD Foundation and the Semihalf team sponsored
> by Stormshield.
>
> Best regards,
> Marcin

Thanks very much for working on this. FYI, there are some test cases
seem to be affected by this:

https://ci.freebsd.org/job/FreeBSD-main-amd64-test/19828/testReport/

The mkimg ones are a bit tricky, it seems the output is changed in
each run. We may need a way to generate reproducible results..

I'm still checking them, but hope more people can join and fix them.

Best,
Li-Wen

HEADS-UP: ASLR for 64-bit executables enabled by default on main

2021-11-16 Thread Marcin Wojtas

As of b014e0f15bc7 the ASLR (Address Space Layout
Randomization) feature becomes enabled for the all 64-bit
binaries by default.

Address Space Layout Randomization (ASLR) is an exploit mitigation
technique implemented in the majority of modern operating systems.
It involves randomly positioning the base address of an executable
and the position of libraries, heap, and stack, in a process's address
space. Although over the years ASLR proved to not guarantee full OS
security on its own, this mechanism can make exploitation more difficult
(especially when combined with other methods, such as W^X).

Tests on the tier 1 64-bit architectures demonstrated that the ASLR is
stable and does not result in noticeable performance degradation,
therefore it is considered safe to enable this mechanism by default.
Moreover its effectiveness is increased for PIE (Position Independent
Executable) binaries. Thanks to commit 9a227a2fd642 ("Enable PIE by
default on 64-bit architectures"), building from src is not necessary
to have PIE binaries and it is enough to control usage of ASLR in the
OS solely by setting the appropriate sysctls. The defaults were toggled
for the 64-bit PIE and non-PIE executables.

As for the drawbacks, a consequence of using the ASLR is more
significant VM fragmentation, hence the issues may be encountered
in the systems with a limited address space in high memory consumption
cases, such as buildworld. As a result, although the tests on 32-bit
architectures with ASLR enabled were mostly on par with what was
observed on 64-bit ones, the defaults for the former are not changed
at this time. Also, for the sake of safety the feature remains disabled
for 32-bit executables on 64-bit machines, too.

The committed change affects the overall OS operation, so the
following should be taken into consideration:
* Address space fragmentation.
* A changed ABI due to modified layout of address space.
* More complicated debugging due to:
  * Non-reproducible address space layout between runs.
  * Some debuggers automatically disable ASLR for spawned processes,
making target's environment different between debug and
non-debug runs.

The known issues (such as PR239873 or PR253208) have been fixed in
HEAD up front, however please pay attention to the system behavior after
upgrading the kernel to the newest revisions.
In order to confirm/rule-out the dependency of any encountered issue
on ASLR it is strongly advised to re-run the test with the feature
disabled - it can be done by setting the following sysctls
in the /etc/sysctl.conf file:
kern.elf64.aslr.enable=0
kern.elf64.aslr.pie_enable=0

The change is a result of combined efforts under the auspices
of the FreeBSD Foundation and the Semihalf team sponsored
by Stormshield.

Best regards,
Marcin

Re: r350484 and ASLR enabled - init died (signal 6, exit 0)

2019-08-08 Thread Konstantin Belousov

On Thu, Aug 08, 2019 at 09:35:23AM +0300, Vladimir Zakharov wrote:
> On Mon, Aug 05, 2019, Konstantin Belousov wrote:
> > On Mon, Aug 05, 2019 at 08:10:43PM +0200, Trond Endrestøl wrote:
> > > On Mon, 5 Aug 2019 06:02-0700, David Wolfskill wrote:
> > > 
> > > > On Mon, Aug 05, 2019 at 02:53:04PM +0200, Trond Endrestøl wrote:
> > > > > Hi,
> > > > > 
> > > > > Has anyone else noticed the kernel being unable to spawn init lately?
> > > > > 
> > > > > All I get is:
> > > > > 
> > > > > init died (signal 6, exit 0)
> > > > > panic: Going nowhere without my init!
> > > > > 
> > Try r350608. There was a mis-merge in the committed patch (more serious
> > part), and some limits were not applied, which I did not see in my
> > testing due to the mismatch between stock FreeBSD and my testing
> > environment.
> 
> The issue persists still at r350713 on HP Probook after clean rebuild.
> 
> root@# uname -a
> FreeBSD vzakharov 13.0-CURRENT FreeBSD 13.0-CURRENT r350713 GENERIC-NODEBUG  
> amd64
> 
> root@# grep aslr /boot/loader.conf
> #kern.elf32.aslr.enable=1
> #kern.elf64.aslr.enable=1

I was able to reproduce it, try r350758.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r350484 and ASLR enabled - init died (signal 6, exit 0)

2019-08-08 Thread Vladimir Zakharov

On Mon, Aug 05, 2019, Konstantin Belousov wrote:
> On Mon, Aug 05, 2019 at 08:10:43PM +0200, Trond Endrestøl wrote:
> > On Mon, 5 Aug 2019 06:02-0700, David Wolfskill wrote:
> > 
> > > On Mon, Aug 05, 2019 at 02:53:04PM +0200, Trond Endrestøl wrote:
> > > > Hi,
> > > > 
> > > > Has anyone else noticed the kernel being unable to spawn init lately?
> > > > 
> > > > All I get is:
> > > > 
> > > > init died (signal 6, exit 0)
> > > > panic: Going nowhere without my init!
> > > > 
> Try r350608. There was a mis-merge in the committed patch (more serious
> part), and some limits were not applied, which I did not see in my
> testing due to the mismatch between stock FreeBSD and my testing
> environment.

The issue persists still at r350713 on HP Probook after clean rebuild.

root@# uname -a
FreeBSD vzakharov 13.0-CURRENT FreeBSD 13.0-CURRENT r350713 GENERIC-NODEBUG  
amd64

root@# grep aslr /boot/loader.conf
#kern.elf32.aslr.enable=1
#kern.elf64.aslr.enable=1

-- 
Regards, | "In theory there is no difference between theory
  Vladimir Zakharov  | and practice. In practice there is."- Yogi Berra


signature.asc
Description: PGP signature

Re: r350484 and ASLR enabled - init died (signal 6, exit 0)

2019-08-06 Thread Trond Endrestøl

On Mon, 5 Aug 2019 22:32+0200, Trond Endrestøl wrote:

> On Mon, 5 Aug 2019 22:23+0300, Konstantin Belousov wrote:
> 
> > On Mon, Aug 05, 2019 at 08:10:43PM +0200, Trond Endrestøl wrote:
> > 
> > > I'm going home and see if VBox 6.0.10 exhibits the same behaviour.
> > 
> > Try r350608. There was a mis-merge in the committed patch (more serious
> > part), and some limits were not applied, which I did not see in my
> > testing due to the mismatch between stock FreeBSD and my testing
> > environment.
> 
> I'm now at r350609, and booting with ASLR enabled works in VBox.
> I'll try the Citrix Hypervisor VM tomorrow

Back at $WORK, I noticed a repeat of the initial issue which persisted 
until I forcefully shutdown this longrunning VM, now running r350624. 
Upon cold start, the VM behaved as expected, making me think there 
might be one or more uninitialised variables at play or some odd 
behaviour by the hypervisors I use.

-- 
Trond.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r350484 and ASLR enabled - init died (signal 6, exit 0)

2019-08-05 Thread Trond Endrestøl

On Mon, 5 Aug 2019 22:23+0300, Konstantin Belousov wrote:

> On Mon, Aug 05, 2019 at 08:10:43PM +0200, Trond Endrestøl wrote:
> 
> > I'm going home and see if VBox 6.0.10 exhibits the same behaviour.
> 
> Try r350608. There was a mis-merge in the committed patch (more serious
> part), and some limits were not applied, which I did not see in my
> testing due to the mismatch between stock FreeBSD and my testing
> environment.

I'm now at r350609, and booting with ASLR enabled works in VBox.
I'll try the Citrix Hypervisor VM tomorrow

Thank you, Konstantin.

-- 
Trond.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r350484 and ASLR enabled - init died (signal 6, exit 0)

2019-08-05 Thread Konstantin Belousov

On Mon, Aug 05, 2019 at 08:10:43PM +0200, Trond Endrestøl wrote:
> On Mon, 5 Aug 2019 06:02-0700, David Wolfskill wrote:
> 
> > On Mon, Aug 05, 2019 at 02:53:04PM +0200, Trond Endrestøl wrote:
> > > Hi,
> > > 
> > > Has anyone else noticed the kernel being unable to spawn init lately?
> > > 
> > > All I get is:
> > > 
> > > init died (signal 6, exit 0)
> > > panic: Going nowhere without my init!
> > > 
> > > /sbin/init hasn't had any changes in 4 months, and is present in /sbin 
> > > in the new BE.
> > > 
> > > I've tried and failed in VBox at home this weekend, and in Citrix 
> > > Hypervisor 8 at $WORK today. I think we can rule out the hypervisors.
> > > 
> > > Last known working revision is r350400.
> > > 
> > > There are numerous kernel changes between r350400 and r350583. I'll 
> > > try each revision in succession and see if I can identify any 
> > > culprits.
> > > ...
> > 
> > I have not seen the behavior in question; my last update was from
> > r350566 to r350584 (and was quite uneventful).
> > 
> > In each case, a "real machine" was used (laptop & a build machine).
> 
> After more trial and error, r350484 is the culprit for Citrix 
> Hypervisor 8.
> 
> I have these lines in /boot/loader.conf:
> 
> kern.elf32.aslr.enable="1"
> kern.elf32.aslr.pie_enable="1"
> 
> kern.elf64.aslr.enable="1"
> kern.elf64.aslr.pie_enable="1"
> 
> r350483 works like a charm, and so does r350484 iff I disable ASLR.
> 
> Reenabling ASLR and setting kern.elf{64,32}.aslr.stack_gap to zero has 
> no effect.
> 
> I've cc'd kib@ on this one.
> 
> I'm going home and see if VBox 6.0.10 exhibits the same behaviour.

Try r350608. There was a mis-merge in the committed patch (more serious
part), and some limits were not applied, which I did not see in my
testing due to the mismatch between stock FreeBSD and my testing
environment.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r350484 and ASLR enabled - init died (signal 6, exit 0)

2019-08-05 Thread Trond Endrestøl

On Mon, 5 Aug 2019 06:02-0700, David Wolfskill wrote:

> On Mon, Aug 05, 2019 at 02:53:04PM +0200, Trond Endrestøl wrote:
> > Hi,
> > 
> > Has anyone else noticed the kernel being unable to spawn init lately?
> > 
> > All I get is:
> > 
> > init died (signal 6, exit 0)
> > panic: Going nowhere without my init!
> > 
> > /sbin/init hasn't had any changes in 4 months, and is present in /sbin 
> > in the new BE.
> > 
> > I've tried and failed in VBox at home this weekend, and in Citrix 
> > Hypervisor 8 at $WORK today. I think we can rule out the hypervisors.
> > 
> > Last known working revision is r350400.
> > 
> > There are numerous kernel changes between r350400 and r350583. I'll 
> > try each revision in succession and see if I can identify any 
> > culprits.
> > ...
> 
> I have not seen the behavior in question; my last update was from
> r350566 to r350584 (and was quite uneventful).
> 
> In each case, a "real machine" was used (laptop & a build machine).

After more trial and error, r350484 is the culprit for Citrix 
Hypervisor 8.

I have these lines in /boot/loader.conf:

kern.elf32.aslr.enable="1"
kern.elf32.aslr.pie_enable="1"

kern.elf64.aslr.enable="1"
kern.elf64.aslr.pie_enable="1"

r350483 works like a charm, and so does r350484 iff I disable ASLR.

Reenabling ASLR and setting kern.elf{64,32}.aslr.stack_gap to zero has 
no effect.

I've cc'd kib@ on this one.

I'm going home and see if VBox 6.0.10 exhibits the same behaviour.

-- 
Trond.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ASLR

2017-01-24 Thread Domagoj Stolfa

Hello,

> For better or worse the term ASLR is today in common use to refer to a
> number of different approaches. Using what has become a generic term
> allows the implementation to change in the future, without changing
> the interface (e.g. sysctls, userland tools, etc.).

If I'm not mistaken, ASR is the approach that was first taken by the PaX team in
an attempt to randomize mmaps. It later evolved into ASLR, however I do agree
that one should call this ASLR for compatibility reasons in the future.

> I wish there was a concise, technical comparison of the approaches
> implemented by different operating systems, but I've unfortunately not
> found one.

FWIW, ASLR is just a workaround and has it's weaknesses[1], but is a workaround
I would like to see implemented in FreeBSD, be it ASLR or ASR, until a proper
solution comes along.

[1] 
https://www.blackhat.com/docs/asia-16/materials/asia-16-Marco-Gisbert-Exploiting-Linux-And-PaX-ASLRS-Weaknesses-On-32-And-64-Bit-Systems-wp.pdf

-- 
Best regards,
Domagoj Stolfa


signature.asc
Description: PGP signature

Re: ASLR

2017-01-24 Thread Ed Maste

On 18 January 2017 at 17:56, Piotr Kubaj <pku...@anongoth.pl> wrote:
> It should also be stated properly that this patch doesn't implement ASLR, but 
> ASR.

For better or worse the term ASLR is today in common use to refer to a
number of different approaches. Using what has become a generic term
allows the implementation to change in the future, without changing
the interface (e.g. sysctls, userland tools, etc.).

I wish there was a concise, technical comparison of the approaches
implemented by different operating systems, but I've unfortunately not
found one.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ASLR

2017-01-18 Thread Piotr Kubaj

It should also be stated properly that this patch doesn't implement ASLR, but 
ASR.


signature.asc
Description: PGP signature

Re: ASLR

2017-01-18 Thread Conrad Meyer

On Wed, Jan 18, 2017 at 9:53 AM, Johannes Lundberg <johal...@gmail.com> wrote:
> Hi
>
> What is the status of ASLR?
>
> https://reviews.freebsd.org/D5603
>
> The thread has been silent for a couple of months. I'm happy to test if
> needed.

Hi Johannes,

I think we were waiting on some review, but if that has stalled out,
let's go ahead and commit it.  Default off is fine for now.  It can be
improved as needed and then we at least have an ASLR story for the
checkbox users.

> I'm also interested in KASLR. Is that also on the roadmap? If someone
> involved could share some info I'd be grateful.

KASLR is less useful (grsecurity folks might say useless) — see
https://forums.grsecurity.net/viewtopic.php?f=7=3367 for some
discussion on it.

Best,
Conrad
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

ASLR

2017-01-18 Thread Johannes Lundberg

Hi

What is the status of ASLR?

https://reviews.freebsd.org/D5603

The thread has been silent for a couple of months. I'm happy to test if
needed.


I'm also interested in KASLR. Is that also on the roadmap? If someone
involved could share some info I'd be grateful.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[CFT] FreeBSD ASLR Patch

2015-04-16 Thread Shawn Webb

Hey All,

I just updated the ASLR patch to FreeBSD (link below). If anyone is interested 
in testing the patch out, please give it a whirl. It has been a while since we 
last did a call for testing, so there's a lot of changes (too many to really 
list). We've vastly improved performance and stability and have resolved the 
vast majority of the concerns the FreeBSD team has had.

If you're at all interested in security and/or exploit mitigation techniques, 
I ask for your assistance in testing the patch. I want to thank all those who 
have tested in the past and have given us helpful suggestions on how to 
improve our hard work.

The patch is on Phabricator: https://reviews.freebsd.org/D473

Thanks,

-- 
Shawn Webb
HardenedBSD

GPG Key ID:0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE

signature.asc
Description: This is a digitally signed message part.

CFT: New ASLR Patch

2015-02-21 Thread Shawn Webb

Hey All,

It has been a long time since we sent out a call for testing request for our 
ASLR patch. We've been hard at work making our ASLR implementation as robust 
as possible. We'd like to invite all adventurous souls to test our ASLR 
implementation. Put it through the ringer.

Since the patch is much too large to attach to an email, you can find our 
latest patch on FreeBSD's Phabricator:

https://reviews.freebsd.org/D473

Or download the raw version of the patch:
https://reviews.freebsd.org/D473?download=true

Please let me know if you find any issues.

Thanks,

Shawn Webb
HardenedBSD

signature.asc
Description: This is a digitally signed message part.

New ASLR Patch

2014-09-05 Thread Shawn Webb

Hey All,

I've submitted a new revision of our ASLR patch to Phabric. It can be
applied to 11-CURRENT. The main changes include removal of the MAP_32BIT
hack for amd64, a couple bug fixes, and stylistic changes requested by a
few people. I'm looking for commentary and volunteers for testing. The link
to Phabric is below and you can download the raw patch from there.

https://reviews.freebsd.org/D473

Thanks,

Shawn
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-30 Thread Wojciech A. Koszek

On Fri, May 23, 2014 at 08:35:25PM -0400, Shawn Webb wrote:
On May 23, 2014 07:53 PM +, Wojciech A. Koszek wrote:
On Wed, May 14, 2014 at 09:58:52AM -0400, Shawn Webb wrote:
Hey All,

[NOTE: crossposting between freebsd-current@, freebsd-security@, and
freebsd-stable@. Please forgive me if crossposting is frowned upon.]

Address Space Layout Randomization, or ASLR for short, is an exploit
mitigation technology. It helps secure applications against low-level
exploits. A popular secure implementation is known as PaX ASLR, which is
a third-party patch for Linux. Our implementation is based off of PaX's.

Oliver Pinter, Danilo Egea, and I have been working hard to bring more
features and robust stability to our ASLR patches. We've done extensive
testing on amd64. We'd like to get as many people testing these patches.
Given the nature of them, we'd also like as many eyeballs reviewing the
code as well.

I have a Raspberry Pi and have noticed a few bugs. On ARM (at least, on
the RPI), when a parent forks a child, and the child gracefully exits,
the parent segfaults with the pc register pointing to 0xc000. That
address is always the same, no matter the application. If anyone knows
the ARM architecture well, and how FreeBSD ties into it, I'd like a
little guidance.

I also have a sparc64 box, but I'm having trouble getting a vanilla
11-current system to be stable on it. I ought to file a few PRs.

You can find links to the patches below.

Patch for 11-current:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff

Patch for 10-stable:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff

Shawn

I appreciate you working on this. We must have this in FreeBSD.

I looked at the patch and I read, but not run it. Comments below.

My personal opinion is that kern_pax.c should be compiled in by default. If
it adds a lot of size, it'd be better to provide empty stub calls instead of
#ifdef'ing everything. But security is very important especially in
embeddded systems, so you can imagine you're writing the code that everybody
wants and must have enabled for decent level of security.

All modern systems run with ASLR turned on.

I skipped user-space stuff. I don't think it's necessary in this commit and
should be separated.

There's a lot of lines of code for status showing. Not sure if we care that
much: ASLR is either on or off. Not sure about more granularity. More below.

We provide the level of granularity because there are a lot of
applications that might exhibit weird behaviors or even crash if we
randomize too many bits. We provide sane defaults, but allow each user
to choose the level of security versus the level of stability they
desire.

I'm OK with it being more granular if that's the case. But Linux/MacOSX all
have ASLR. If we have programs in ports/ that run on Linux, it's likely
they'll just work. If they break, we'll just marked them as broken and to be
fixed by the maintainer.

Can you run GNOME or KDE with your patch? Or node.js? Node.js uses JIT
engine for Javascript. If it works, it's quite likely other will work.

kern_jail.c:

something looks wrong here. Sounds like you need pr-pax. But I don't
understand why you need to have these pr_* values here. It seems
unnecessary.

I've made it possible to have per-jail ASLR settings. If you have an
application that misbehaves, you can jail it with ASLR turned off just
for that jail. My BSDCan presentation talks about this. The recording
isn't up, yet, though.

I don't get it. If there's a program that is broken but you want to run it
in jail, our rc.d jail startup script should earn a NOPIE function maybe.
I believed PIE/NOPIE is per-process setting on whether to use PIE or not. In
this case we'd be able to do:

/usr/sbin/jail .. /usr/sbin/nopax program ...

In Linux you can do it with personalities. I don't know what it would
translate in the FreeBSD to. I guess this could be achieved with simple
per-process SYSCTL. nopax would disable ASLR, fork and exec().

I can imagine we won't want ASLR only temporarily, for ports which break and
must be fixed. So we probably just need per-process ASLR on/off switch and a
wrapper which could be used like:

aslr off program

So we have right now an addition to mac_bsdextended(4)/ugidfw(8) that
does this exact thing. We also plan on adding FS extended attribute
support soon, too. Also, per-jail ASLR settings.

If you can already do it with MAC layer, it should be enough. Touching
jail(8) will require lots of people to review this patch and analyze it in a
great details, which typically slows things down a lot.

The debug stuff I'd remove too. We could have additional CTR stubs used
there, if necessary.

Oliver

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-25 Thread Dag-Erling Smørgrav

Oliver Pinter oliver.p...@gmail.com writes:
 Two idea here:
 a) create a tunable security.pax.expert_mode, and create sysctls at
 boot time depending from expert mode
 b) just add CTLFLAG_SKIP and hide the sysctl from normal user

The cost of an unused sysctl is about a hundred bytes of kernel memory.
What is the cost of the code required to turn it on and off, keeping in
mind that most of the contents of the struct sysctl_oid must be present
anyway so you can fill in the malloc()ed node?

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-25 Thread Dag-Erling Smørgrav

Oliver Pinter oliver.p...@gmail.com writes:
   PAX LOG: implement new logging subsystem
   PAX LOG: fix pax_ulog_segvguard
   PAX LOG: added sysctl's and tunables
   PAX ASLR: use PAX LOG
   PAX LOG: fix pax_ulog_##name()
   PAX LOG: fix prison init
   PAX LOG: fixed log and ulog sysctl

What exactly is the purpose of PAX LOG?  Have you considered using
ktrace instead?

   PAX: blacklist clang and related binaries from PIE support

Why?  Performance, or do they actually break?

   PAX ASLR: Blacklist the applications that don't support being built as 
 a position-independent executable

don't support as in you have tested them and confirmed that they break
in some way?  Could you post your test methodology so people can
replicate the failures and look into fixing them?

   PAX ASLR: Use a full kernel config for LATT-ASLR

What is the difference between LATT-ASLR and OP-ASLR, and why not just
include GENERIC?  You know about nooptions, right?

   Revert PAX: blacklist clang and related binaries from PIE support
   Revert Revert PAX: blacklist clang and related binaries from PIE 
 support

Hmm...

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-25 Thread Oliver Pinter

On 5/25/14, Dag-Erling Smørgrav d...@des.no wrote:
 Oliver Pinter oliver.p...@gmail.com writes:
   PAX LOG: implement new logging subsystem
   PAX LOG: fix pax_ulog_segvguard
   PAX LOG: added sysctl's and tunables
   PAX ASLR: use PAX LOG
   PAX LOG: fix pax_ulog_##name()
   PAX LOG: fix prison init
   PAX LOG: fixed log and ulog sysctl

 What exactly is the purpose of PAX LOG?  Have you considered using
 ktrace instead?

pax_log will be in future a generic pax related logging framework,
with ratelimiting and other features.
It will log user, IP, binary name, path, checksum, and others.


   PAX: blacklist clang and related binaries from PIE support

 Why?  Performance, or do they actually break?

No. If you definded WITH_CLANG_EXTRAS= in src.conf, the breaked the build.
(added dim@ to CC)

--- usr.bin.all__D ---
/usr/obj/usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/bugpoint/../../../lib/clang/libllvmirreader/libllvmirreader.a:
could not read symbols: Bad value
c++: error: linker command failed with exit code 1 (use -v to see invocation)
*** [bugpoint] Error code 1

bmake[5]: stopped in
/usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/bugpoint
1 error

bmake[5]: stopped in
/usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/bugpoint
*** [all_subdir_bugpoint] Error code 2

bmake[4]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang
--- usr.sbin.all__D ---
A failure has been detected in another branch of the parallel make

bmake[5]: stopped in
/usr/data/source/git/opBSD/hardenedBSD.git/usr.sbin/acpi/iasl
*** [all] Error code 2

bmake[4]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.sbin/acpi
1 error

bmake[4]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.sbin/acpi
*** [all_subdir_acpi] Error code 2

bmake[3]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.sbin
1 error

bmake[3]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.sbin
*** [usr.sbin.all__D] Error code 2

bmake[2]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git
--- usr.bin.all__D ---
--- all_subdir_tblgen ---
A failure has been detected in another branch of the parallel make

bmake[5]: stopped in
/usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/tblgen
*** [all_subdir_tblgen] Error code 2

bmake[4]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang
2 errors

bmake[4]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang
*** [all_subdir_clang] Error code 2

bmake[3]: stopped in /usr/data/source/git/opBSD/hardenedBSD.git/usr.bin


   PAX ASLR: Blacklist the applications that don't support being built
 as a position-independent executable

 don't support as in you have tested them and confirmed that they break
 in some way?  Could you post your test methodology so people can
 replicate the failures and look into fixing them?

   PAX ASLR: Use a full kernel config for LATT-ASLR

 What is the difference between LATT-ASLR and OP-ASLR, and why not just
 include GENERIC?  You know about nooptions, right?

In upstreamed patch will be removed this kernel configs. These are
Shawn's and my kernel config.


   Revert PAX: blacklist clang and related binaries from PIE support
   Revert Revert PAX: blacklist clang and related binaries from PIE
 support

 Hmm...

See above.


 DES
 --
 Dag-Erling Smørgrav - d...@des.no

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-25 Thread Dimitry Andric

On 25 May 2014, at 19:42, Oliver Pinter oliver.p...@gmail.com wrote:
On 5/25/14, Dag-Erling Smørgrav d...@des.no wrote:
Oliver Pinter oliver.p...@gmail.com writes:
...
PAX: blacklist clang and related binaries from PIE support

Why? Performance, or do they actually break?

No. If you definded WITH_CLANG_EXTRAS= in src.conf, the breaked the build.
(added dim@ to CC)

--- usr.bin.all__D ---
/usr/obj/usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/bugpoint/../../../lib/clang/libllvmirreader/libllvmirreader.a:
could not read symbols: Bad value
c++: error: linker command failed with exit code 1 (use -v to see invocation)
*** [bugpoint] Error code 1

I assume you only get this with your ASLR patches applied? Maybe this is
because the clang binary itself gets built statically (and so will definitely
not be PIE), but the rest of the 'extras', such as bugpoint, are regular
dynamic executables. And note that none of the libraries built under
lib/libclang are built with -fPIC, at the moment. So that might cause trouble
with your PIE patches.

In any case, the interesting thing is what the actual linker error was. Do you
have more of the preceding build log, including the rest of the settings that
were used to build world? And also, what does file
/usr/obj/usr/data/source/git/opBSD/hardenedBSD.git/usr.bin/clang/bugpoint/../../../lib/clang/libllvmirreader/libllvmirreader.a
say?

-Dimitry

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-25 Thread Dag-Erling Smørgrav

Oliver Pinter oliver.p...@gmail.com writes:
 pax_log will be in future a generic pax related logging framework,
 with ratelimiting and other features.  It will log user, IP, binary
 name, path, checksum, and others.

What are you using this for?  Are you sure you can't use ktrace?  It's a
lot more flexible and powerful than you probably realize.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-25 Thread Oliver Pinter

On 5/25/14, Dag-Erling Smørgrav d...@des.no wrote:
 Oliver Pinter oliver.p...@gmail.com writes:
 pax_log will be in future a generic pax related logging framework,
 with ratelimiting and other features.  It will log user, IP, binary
 name, path, checksum, and others.

 What are you using this for?  Are you sure you can't use ktrace?  It's a
 lot more flexible and powerful than you probably realize.

Logging to system log, The feature will similar to this in grsecurity:
http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Kernel_Auditing


 DES
 --
 Dag-Erling Smørgrav - d...@des.no

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-25 Thread David Chisnall

On 25 May 2014, at 21:31, Oliver Pinter oliver.p...@gmail.com wrote:

 On 5/25/14, Dag-Erling Smørgrav d...@des.no wrote:
 Oliver Pinter oliver.p...@gmail.com writes:
 pax_log will be in future a generic pax related logging framework,
 with ratelimiting and other features.  It will log user, IP, binary
 name, path, checksum, and others.
 
 What are you using this for?  Are you sure you can't use ktrace?  It's a
 lot more flexible and powerful than you probably realize.
 
 Logging to system log, The feature will similar to this in grsecurity:
 http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Kernel_Auditing

It sounds like you actually want to be writing audit events then.  See audit(4).

David

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-25 Thread Julian Elischer


On 5/26/14, 5:18 AM, David Chisnall wrote:

On 25 May 2014, at 21:31, Oliver Pinter oliver.p...@gmail.com wrote:


On 5/25/14, Dag-Erling Smørgrav d...@des.no wrote:

Oliver Pinter oliver.p...@gmail.com writes:

pax_log will be in future a generic pax related logging framework,
with ratelimiting and other features.  It will log user, IP, binary
name, path, checksum, and others.

What are you using this for?  Are you sure you can't use ktrace?  It's a
lot more flexible and powerful than you probably realize.

Logging to system log, The feature will similar to this in grsecurity:
http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Kernel_Auditing

It sounds like you actually want to be writing audit events then.  See audit(4).


yeah I think the point is not use ktrace but use and/or possibly 
extend one of the several already existing methods.

we don't need *another* logging facility.



David

___
freebsd-secur...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org




___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-24 Thread Shawn Webb

On May 23, 2014 07:44 PM -0500, Pedro Giffuni wrote:
 (Dropped the cross-posting, which *is* frowned upon)
 
 While I do very much appreciate this work being done, and I agree we should 
 have it in the tree, I would really prefer it opt-in rather opt-out, at least 
 initially.
 
 I know this may very well be the subject of a bikeshed of historical 
 proportions but:
 
 1) Understand this may break some applications (?).

Yup. This is why we provide both ugidfw support for dynamic rulesets and
per-jail settings. We'll soon be adding FS extended attributes as well.

 
 2) It is yet undetermined what the performance effect will be.

Very early on, Oliver ran unixbench against the ASLR implementation.
There was some anomalous behaviors. Our implementation has drastically
changed since then and we ought to run unixbench again against the
current implementation. I've got a lot going on right now, but when
things settle down, I'll run unixbench under these conditions:

1) Vanilla FreeBSD 11-CURRENT with WITNESS and other debugging features
turned off.
2) FreeBSD 11-CURRENT with ASLR patches applied, but with ASLR turned
off, and with WITNESS and other debugging features turned off.
3) FreeBSD 11-CURRENT with ASLR patches applied, but with ASLR turned
on, and with WITNESS and other debugging features turned off.

I hope to have the tests done within the next two weeks.

 
 I find it very neat that it can be enabled for jails though.

That's my second favorite feature of our implementation, the first being
ugidfw integration. I'm glad to see you like the jails integration.

Thanks,

Shawn


pgpt0Dx797gBg.pgp
Description: PGP signature

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-24 Thread Oliver Pinter

On 5/24/14, Shawn Webb latt...@gmail.com wrote:
On May 23, 2014 07:53 PM +, Wojciech A. Koszek wrote:
On Wed, May 14, 2014 at 09:58:52AM -0400, Shawn Webb wrote:
Hey All,

[NOTE: crossposting between freebsd-current@, freebsd-security@, and
freebsd-stable@. Please forgive me if crossposting is frowned upon.]

Address Space Layout Randomization, or ASLR for short, is an exploit
mitigation technology. It helps secure applications against low-level
exploits. A popular secure implementation is known as PaX ASLR, which
is
a third-party patch for Linux. Our implementation is based off of
PaX's.

Oliver Pinter, Danilo Egea, and I have been working hard to bring more
features and robust stability to our ASLR patches. We've done extensive
testing on amd64. We'd like to get as many people testing these
patches.
Given the nature of them, we'd also like as many eyeballs reviewing the
code as well.

I also have a sparc64 box, but I'm having trouble getting a vanilla
11-current system to be stable on it. I ought to file a few PRs.

You can find links to the patches below.

Patch for 11-current:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff

Patch for 10-stable:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff

Shawn

I appreciate you working on this. We must have this in FreeBSD.

I looked at the patch and I read, but not run it. Comments below.

My personal opinion is that kern_pax.c should be compiled in by default.
If
it adds a lot of size, it'd be better to provide empty stub calls instead
of
#ifdef'ing everything. But security is very important especially in
embeddded systems, so you can imagine you're writing the code that
everybody
wants and must have enabled for decent level of security.

All modern systems run with ASLR turned on.

I skipped user-space stuff. I don't think it's necessary in this commit
and
should be separated.

There's a lot of lines of code for status showing. Not sure if we care
that
much: ASLR is either on or off. Not sure about more granularity. More
below.

Two idea here:
a) create a tunable security.pax.expert_mode, and create sysctls at
boot time depending from expert mode
(
https://github.com/HardenedBSD/hardenedBSD/blob/hardened/current/aslr/sys/kern/kern_sysctl.c#L460
)
b) just add CTLFLAG_SKIP and hide the sysctl from normal user
(
https://github.com/HardenedBSD/hardenedBSD/blob/hardened/current/aslr/sys/kern/kern_sysctl.c#L739
)

Lots of files:

You conditionally make .sv_pax_aslr_init method point to something else.
I'd
assume PAX function _pax_aslr_init32() always gets called and based on
whether ASLR is on or not, it does something or not. This will simplify
the
code a lot, and the difference probably won't be measurable.

You have:

int a;
int b;

instead of:

int a, b;

And you miss spaces around = sometimes.

Cleaning up the code and make style changes are a high priority on my
list. Once I get a few more pieces of code locked down, I'm going to go
over every line with a comb to make sure I'm adhering to the FreeBSD
coding style. des@ has made a lot of suggestions in that regard and has
even provided me with a sample vimrc. Prior to talking with des@, I was
re-using the same vimrc that I use for ClamAV (which, admittedly, has a
much different coding style than FreeBSD).

kern_jail.c:

something looks wrong here. Sounds like you need pr-pax. But I don't
understand why you need to have these pr_* values here. It seems
unnecessary.

kern_pax.c:

I can't quickly tell what locking is using. Some ASSERTS() in pax_
function
would help.

pax_aslr_active():

I don't see why you need to pass td and proc (I looked at usage: you
pass proc only once). I think you could always pass proc to it, with
td-td_proc passed typically.
kern_pax_*:

There's so many SYSCTLs I think people will have problem configuring it.
Pick reasonable value for all

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-23 Thread Wojciech A. Koszek

On Wed, May 14, 2014 at 09:58:52AM -0400, Shawn Webb wrote:
Hey All,

[NOTE: crossposting between freebsd-current@, freebsd-security@, and
freebsd-stable@. Please forgive me if crossposting is frowned upon.]

I also have a sparc64 box, but I'm having trouble getting a vanilla
11-current system to be stable on it. I ought to file a few PRs.

You can find links to the patches below.

Patch for 11-current:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff

Patch for 10-stable:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff

Shawn

I appreciate you working on this. We must have this in FreeBSD.

I looked at the patch and I read, but not run it. Comments below.

All modern systems run with ASLR turned on.

I skipped user-space stuff. I don't think it's necessary in this commit and
should be separated.

There's a lot of lines of code for status showing. Not sure if we care that
much: ASLR is either on or off. Not sure about more granularity. More below.

Lots of files:

You conditionally make .sv_pax_aslr_init method point to something else. I'd
assume PAX function _pax_aslr_init32() always gets called and based on
whether ASLR is on or not, it does something or not. This will simplify the
code a lot, and the difference probably won't be measurable.

You have:

int a;
int b;

instead of:

int a, b;

And you miss spaces around = sometimes.

kern_jail.c:

something looks wrong here. Sounds like you need pr-pax. But I don't
understand why you need to have these pr_* values here. It seems
unnecessary.

kern_pax.c:

I can't quickly tell what locking is using. Some ASSERTS() in pax_ function
would help.

pax_aslr_active():

I don't see why you need to pass td and proc (I looked at usage: you
pass proc only once). I think you could always pass proc to it, with
td-td_proc passed typically.

kern_pax_*:

There's so many SYSCTLs I think people will have problem configuring it.
Pick reasonable value for all values and let users change them via
SYSCTL_INT (static sysctls) only for debugging.

I can imagine we won't want ASLR only temporarily, for ports which break and
must be fixed. So we probably just need per-process ASLR on/off switch and a
wrapper which could be used like:

aslr off program

The debug stuff I'd remove too. We could have additional CTR stubs used
there, if necessary.

segvguard part I didn't understand. Why do you keep a list of programs that
failed? There was no ASSERTs, thus it was hard to understand the locking
too.

I'm trying to understand if randomization is done correctly. Do you think
you could post the results?

Program:

http://pastebin.com/XTRHLhMg

Results:
cat aslr.c
paste
gcc aslr.c -o aslr
echo 1 2 3 4 5 | xargs -I % -n 1 echo ./aslr aslr.% | sh
paste aslr.[12345] | column -t

Linux with ASLR:

http://pastebin.com/UuwW1JMN

MacOSX:

http://pastebin.com/kuQnYS4e

Thanks,

--
Wojciech A. Koszek
wkos...@freebsd.czest.pl
http://FreeBSD.czest.pl/~wkoszek/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-23 Thread Oliver Pinter

On 5/14/14, Shawn Webb latt...@gmail.com wrote:
 Hey All,

 [NOTE: crossposting between freebsd-current@, freebsd-security@, and
 freebsd-stable@. Please forgive me if crossposting is frowned upon.]

 Address Space Layout Randomization, or ASLR for short, is an exploit
 mitigation technology. It helps secure applications against low-level
 exploits. A popular secure implementation is known as PaX ASLR, which is
 a third-party patch for Linux. Our implementation is based off of PaX's.

 Oliver Pinter, Danilo Egea, and I have been working hard to bring more
 features and robust stability to our ASLR patches. We've done extensive
 testing on amd64. We'd like to get as many people testing these patches.
 Given the nature of them, we'd also like as many eyeballs reviewing the
 code as well.

 I have a Raspberry Pi and have noticed a few bugs. On ARM (at least, on
 the RPI), when a parent forks a child, and the child gracefully exits,
 the parent segfaults with the pc register pointing to 0xc000. That
 address is always the same, no matter the application. If anyone knows
 the ARM architecture well, and how FreeBSD ties into it, I'd like a
 little guidance.

 I also have a sparc64 box, but I'm having trouble getting a vanilla
 11-current system to be stable on it. I ought to file a few PRs.

 You can find links to the patches below.

 Patch for 11-current:
 http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff

 Patch for 10-stable:
 http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff

 Thanks,

 Shawn Webb


New round of patches are there:

11-CURRENT: 
http://www.crysys.hu/~op/freebsd/patches/20140524011327-freebsd-current-aslr-segvguard-SNAPSHOT.diff

10-STABLE: 
http://www.crysys.hu/~op/freebsd/patches/20140524011327-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff



What's changed related to previous tag:
11-CURRENT:
Oliver Pinter (17):
  PAX ASLR: update license in kern_pax_aslr.c
  PAX: update license in kern_pax.c
  PAX SEGVGUARD: update license in kern_pax_segvguard.c
  PAX: update license in pax.h
  PAX ASLR: remove unneeded parameter from pax_aslr_stack function
  PAX LOG: implement new logging subsystem
  PAX LOG: fix pax_ulog_segvguard
  PAX LOG: added sysctl's and tunables
  PAX ASLR: use PAX LOG
  PAX LOG: fix pax_ulog_##name()
  PAX LOG: fix prison init
  PAX LOG: fixed log and ulog sysctl
  PAX ASLR: fixed debug sysctl
  PAX: blacklist clang and related binaries from PIE support
  PAX ASLR: make ASLR by default opt-out
  Merge remote-tracking branch 'freebsd/master' into hardened/current/aslr
  Merge branch 'hardened/current/aslr' of
github.com:HardenedBSD/hardenedBSD into hardened/current/aslr

Shawn Webb (10):
  Remove CAN_PIE in preparation for NO_PIE
  Merge remote-tracking branch 'upstream/master' into hardened/current/aslr
  PAX ASLR: Blacklist the applications that don't support being
built as a position-independent executable
  Merge remote-tracking branch 'upstream/master' into hardened/current/aslr
  Disable PAX_SEGVGUARD in LATT-ASLR kernel
  PAX ASLR: Lock the jail when initializing PAX per-jail PAX settings
  PAX ASLR: Fix bug with pax_aslr_active()
  PAX ASLR: Use a full kernel config for LATT-ASLR
  Revert PAX: blacklist clang and related binaries from PIE support
  Revert Revert PAX: blacklist clang and related binaries from
PIE support


10-STABLE:
Oliver Pinter (20):
  PAX ASLR: update license in kern_pax_aslr.c
  PAX: update license in kern_pax.c
  PAX SEGVGUARD: update license in kern_pax_segvguard.c
  PAX: update license in pax.h
  PAX ASLR: remove unneeded parameter from pax_aslr_stack function
  PAX LOG: implement new logging subsystem
  PAX LOG: fix pax_ulog_segvguard
  PAX LOG: added sysctl's and tunables
  PAX ASLR: use PAX LOG
  PAX LOG: fix pax_ulog_##name()
  PAX LOG: fix prison init
  PAX LOG: fixed log and ulog sysctl
  PAX ASLR: fixed debug sysctl
  Merge remote-tracking branch 'freebsd/stable/10' into hardened/10/aslr
  Merge remote-tracking branch 'freebsd/stable/10' into hardened/10/aslr
  added OPN-ASLR kernel config
  PAX: Remove CAN_PIE in preparation for NO_PIE from /bin/sh
  PAX: blacklist clang and related binaries from PIE support
  PAX ASLR: make ASLR by default opt-out
  Merge remote-tracking branch 'freebsd/stable/10' into hardened/10/aslr

Shawn Webb (4):
  PAX: Remove CAN_PIE in preparation for NO_PIE
  PAX ASLR: Blacklist the applications that don't support being
built as a position-independent executable
  PAX ASLR: Lock the jail when initializing PAX per-jail PAX settings
  PAX ASLR: Fix bug with pax_aslr_active()
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-23 Thread Shawn Webb

On May 23, 2014 07:53 PM +, Wojciech A. Koszek wrote:
On Wed, May 14, 2014 at 09:58:52AM -0400, Shawn Webb wrote:
Hey All,

[NOTE: crossposting between freebsd-current@, freebsd-security@, and
freebsd-stable@. Please forgive me if crossposting is frowned upon.]

I also have a sparc64 box, but I'm having trouble getting a vanilla
11-current system to be stable on it. I ought to file a few PRs.

You can find links to the patches below.

Patch for 11-current:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff

Patch for 10-stable:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff

Shawn

I appreciate you working on this. We must have this in FreeBSD.

I looked at the patch and I read, but not run it. Comments below.

All modern systems run with ASLR turned on.

I skipped user-space stuff. I don't think it's necessary in this commit and
should be separated.

There's a lot of lines of code for status showing. Not sure if we care that
much: ASLR is either on or off. Not sure about more granularity. More below.

Lots of files:

You conditionally make .sv_pax_aslr_init method point to something else. I'd
assume PAX function _pax_aslr_init32() always gets called and based on
whether ASLR is on or not, it does something or not. This will simplify the
code a lot, and the difference probably won't be measurable.

You have:

int a;
int b;

instead of:

int a, b;

And you miss spaces around = sometimes.

kern_jail.c:

something looks wrong here. Sounds like you need pr-pax. But I don't
understand why you need to have these pr_* values here. It seems
unnecessary.

kern_pax.c:

I can't quickly tell what locking is using. Some ASSERTS() in pax_ function
would help.

pax_aslr_active():

I don't see why you need to pass td and proc (I looked at usage: you
pass proc only once). I think you could always pass proc to it, with
td-td_proc passed typically.
kern_pax_*:

There's so many SYSCTLs I think people will have problem configuring it.
Pick reasonable value for all values and let users change them via
SYSCTL_INT (static sysctls) only for debugging.

There are quite a few SYSCTLs, I agree. I'll talk with Oliver Pinter,
one of the developers that is working with me on this ASLR
implementation, to see if we can simplify this.

I can imagine we won't want ASLR only temporarily, for ports which break and
must be fixed. So we probably just need per-process ASLR on/off switch and a
wrapper which could

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-23 Thread Pedro Giffuni

(Dropped the cross-posting, which *is* frowned upon)

While I do very much appreciate this work being done, and I agree we should 
have it in the tree, I would really prefer it opt-in rather opt-out, at least 
initially.

I know this may very well be the subject of a bikeshed of historical 
proportions but:

1) Understand this may break some applications (?).

2) It is yet undetermined what the performance effect will be.

I find it very neat that it can be enabled for jails though.

Pedro.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-22 Thread Ian Lepore

On Wed, 2014-05-14 at 09:58 -0400, Shawn Webb wrote:
Hey All,

[NOTE: crossposting between freebsd-current@, freebsd-security@, and
freebsd-stable@. Please forgive me if crossposting is frowned upon.]

I almost forgot about your question (I was really busy when it first
arrived), sorry for the long delay.

I guess you must be saying that this parent segfault on child exit
happens when your aslr patches are in place? I've never seen anything
like that on arm. The 0xc000 address is the start of the kernel
address space. Also, the userland stack grows down from 0xbfff, so
walking off the top of the stack would hit that address.

-- Ian

I also have a sparc64 box, but I'm having trouble getting a vanilla
11-current system to be stable on it. I ought to file a few PRs.

You can find links to the patches below.

Patch for 11-current:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff

Patch for 10-stable:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff

Thanks,

Shawn Webb

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-14 Thread Shawn Webb

Hey All,

[NOTE: crossposting between freebsd-current@, freebsd-security@, and
freebsd-stable@. Please forgive me if crossposting is frowned upon.]

I also have a sparc64 box, but I'm having trouble getting a vanilla
11-current system to be stable on it. I ought to file a few PRs.

You can find links to the patches below.

Patch for 11-current:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff

Patch for 10-stable:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff

Thanks,

Shawn Webb

pgpnUWb8TUnz_.pgp
Description: PGP signature

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-14 Thread Adrian Chadd

Hi!

Cool! Does it run on MIPS? :P

-a

On 14 May 2014 06:58, Shawn Webb latt...@gmail.com wrote:
Hey All,

[NOTE: crossposting between freebsd-current@, freebsd-security@, and
freebsd-stable@. Please forgive me if crossposting is frowned upon.]

I also have a sparc64 box, but I'm having trouble getting a vanilla
11-current system to be stable on it. I ought to file a few PRs.

You can find links to the patches below.

Patch for 11-current:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff

Patch for 10-stable:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff

Thanks,

Shawn Webb
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-14 Thread Shawn Webb

It runs on all architectures FreeBSD supports. The question is how well
it runs. The wider the testing, the better the code, of course. We're
actively testing on amd64 and i386 with limited testing on sparc64 and
ARM. I've been running with this patches on amd64 on multiple machines
for months. amd64 is rock solid from my experience. But your mileage may
vary, hence the CFT. :-)

Thanks,

Shawn

On May 14, 2014 10:02 AM -0700, Adrian Chadd wrote:
Hi!

Cool! Does it run on MIPS? :P

-a

On 14 May 2014 06:58, Shawn Webb latt...@gmail.com wrote:
Hey All,

[NOTE: crossposting between freebsd-current@, freebsd-security@, and
freebsd-stable@. Please forgive me if crossposting is frowned upon.]

I also have a sparc64 box, but I'm having trouble getting a vanilla
11-current system to be stable on it. I ought to file a few PRs.

You can find links to the patches below.

Patch for 11-current:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff

Patch for 10-stable:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff

Thanks,

Shawn Webb

pgph_5tsmmLH1.pgp
Description: PGP signature

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-14 Thread Adrian Chadd

On 14 May 2014 10:09, Shawn Webb latt...@gmail.com wrote:
 It runs on all architectures FreeBSD supports. The question is how well
 it runs. The wider the testing, the better the code, of course. We're
 actively testing on amd64 and i386 with limited testing on sparc64 and
 ARM. I've been running with this patches on amd64 on multiple machines
 for months. amd64 is rock solid from my experience. But your mileage may
 vary, hence the CFT. :-)

:)

So for MIPS, there's a documented way to run up the emulator framework
to do testing.

https://wiki.freebsd.org/FreeBSD/MipsEmulation

That way you can give it a whirl before us MIPS people with hardware
can get around to it. :P



-a
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] ASLR and PIE on amd64

2014-04-28 Thread Oliver Pinter

Updated aslr + segvguard SNAPSHOT patches, see the attachments.

freebsd-stable-10-r265039-aslr-segvguard-SNAPSHOT.diff  : against
stable/10 @r265039

freebsd-current-r265046-aslr-segvguard-SNAPSHOT.diff  : against current @r265046

To apply the patch, use this command:
patch -p1  freebsd-stable-10-r265039-aslr-segvguard-SNAPSHOT.diff
or
patch -p1  freebsd-current-r265046-aslr-segvguard-SNAPSHOT.diff


github: https://github.com/HardenedBSD/hardenedBSD/commits/hardened/10/aslr
github: https://github.com/HardenedBSD/hardenedBSD/commits/hardened/current/aslr

git: https://github.com/HardenedBSD/hardenedBSD.git
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] ASLR and PIE on amd64

2014-04-08 Thread Oliver Pinter

On 4/2/14, Shawn Webb latt...@gmail.com wrote:
 On Apr 02, 2014 04:54 PM +0200, Oliver Pinter wrote:
 On 4/2/14, Oliver Pinter oliver.p...@gmail.com wrote:
  On 3/31/14, Shawn Webb latt...@gmail.com wrote:
  On Mar 31, 2014 02:07 AM +0200, Oliver Pinter wrote:
  On 3/22/14, Shawn Webb latt...@gmail.com wrote:
   Hey All,
  
   First off, I hope that even as a non-committer, it's okay that I
   post
   a call for testing. If not, please excuse my newbishness in this
   process. This is my first time submitting a major patch upstream to
   FreeBSD.
  
   Over the past few months, I've had the opportunity and pleasure to
   enhance existing patches to FreeBSD that implement a common exploit
   mitigation technology called Address Space Layout Randomization
   (ASLR)
   along with support for Position Independent Executables (PIE).
   ASLR+PIE has been a long-requested feature by many people I've met
   on
   IRC.
  
   I've submitted my patch to PR kernel/181497. I'm currently in the
   process of adding PIE support to certain high-visibility
   applications
   in base (mainly network daemons). I've added a make.conf knob
   that's
   default to enabled (WITH_PIE=1). An application has to also
   explicitly
   support PIE as well by defining CAN_PIE in the Makefile prior to
   including bsd.prog.mk. After I get a decent amount of applications
   enabled with PIE support, I'll submit one last patch.
  
   The following sysctl's can be set with a kernel compiled with the
   PAX_ASLR option:
  
   security.pax.aslr.status: 1
   security.pax.aslr.debug: 0
   security.pax.aslr.mmap_len: 16
   security.pax.aslr.stack_len: 12
   security.pax.aslr.exec_len: 12
  
   The security.pax.aslr.status sysctl enables and disables the ASLR
   system as a whole. The debug sysctl gives debugging output. The
   mmap_len sysctl tells the ASLR system how many bits to randomize
   with
   mmap() is called. The stack_len sysctl tells the ASLR system how
   many
   bits to randomize in the stack. The exec_len sysctl tells the ASLR
   system how many bits to randomize the execbase (this controls PIE).
   These sysctls can be set as a per-jail basis. If you have an
   application which doesn't support ASLR, yet you want ASLR enabled
   for
   everything else, you can simply place that misbehaving application
   in
   a jail with only that jail's ASLR settings turned off.
  
   Please let me know how your testing goes. I'm giving a presentation
   at
   BSDCan regarding this.
  
   If you want to keep tabs on my bleeding-edge development process,
   please follow my progress on GitHub:
   https://github.com/lattera/freebsd (branch: soldierx/lattera/aslr).
  
   Thank you very much,
 
  Hi!
 
  Please apply this patch. This fixed an issue with tunables.
 
  Patch merged successfully into my GitHub repo. Fixed with commit
  d2c0813. I'll include it in my next patch submission upstream when I
  submit my PIE work. Thanks!
 
  please see the attached patch, compile and boot tested on amd64


 Some more patches, and one critical fix
 (0006-PAX-ASLR-use-the-right-sysent-before-this-commit-cal.patch).

 You are awesome. I'll integrate those patches today. In reviewing your
 patches, I noticed a few places where I'm keying off the local
 pax_aslr_debug variable. I ought to switch that to keying off the jail's
 pr_pax_aslr_debug variable.


https://github.com/HardenedBSD/hardenedBSD/commits/hardened/10/aslr
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] ASLR and PIE on amd64

2014-04-08 Thread Shawn Webb

On Apr 09, 2014 02:17 AM +0200, Oliver Pinter wrote:
 On 4/2/14, Shawn Webb latt...@gmail.com wrote:
  On Apr 02, 2014 04:54 PM +0200, Oliver Pinter wrote:
  On 4/2/14, Oliver Pinter oliver.p...@gmail.com wrote:
   On 3/31/14, Shawn Webb latt...@gmail.com wrote:
   On Mar 31, 2014 02:07 AM +0200, Oliver Pinter wrote:
   On 3/22/14, Shawn Webb latt...@gmail.com wrote:
Hey All,
   
First off, I hope that even as a non-committer, it's okay that I
post
a call for testing. If not, please excuse my newbishness in this
process. This is my first time submitting a major patch upstream to
FreeBSD.
   
Over the past few months, I've had the opportunity and pleasure to
enhance existing patches to FreeBSD that implement a common exploit
mitigation technology called Address Space Layout Randomization
(ASLR)
along with support for Position Independent Executables (PIE).
ASLR+PIE has been a long-requested feature by many people I've met
on
IRC.
   
I've submitted my patch to PR kernel/181497. I'm currently in the
process of adding PIE support to certain high-visibility
applications
in base (mainly network daemons). I've added a make.conf knob
that's
default to enabled (WITH_PIE=1). An application has to also
explicitly
support PIE as well by defining CAN_PIE in the Makefile prior to
including bsd.prog.mk. After I get a decent amount of applications
enabled with PIE support, I'll submit one last patch.
   
The following sysctl's can be set with a kernel compiled with the
PAX_ASLR option:
   
security.pax.aslr.status: 1
security.pax.aslr.debug: 0
security.pax.aslr.mmap_len: 16
security.pax.aslr.stack_len: 12
security.pax.aslr.exec_len: 12
   
The security.pax.aslr.status sysctl enables and disables the ASLR
system as a whole. The debug sysctl gives debugging output. The
mmap_len sysctl tells the ASLR system how many bits to randomize
with
mmap() is called. The stack_len sysctl tells the ASLR system how
many
bits to randomize in the stack. The exec_len sysctl tells the ASLR
system how many bits to randomize the execbase (this controls PIE).
These sysctls can be set as a per-jail basis. If you have an
application which doesn't support ASLR, yet you want ASLR enabled
for
everything else, you can simply place that misbehaving application
in
a jail with only that jail's ASLR settings turned off.
   
Please let me know how your testing goes. I'm giving a presentation
at
BSDCan regarding this.
   
If you want to keep tabs on my bleeding-edge development process,
please follow my progress on GitHub:
https://github.com/lattera/freebsd (branch: soldierx/lattera/aslr).
   
Thank you very much,
  
   Hi!
  
   Please apply this patch. This fixed an issue with tunables.
  
   Patch merged successfully into my GitHub repo. Fixed with commit
   d2c0813. I'll include it in my next patch submission upstream when I
   submit my PIE work. Thanks!
  
   please see the attached patch, compile and boot tested on amd64
 
 
  Some more patches, and one critical fix
  (0006-PAX-ASLR-use-the-right-sysent-before-this-commit-cal.patch).
 
  You are awesome. I'll integrate those patches today. In reviewing your
  patches, I noticed a few places where I'm keying off the local
  pax_aslr_debug variable. I ought to switch that to keying off the jail's
  pr_pax_aslr_debug variable.
 
 
 https://github.com/HardenedBSD/hardenedBSD/commits/hardened/10/aslr

And for anyone who's tracking HEAD (like me):
https://github.com/HardenedBSD/hardenedBSD/commits/hardened/current/aslr


pgpxHOeRmSC1p.pgp
Description: PGP signature

Re: [CFT] ASLR and PIE on amd64

2014-04-02 Thread Oliver Pinter

On 4/2/14, Oliver Pinter oliver.p...@gmail.com wrote:
 On 3/31/14, Shawn Webb latt...@gmail.com wrote:
 On Mar 31, 2014 02:07 AM +0200, Oliver Pinter wrote:
 On 3/22/14, Shawn Webb latt...@gmail.com wrote:
  Hey All,
 
  First off, I hope that even as a non-committer, it's okay that I post
  a call for testing. If not, please excuse my newbishness in this
  process. This is my first time submitting a major patch upstream to
  FreeBSD.
 
  Over the past few months, I've had the opportunity and pleasure to
  enhance existing patches to FreeBSD that implement a common exploit
  mitigation technology called Address Space Layout Randomization (ASLR)
  along with support for Position Independent Executables (PIE).
  ASLR+PIE has been a long-requested feature by many people I've met on
  IRC.
 
  I've submitted my patch to PR kernel/181497. I'm currently in the
  process of adding PIE support to certain high-visibility applications
  in base (mainly network daemons). I've added a make.conf knob that's
  default to enabled (WITH_PIE=1). An application has to also explicitly
  support PIE as well by defining CAN_PIE in the Makefile prior to
  including bsd.prog.mk. After I get a decent amount of applications
  enabled with PIE support, I'll submit one last patch.
 
  The following sysctl's can be set with a kernel compiled with the
  PAX_ASLR option:
 
  security.pax.aslr.status: 1
  security.pax.aslr.debug: 0
  security.pax.aslr.mmap_len: 16
  security.pax.aslr.stack_len: 12
  security.pax.aslr.exec_len: 12
 
  The security.pax.aslr.status sysctl enables and disables the ASLR
  system as a whole. The debug sysctl gives debugging output. The
  mmap_len sysctl tells the ASLR system how many bits to randomize with
  mmap() is called. The stack_len sysctl tells the ASLR system how many
  bits to randomize in the stack. The exec_len sysctl tells the ASLR
  system how many bits to randomize the execbase (this controls PIE).
  These sysctls can be set as a per-jail basis. If you have an
  application which doesn't support ASLR, yet you want ASLR enabled for
  everything else, you can simply place that misbehaving application in
  a jail with only that jail's ASLR settings turned off.
 
  Please let me know how your testing goes. I'm giving a presentation at
  BSDCan regarding this.
 
  If you want to keep tabs on my bleeding-edge development process,
  please follow my progress on GitHub:
  https://github.com/lattera/freebsd (branch: soldierx/lattera/aslr).
 
  Thank you very much,

 Hi!

 Please apply this patch. This fixed an issue with tunables.

 Patch merged successfully into my GitHub repo. Fixed with commit
 d2c0813. I'll include it in my next patch submission upstream when I
 submit my PIE work. Thanks!

 please see the attached patch, compile and boot tested on amd64


Some more patches, and one critical fix
(0006-PAX-ASLR-use-the-right-sysent-before-this-commit-cal.patch).


0001-PAX-ASLR-remove-dirty-hack-to-determine-which-pax_in.patch
Description: Binary data


0002-PAX-ASLR-updated-debug-messages.patch
Description: Binary data


0003-PAX-ASLR-removed-unused-variable.patch
Description: Binary data


0004-PaX-ASLR-added-more-debug-messages.patch
Description: Binary data


0005-PAX-ASLR-fix-debug-messages-added-new-line.patch
Description: Binary data


0006-PAX-ASLR-use-the-right-sysent-before-this-commit-cal.patch
Description: Binary data
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] ASLR and PIE on amd64

2014-04-02 Thread Shawn Webb

On Apr 02, 2014 04:54 PM +0200, Oliver Pinter wrote:
 On 4/2/14, Oliver Pinter oliver.p...@gmail.com wrote:
  On 3/31/14, Shawn Webb latt...@gmail.com wrote:
  On Mar 31, 2014 02:07 AM +0200, Oliver Pinter wrote:
  On 3/22/14, Shawn Webb latt...@gmail.com wrote:
   Hey All,
  
   First off, I hope that even as a non-committer, it's okay that I post
   a call for testing. If not, please excuse my newbishness in this
   process. This is my first time submitting a major patch upstream to
   FreeBSD.
  
   Over the past few months, I've had the opportunity and pleasure to
   enhance existing patches to FreeBSD that implement a common exploit
   mitigation technology called Address Space Layout Randomization (ASLR)
   along with support for Position Independent Executables (PIE).
   ASLR+PIE has been a long-requested feature by many people I've met on
   IRC.
  
   I've submitted my patch to PR kernel/181497. I'm currently in the
   process of adding PIE support to certain high-visibility applications
   in base (mainly network daemons). I've added a make.conf knob that's
   default to enabled (WITH_PIE=1). An application has to also explicitly
   support PIE as well by defining CAN_PIE in the Makefile prior to
   including bsd.prog.mk. After I get a decent amount of applications
   enabled with PIE support, I'll submit one last patch.
  
   The following sysctl's can be set with a kernel compiled with the
   PAX_ASLR option:
  
   security.pax.aslr.status: 1
   security.pax.aslr.debug: 0
   security.pax.aslr.mmap_len: 16
   security.pax.aslr.stack_len: 12
   security.pax.aslr.exec_len: 12
  
   The security.pax.aslr.status sysctl enables and disables the ASLR
   system as a whole. The debug sysctl gives debugging output. The
   mmap_len sysctl tells the ASLR system how many bits to randomize with
   mmap() is called. The stack_len sysctl tells the ASLR system how many
   bits to randomize in the stack. The exec_len sysctl tells the ASLR
   system how many bits to randomize the execbase (this controls PIE).
   These sysctls can be set as a per-jail basis. If you have an
   application which doesn't support ASLR, yet you want ASLR enabled for
   everything else, you can simply place that misbehaving application in
   a jail with only that jail's ASLR settings turned off.
  
   Please let me know how your testing goes. I'm giving a presentation at
   BSDCan regarding this.
  
   If you want to keep tabs on my bleeding-edge development process,
   please follow my progress on GitHub:
   https://github.com/lattera/freebsd (branch: soldierx/lattera/aslr).
  
   Thank you very much,
 
  Hi!
 
  Please apply this patch. This fixed an issue with tunables.
 
  Patch merged successfully into my GitHub repo. Fixed with commit
  d2c0813. I'll include it in my next patch submission upstream when I
  submit my PIE work. Thanks!
 
  please see the attached patch, compile and boot tested on amd64
 
 
 Some more patches, and one critical fix
 (0006-PAX-ASLR-use-the-right-sysent-before-this-commit-cal.patch).

You are awesome. I'll integrate those patches today. In reviewing your
patches, I noticed a few places where I'm keying off the local
pax_aslr_debug variable. I ought to switch that to keying off the jail's
pr_pax_aslr_debug variable.


pgp_l2AgaRe3M.pgp
Description: PGP signature

Re: [CFT] ASLR and PIE on amd64

2014-04-01 Thread Oliver Pinter

On 3/31/14, Shawn Webb latt...@gmail.com wrote:
 On Mar 31, 2014 02:07 AM +0200, Oliver Pinter wrote:
 On 3/22/14, Shawn Webb latt...@gmail.com wrote:
  Hey All,
 
  First off, I hope that even as a non-committer, it's okay that I post
  a call for testing. If not, please excuse my newbishness in this
  process. This is my first time submitting a major patch upstream to
  FreeBSD.
 
  Over the past few months, I've had the opportunity and pleasure to
  enhance existing patches to FreeBSD that implement a common exploit
  mitigation technology called Address Space Layout Randomization (ASLR)
  along with support for Position Independent Executables (PIE).
  ASLR+PIE has been a long-requested feature by many people I've met on
  IRC.
 
  I've submitted my patch to PR kernel/181497. I'm currently in the
  process of adding PIE support to certain high-visibility applications
  in base (mainly network daemons). I've added a make.conf knob that's
  default to enabled (WITH_PIE=1). An application has to also explicitly
  support PIE as well by defining CAN_PIE in the Makefile prior to
  including bsd.prog.mk. After I get a decent amount of applications
  enabled with PIE support, I'll submit one last patch.
 
  The following sysctl's can be set with a kernel compiled with the
  PAX_ASLR option:
 
  security.pax.aslr.status: 1
  security.pax.aslr.debug: 0
  security.pax.aslr.mmap_len: 16
  security.pax.aslr.stack_len: 12
  security.pax.aslr.exec_len: 12
 
  The security.pax.aslr.status sysctl enables and disables the ASLR
  system as a whole. The debug sysctl gives debugging output. The
  mmap_len sysctl tells the ASLR system how many bits to randomize with
  mmap() is called. The stack_len sysctl tells the ASLR system how many
  bits to randomize in the stack. The exec_len sysctl tells the ASLR
  system how many bits to randomize the execbase (this controls PIE).
  These sysctls can be set as a per-jail basis. If you have an
  application which doesn't support ASLR, yet you want ASLR enabled for
  everything else, you can simply place that misbehaving application in
  a jail with only that jail's ASLR settings turned off.
 
  Please let me know how your testing goes. I'm giving a presentation at
  BSDCan regarding this.
 
  If you want to keep tabs on my bleeding-edge development process,
  please follow my progress on GitHub:
  https://github.com/lattera/freebsd (branch: soldierx/lattera/aslr).
 
  Thank you very much,

 Hi!

 Please apply this patch. This fixed an issue with tunables.

 Patch merged successfully into my GitHub repo. Fixed with commit
 d2c0813. I'll include it in my next patch submission upstream when I
 submit my PIE work. Thanks!

please see the attached patch, compile and boot tested on amd64




0001-PAX-ASLR-remove-dirty-hack-to-determine-which-pax_in.patch
Description: Binary data
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] ASLR and PIE on amd64

2014-03-30 Thread Oliver Pinter

On 3/22/14, Shawn Webb latt...@gmail.com wrote:
 Hey All,

 First off, I hope that even as a non-committer, it's okay that I post
 a call for testing. If not, please excuse my newbishness in this
 process. This is my first time submitting a major patch upstream to
 FreeBSD.

 Over the past few months, I've had the opportunity and pleasure to
 enhance existing patches to FreeBSD that implement a common exploit
 mitigation technology called Address Space Layout Randomization (ASLR)
 along with support for Position Independent Executables (PIE).
 ASLR+PIE has been a long-requested feature by many people I've met on
 IRC.

 I've submitted my patch to PR kernel/181497. I'm currently in the
 process of adding PIE support to certain high-visibility applications
 in base (mainly network daemons). I've added a make.conf knob that's
 default to enabled (WITH_PIE=1). An application has to also explicitly
 support PIE as well by defining CAN_PIE in the Makefile prior to
 including bsd.prog.mk. After I get a decent amount of applications
 enabled with PIE support, I'll submit one last patch.

 The following sysctl's can be set with a kernel compiled with the
 PAX_ASLR option:

 security.pax.aslr.status: 1
 security.pax.aslr.debug: 0
 security.pax.aslr.mmap_len: 16
 security.pax.aslr.stack_len: 12
 security.pax.aslr.exec_len: 12

 The security.pax.aslr.status sysctl enables and disables the ASLR
 system as a whole. The debug sysctl gives debugging output. The
 mmap_len sysctl tells the ASLR system how many bits to randomize with
 mmap() is called. The stack_len sysctl tells the ASLR system how many
 bits to randomize in the stack. The exec_len sysctl tells the ASLR
 system how many bits to randomize the execbase (this controls PIE).
 These sysctls can be set as a per-jail basis. If you have an
 application which doesn't support ASLR, yet you want ASLR enabled for
 everything else, you can simply place that misbehaving application in
 a jail with only that jail's ASLR settings turned off.

 Please let me know how your testing goes. I'm giving a presentation at
 BSDCan regarding this.

 If you want to keep tabs on my bleeding-edge development process,
 please follow my progress on GitHub:
 https://github.com/lattera/freebsd (branch: soldierx/lattera/aslr).

 Thank you very much,

Hi!

Please apply this patch. This fixed an issue with tunables.


 Shawn Webb
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org



0001-PaX-ASLR-fixed-tunables-in-kern_pax.c.patch
Description: Binary data
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] ASLR and PIE on amd64

2014-03-30 Thread Shawn Webb

On Mar 31, 2014 02:07 AM +0200, Oliver Pinter wrote:
 On 3/22/14, Shawn Webb latt...@gmail.com wrote:
  Hey All,
 
  First off, I hope that even as a non-committer, it's okay that I post
  a call for testing. If not, please excuse my newbishness in this
  process. This is my first time submitting a major patch upstream to
  FreeBSD.
 
  Over the past few months, I've had the opportunity and pleasure to
  enhance existing patches to FreeBSD that implement a common exploit
  mitigation technology called Address Space Layout Randomization (ASLR)
  along with support for Position Independent Executables (PIE).
  ASLR+PIE has been a long-requested feature by many people I've met on
  IRC.
 
  I've submitted my patch to PR kernel/181497. I'm currently in the
  process of adding PIE support to certain high-visibility applications
  in base (mainly network daemons). I've added a make.conf knob that's
  default to enabled (WITH_PIE=1). An application has to also explicitly
  support PIE as well by defining CAN_PIE in the Makefile prior to
  including bsd.prog.mk. After I get a decent amount of applications
  enabled with PIE support, I'll submit one last patch.
 
  The following sysctl's can be set with a kernel compiled with the
  PAX_ASLR option:
 
  security.pax.aslr.status: 1
  security.pax.aslr.debug: 0
  security.pax.aslr.mmap_len: 16
  security.pax.aslr.stack_len: 12
  security.pax.aslr.exec_len: 12
 
  The security.pax.aslr.status sysctl enables and disables the ASLR
  system as a whole. The debug sysctl gives debugging output. The
  mmap_len sysctl tells the ASLR system how many bits to randomize with
  mmap() is called. The stack_len sysctl tells the ASLR system how many
  bits to randomize in the stack. The exec_len sysctl tells the ASLR
  system how many bits to randomize the execbase (this controls PIE).
  These sysctls can be set as a per-jail basis. If you have an
  application which doesn't support ASLR, yet you want ASLR enabled for
  everything else, you can simply place that misbehaving application in
  a jail with only that jail's ASLR settings turned off.
 
  Please let me know how your testing goes. I'm giving a presentation at
  BSDCan regarding this.
 
  If you want to keep tabs on my bleeding-edge development process,
  please follow my progress on GitHub:
  https://github.com/lattera/freebsd (branch: soldierx/lattera/aslr).
 
  Thank you very much,
 
 Hi!
 
 Please apply this patch. This fixed an issue with tunables.

Patch merged successfully into my GitHub repo. Fixed with commit
d2c0813. I'll include it in my next patch submission upstream when I
submit my PIE work. Thanks!


pgpcK7WD3olj8.pgp
Description: PGP signature

[CFT] ASLR and PIE on amd64

2014-03-21 Thread Shawn Webb

Hey All,

First off, I hope that even as a non-committer, it's okay that I post
a call for testing. If not, please excuse my newbishness in this
process. This is my first time submitting a major patch upstream to
FreeBSD.

Over the past few months, I've had the opportunity and pleasure to
enhance existing patches to FreeBSD that implement a common exploit
mitigation technology called Address Space Layout Randomization (ASLR)
along with support for Position Independent Executables (PIE).
ASLR+PIE has been a long-requested feature by many people I've met on
IRC.

I've submitted my patch to PR kernel/181497. I'm currently in the
process of adding PIE support to certain high-visibility applications
in base (mainly network daemons). I've added a make.conf knob that's
default to enabled (WITH_PIE=1). An application has to also explicitly
support PIE as well by defining CAN_PIE in the Makefile prior to
including bsd.prog.mk. After I get a decent amount of applications
enabled with PIE support, I'll submit one last patch.

The following sysctl's can be set with a kernel compiled with the
PAX_ASLR option:

security.pax.aslr.status: 1
security.pax.aslr.debug: 0
security.pax.aslr.mmap_len: 16
security.pax.aslr.stack_len: 12
security.pax.aslr.exec_len: 12

The security.pax.aslr.status sysctl enables and disables the ASLR
system as a whole. The debug sysctl gives debugging output. The
mmap_len sysctl tells the ASLR system how many bits to randomize with
mmap() is called. The stack_len sysctl tells the ASLR system how many
bits to randomize in the stack. The exec_len sysctl tells the ASLR
system how many bits to randomize the execbase (this controls PIE).
These sysctls can be set as a per-jail basis. If you have an
application which doesn't support ASLR, yet you want ASLR enabled for
everything else, you can simply place that misbehaving application in
a jail with only that jail's ASLR settings turned off.

Please let me know how your testing goes. I'm giving a presentation at
BSDCan regarding this.

If you want to keep tabs on my bleeding-edge development process,
please follow my progress on GitHub:
https://github.com/lattera/freebsd (branch: soldierx/lattera/aslr).

Thank you very much,

Shawn Webb
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

54 matches

Mail list logo