Re: ASLR/PIE status in FreeBSD HEAD
On Mon, 20 Apr 2020 at 10:22, Marcin Wojtas wrote: > > Indeed I thought of kyua and measuring buildworld execution time for > stressing the DUT and having the first comparison numbers for the low > price. > > Do you think it is possible to get help here, i.e. is there a FreeBSD > devops team, maintaining the Jenkins CI whose spare cycles could be > used for this purpose? Or is this a field requiring external help from > interested parties? There aren't a lot of spare cycles to go around, but putting automation in place so that tests like this can easily be performed is certainly something that's in the Jenkins team's domain. > Yes, making use of something actively maintained would be great. Do > you see a need for IO stressing/benchmarking for the discussed cases? In the fullness of time I think it's important, but my opinion is that it's really functional tests that we need, for enabling features in -CURRENT; we can work on benchmarking before and after changing a default. ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: ASLR/PIE status in FreeBSD HEAD
On Wed, 22 Apr 2020 at 02:10, Dewayne Geraghty wrote: > > Thank-you for the pointer to elfctl. Unfortunately it looks like I need > to create the section in the image file, due to my: (for example) > > # elfctl -l /usr/bin/ztest > Known features are: > aslrDisable ASLR > protmax Disable implicit PROT_MAX > stackgapDisable stack gap > elfctl: NT_FREEBSD_FEATURE_CTL note not found > > on > FreeBSD 12.1-STABLE #0 r359973M: Thu Apr 16 amd64 1201513 1201513 Ah, yes - r340701 needs to be MFC'd to stable/12 to make this work there. ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: ASLR/PIE status in FreeBSD HEAD
On Thu, 23 Apr 2020 at 11:38, Brooks Davis wrote: > > > I was thinking if it is possible to come up with such wide test > > coverage to test every single application from the base system. Do you > > think it is achievable or should we rather follow the approach to do > > as many tests as possible, but rely on the community feedback to catch > > the corner cases (like the ntpd issue mentioned in this thread)? > > What about the ports? > > If we gate on full testing we'll never move forward. We had a GSoC > project a few years ago to try to generate lame tests for each program, > if someone picked that up, we could get better coverage fairly > quickly, but it would still be far from complete. Indeed, having a basic smoke test for as much of the base system as possible is a good initial step. I suspect it won't take very long to have confidence in turning on options for the base system, but ports will be a much longer process. For ports I think the first thing that needs to happen is to have some infrastructure in ports itself to allow individual ports to indicate (via elfctl) that they are not compatible with certain options; with that in place it should be trivial to start marking individual ports. ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
