For example it is possible to share file descriptor tables, and one of the processes may not be encumbered by the jail.

I'm going to have to sleep on the approach. This is a known escape, but I don't know if the method used can fully plug it. For example it is possible to share file descriptor tables, and one of the processes may not be encumbered by the jail. As is it does solve it for processes which have no way to talk to each other apart from a partially shared fs though.

I'll do the commit. Thanks to Greg for writing this and to everyone who helped to review it!

Who is going to do the actual commit? I'm happy to do it if no-one else wants to? Whoever does it has csprng@ green-light.

Last nit can be done pre-commit or I can whack it post-commit; ok from lua perspective.

Is this ready to be committed? I'm happy to do it myself but markm said he was going to commit (prior to the latest round of changes) -- don't want to commit prematurely if you're still waiting for something.

Yep, I've had basically the exact same opinion as @delphij about the copyright. Let's go with Intel.

So seems like it's easier to just do it all in core.lua, which is where lots of config accesses are anyway.

In D20780#766778, @greg_unrelenting.technology wrote:

err, I have not addressed the "isUEFIBoot" thing and the "This file needs a copyright / license at the top" thing…

err, I have not addressed the "isUEFIBoot" thing and the "This file needs a copyright / license at the top" thing…

Thanks! Can you also MFC it to stable/13 after a week?

In D20780#766643, @cperciva wrote:

Is this waiting for anything else before it gets committed?

Is this waiting for anything else before it gets committed?

I did a minor edit on the proposed commit message to clarify some things (sorry I do not have it as a diff)

In D27666#745003, @mw wrote:

Altough I agree it should be safe to enable ASLR 32-bit, for now I'd stay with 64-bit only - please remember that after a discussion it was decided to compile only 64-bit executables "WITH_PIE".

In D27666#744977, @kib wrote:

In D27666#744939, @emaste wrote:

I might write are not changed at this time to suggest this is not necessarily a final decision (in fact, it's not really a decision at all, 32-bit is probably not relevant enough to spend much effort on).

For 32bit, it might make sense to enable ASLR for 32bit binaries on 64bit host, still. That said, i386 kernel provides almost full 4G for UVA, so it might make sense to enable there as well, but lets limit the change to 64bit kernels, indeed.

In D27666#744939, @emaste wrote:

I might write are not changed at this time to suggest this is not necessarily a final decision (in fact, it's not really a decision at all, 32-bit is probably not relevant enough to spend much effort on).

In D27666#744939, @emaste wrote:

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. Also, for the sake of safety keep the feature disabled for 32-bit
executables on 64-bit machines, too.

I might write are not changed at this time to suggest this is not necessarily a final decision (in fact, it's not really a decision at all, 32-bit is probably not relevant enough to spend much effort on).

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. Also, for the sake of safety keep the feature disabled for 32-bit
executables on 64-bit machines, too.

In D27666#744905, @kib wrote:

Yes, leave it. I think it is verbose but explicit so that more people can notice that if pointed to.

Yes, leave it. I think it is verbose but explicit so that more people can notice that if pointed to.

In D27666#744903, @kib wrote:

I suggest also dropping the

In case any change in the OS behavior is observed, that can be possibly
caused by this patch, it is recommended to use freebsd-bugs@freebsd.org
mailing list for reporting and discussing the encountered issue. Also,

wording.

I suggest also dropping the

In case any change in the OS behavior is observed, that can be possibly
caused by this patch, it is recommended to use freebsd-bugs@freebsd.org
mailing list for reporting and discussing the encountered issue. Also,

wording.

I think it is better to provide short and concise list of potential issues with ASLR, like this:

• changed ABI due to modified layout of address space
• address space fragmentation
• non-reproducable address space layout between runs
• harder debugging
• some debuggers automatically disable ASLR for spawned targets, making target' environment different between debug and non-debug runs

Limit setting of __elfN(pie_aslr_enabled) for only 64-bit PIE binaries.

Hi! Any comments/remarks to the updated version?

In D27666#734447, @lattera-gmail.com wrote:

In D27666#734443, @mw wrote:

Hi,

I'm refreshing the discussion. The current status is following:

3. Fixes for the outstanding bugs ntpd (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253208) and Firefox/Thunderbird (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239873) landed on Friday. Hopefully this will cover all cases that might have remained unknown until now.

It seems like a problem with the underlying AS{L}R implementation. HardenedBSD has not needed to make any changes to any application since it completed its PaX-inspired ASLR implementation in 2015. If applications experience issues with FreeBSD's AS{L}R implementation, it'd be safe to assume a problem with the AS{L}R implementation, not the application.

In D27666#734443, @mw wrote:

Hi,

I'm refreshing the discussion. The current status is following:

3. Fixes for the outstanding bugs ntpd (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253208) and Firefox/Thunderbird (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239873) landed on Friday. Hopefully this will cover all cases that might have remained unknown until now.

I'm refreshing the discussion. The current status is following:

1. PIE enabled by default in 64-builds.
2. Ports' exp-run issues are fixed (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214864)
3. Fixes for the outstanding bugs ntpd (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253208) and Firefox/Thunderbird (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239873) landed on Friday. Hopefully this will cover all cases that might have remained unknown until now.

Oops, didn't meant to block after the amendment.

Testing this on an RPi4 would be nice, but it's not a dealbreaker.

Now loading with a separate preload type

Changed to use the file_addbuf function — no more modifications to stand/common/module \o/

I created D29550, D29551, D29552 and D29553, which allow us to disable stack gap for ntpd during build.

Update revision after splitting PIE enablement to a separate patch (https://reviews.freebsd.org/D28328)

In D27666#629768, @mw wrote:

In D27666#629538, @emaste wrote:

In D27666#629463, @mw wrote:

Thanks @emaste. Is there any part requiring additional work / contribution? If yes, please reach me out, so we can sync and help with whatever is needed.

Mainly I think we need to make a concerted effort towards identifying ports that require ELF feature tags to opt out of various features, and some common mechanism (either infrastructure or template approach) for setting those bits. I submitted PR252629

As above PR239873 reports issues with firefox and thunderbird with ASLR stack gap. I found libreoffice is incompatible with W^X and submitted PR252689 for that.

WRT ports do you see a better option than enable PIE/ASLR by default, let the community / port maintainers identify problems, create PR's and opt-out this option until fixed?

In D27666#629538, @emaste wrote:

In D27666#629463, @mw wrote:

Thanks @emaste. Is there any part requiring additional work / contribution? If yes, please reach me out, so we can sync and help with whatever is needed.

Mainly I think we need to make a concerted effort towards identifying ports that require ELF feature tags to opt out of various features, and some common mechanism (either infrastructure or template approach) for setting those bits. I submitted PR252629

As above PR239873 reports issues with firefox and thunderbird with ASLR stack gap. I found libreoffice is incompatible with W^X and submitted PR252689 for that.

In D27666#629463, @mw wrote:

Thanks @emaste. Is there any part requiring additional work / contribution? If yes, please reach me out, so we can sync and help with whatever is needed.

In D27666#628869, @emaste wrote:

Related PRs/reviews to check out:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252629
D28139
D28140

Related PRs/reviews to check out:

Hi! Any thoughts? If no objections, I plan to merge the patch after February 5th.

Hi! Any thoughts about the patch? Do you have objections to get it merged?

Any chance that this patch would make it into 13.0 RELEASE?

In D26243#587330, @asomers wrote:

Isn't audit_nfsarg_vnode1 the problem? You already know the path when you call AUDIT_ARG_UPATH1_VP, right?

In D26243#587174, @shivank wrote:

In D26243#587132, @mjg wrote:

Audit support for regular lookup starts with AUDIT_ARG_UPATH1_VP/AUDIT_ARG_UPATH2_VP without any vnodes locked. Later on visited vnodes get added with AUDIT_ARG_VNODE1/AUDIT_ARG_VNODE2 which only performs VOP_GETATTR (i.e. does *NOT* resolve any paths). Your code should follow the same scheme.

As you can see path resolving routines can take vnode locks on their own (modulo the smr case). This means they can't be called with locked vnodes to begin with, as otherwise you risk violating global lock ordering and consequently deadlocking the kernel.

The VOP_ISLOCKED routine is not entirely legal to call if you don't hold the lock. The name is perhaps misleading, but it can only reliably tell you that you have an exclusive lock or that *SOMEONE* has a shared lock (and it may be you). Or to put it differently, if you don't have the vnode locked but someone else has it shared locked, you will get non-0 and that's how you get the panic. Regardless of this problem, adding the call reduces performance and most notably suggests a bug on its own.

So the question is why are you calling here with any vnodes locked.

I wish to audit the canonical path of the file requested by the NFS clients. The requested path from the client is extracted in the NFS server using nfsrv_parsename, but the vnode is locked in some NFS services. I thought of unlocking/relocking of vnode for path audit but Rick advised not to. That's why I had to call this locked vnode.

Thanks for your question which made me rethink the problem from scratch and I got a new idea for auditing path.

Hi @rmacklem and @asomers, if I use nfsvno_namei to get the canonical path for the client, I will not the need the AUDIT_ARG_UPATH1_VP.which will save me from all the trouble of passing locked vnode to vn_fullpath_global. Please provide your opinion on the same.

In D26243#587132, @mjg wrote:

Audit support for regular lookup starts with AUDIT_ARG_UPATH1_VP/AUDIT_ARG_UPATH2_VP without any vnodes locked. Later on visited vnodes get added with AUDIT_ARG_VNODE1/AUDIT_ARG_VNODE2 which only performs VOP_GETATTR (i.e. does *NOT* resolve any paths). Your code should follow the same scheme.

As you can see path resolving routines can take vnode locks on their own (modulo the smr case). This means they can't be called with locked vnodes to begin with, as otherwise you risk violating global lock ordering and consequently deadlocking the kernel.

The VOP_ISLOCKED routine is not entirely legal to call if you don't hold the lock. The name is perhaps misleading, but it can only reliably tell you that you have an exclusive lock or that *SOMEONE* has a shared lock (and it may be you). Or to put it differently, if you don't have the vnode locked but someone else has it shared locked, you will get non-0 and that's how you get the panic. Regardless of this problem, adding the call reduces performance and most notably suggests a bug on its own.

So the question is why are you calling here with any vnodes locked.

Audit support for regular lookup starts with AUDIT_ARG_UPATH1_VP/AUDIT_ARG_UPATH2_VP without any vnodes locked. Later on visited vnodes get added with AUDIT_ARG_VNODE1/AUDIT_ARG_VNODE2 which only performs VOP_GETATTR (i.e. does *NOT* resolve any paths). Your code should follow the same scheme.

I feel vfs_cache.c changes for making vn_fullpath_global work for optionally locked vnode are causing the trouble. Though I'm not sure what's the problem. I request Mateusz Guzik, @mjg to have a look at my vfs_cache.c changes. I would be grateful for your time.

The new code looks better. But grrr, there are two big problems:

1. It doesn't compile due to some recent changes on head. I suggest the following:
   • Remove the <rpc/rpc.h>, <sys/mount.h>, and <fs/nfs/*> includes from audit.h. In addition to fixing the compile failure, it's generally not recommended to include headers from other headers. Sometimes it's necessary, but it also causes header pollution, and slow build times. Instead of including those files, just forward declare struct nfsrv_descript; and struct kaudit_record;.
   • Add `<netinet/in.h>, <rpc/rpc.h>, <fs/nfs/nfsdport.h>, <fs/nfs/nfsproto.h>, and <fs/nfs/nfs.h> to audit_bsm_db.c
   • Add <rpc/rpc.h>, <fs/nfs/nfsport.h>, <fs/nfs/nfsproto.h>, and <fs/nfs/nfs.h> to audit.c

• merge vn_fullpath_any and vn_vptocnp with their locked counterpart to work for optionally locked vnodes.

I created a new review - D26243. Sorry for the trouble.

It was earlier being reviewed on D25869. But due to change of base revision, It was showing changes which were not mine. So, I created a new review here.

In D25869#583083, @shivank wrote:

It looks like your most recent change rebased the base revision. That makes it very hard to see which changes are from you and which aren't. Could you please either un-rebase it or, if that's not possible, open a new review?

Ohh, Sorry! I didn't thought pulling HEAD changes will create this side-effect in revision
I think I would open a new review as going back will have conflicting changes again. Should I abandon this while creating a new one??