Page MenuHomeFreeBSD
Feed Advanced Search

Mar 29 2022

firk_cantconnect.ru added a comment to D34579: Verify directory fds against chroot when receiving them through SCM_RIGHTS.

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

Mar 29 2022, 2:34 PM · network, Jails, security
mjg added a comment to D34579: Verify directory fds against chroot when receiving them through SCM_RIGHTS.

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.

Mar 29 2022, 12:46 PM · network, Jails, security

Mar 28 2022

firk_cantconnect.ru updated subscribers of D34579: Verify directory fds against chroot when receiving them through SCM_RIGHTS.
Mar 28 2022, 9:48 PM · network, Jails, security

Mar 16 2022

firk_cantconnect.ru updated the test plan for D34579: Verify directory fds against chroot when receiving them through SCM_RIGHTS.
Mar 16 2022, 6:59 PM · network, Jails, security
firk_cantconnect.ru requested review of D34579: Verify directory fds against chroot when receiving them through SCM_RIGHTS.
Mar 16 2022, 10:28 AM · network, Jails, security

Mar 15 2022

firk_cantconnect.ru retitled D34560: Add mount option to disallow creating sockets on filesystem from Add mount option to disallow creating socketson filesystem to Add mount option to disallow creating sockets on filesystem.
Mar 15 2022, 12:25 AM · security, network, Jails

Mar 14 2022

firk_cantconnect.ru requested review of D34560: Add mount option to disallow creating sockets on filesystem.
Mar 14 2022, 11:28 PM · security, network, Jails

Feb 17 2022

cperciva closed D20780: Add support for getting early entropy from the UEFI RNG protocol.
Feb 17 2022, 9:12 PM · csprng, security, arm64
cperciva added a comment to D20780: Add support for getting early entropy from the UEFI RNG protocol.

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

Feb 17 2022, 9:11 PM · csprng, security, arm64

Feb 16 2022

markm added a comment to D20780: Add support for getting early entropy from the UEFI RNG protocol.

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.

Feb 16 2022, 6:16 PM · csprng, security, arm64
kevans accepted D20780: Add support for getting early entropy from the UEFI RNG protocol.

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

Feb 16 2022, 1:09 AM · csprng, security, arm64
kevans added inline comments to D20780: Add support for getting early entropy from the UEFI RNG protocol.
Feb 16 2022, 1:08 AM · csprng, security, arm64
cperciva added a comment to D20780: Add support for getting early entropy from the UEFI RNG protocol.

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.

Feb 16 2022, 12:50 AM · csprng, security, arm64

Jan 29 2022

markm accepted D20780: Add support for getting early entropy from the UEFI RNG protocol.
Jan 29 2022, 10:17 AM · csprng, security, arm64

Jan 28 2022

markm added inline comments to D20780: Add support for getting early entropy from the UEFI RNG protocol.
Jan 28 2022, 6:05 PM · csprng, security, arm64
greg_unrelenting.technology updated the diff for D20780: Add support for getting early entropy from the UEFI RNG protocol.

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

Jan 28 2022, 11:59 AM · csprng, security, arm64

Jan 27 2022

delphij accepted D20780: Add support for getting early entropy from the UEFI RNG protocol.
Jan 27 2022, 5:52 PM · csprng, security, arm64
markm added inline comments to D20780: Add support for getting early entropy from the UEFI RNG protocol.
Jan 27 2022, 5:42 PM · csprng, security, arm64

Jan 26 2022

greg_unrelenting.technology updated the diff for D20780: Add support for getting early entropy from the UEFI RNG protocol.

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

Jan 26 2022, 9:31 PM · csprng, security, arm64

Jan 17 2022

markm added a comment to D20780: Add support for getting early entropy from the UEFI RNG protocol.

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

Jan 17 2022, 8:42 AM · csprng, security, arm64

Jan 16 2022

greg_unrelenting.technology added a comment to D20780: Add support for getting early entropy from the UEFI RNG protocol.

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

Jan 16 2022, 1:24 PM · csprng, security, arm64

Jan 15 2022

cperciva added a comment to D20780: Add support for getting early entropy from the UEFI RNG protocol.

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

Jan 15 2022, 5:48 PM · csprng, security, arm64
markm added a comment to D20780: Add support for getting early entropy from the UEFI RNG protocol.

Is this waiting for anything else before it gets committed?

Jan 15 2022, 9:30 AM · csprng, security, arm64

Jan 14 2022

Herald added a reviewer for D20780: Add support for getting early entropy from the UEFI RNG protocol: manu.

Is this waiting for anything else before it gets committed?

Jan 14 2022, 10:14 PM · csprng, security, arm64

Nov 16 2021

mw closed D27666: Enable ASLR by default for 64-bit executables..
Nov 16 2021, 10:27 PM · PowerPC, security, arm64

Nov 15 2021

mw updated the summary of D27666: Enable ASLR by default for 64-bit executables..
Nov 15 2021, 8:26 PM · PowerPC, security, arm64
mw updated the summary of D27666: Enable ASLR by default for 64-bit executables..
Nov 15 2021, 8:26 PM · PowerPC, security, arm64
emaste accepted D27666: Enable ASLR by default for 64-bit executables..
Nov 15 2021, 7:12 PM · PowerPC, security, arm64
emaste added a comment to D27666: Enable ASLR by default for 64-bit executables..

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

Nov 15 2021, 7:12 PM · PowerPC, security, arm64
kib accepted D27666: Enable ASLR by default for 64-bit executables..
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".

Nov 15 2021, 5:33 PM · PowerPC, security, arm64
mw added a comment to D27666: Enable ASLR by default for 64-bit executables..
In D27666#744977, @kib 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.

Nov 15 2021, 4:21 PM · PowerPC, security, arm64
kib added a comment to D27666: Enable ASLR by default for 64-bit executables..

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).

Nov 15 2021, 3:53 PM · PowerPC, security, arm64
mw added a comment to D27666: Enable ASLR by default for 64-bit executables..

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).

Nov 15 2021, 3:17 PM · PowerPC, security, arm64
mw updated the summary of D27666: Enable ASLR by default for 64-bit executables..
Nov 15 2021, 3:17 PM · PowerPC, security, arm64
emaste added a comment to D27666: Enable ASLR by default for 64-bit executables..

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.

Nov 15 2021, 3:10 PM · PowerPC, security, arm64
mw added a comment to D27666: Enable ASLR by default for 64-bit executables..
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.

Nov 15 2021, 2:53 PM · PowerPC, security, arm64
mw updated the summary of D27666: Enable ASLR by default for 64-bit executables..
Nov 15 2021, 2:52 PM · PowerPC, security, arm64
kib added a comment to D27666: Enable ASLR by default for 64-bit executables..

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

Nov 15 2021, 2:15 PM · PowerPC, security, arm64
mw added a comment to D27666: Enable ASLR by default for 64-bit executables..
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.

Nov 15 2021, 2:12 PM · PowerPC, security, arm64
kib added a comment to D27666: Enable ASLR by default for 64-bit executables..

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.

Nov 15 2021, 1:44 PM · PowerPC, security, arm64
mw updated the summary of D27666: Enable ASLR by default for 64-bit executables..
Nov 15 2021, 10:47 AM · PowerPC, security, arm64

Nov 12 2021

kib added a comment to D27666: Enable ASLR by default for 64-bit executables..

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
Nov 12 2021, 7:50 PM · PowerPC, security, arm64
mw updated the summary of D27666: Enable ASLR by default for 64-bit executables..
Nov 12 2021, 7:28 PM · PowerPC, security, arm64

Nov 4 2021

mw updated the diff for D27666: Enable ASLR by default for 64-bit executables..

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

Nov 4 2021, 3:42 PM · PowerPC, security, arm64

Nov 2 2021

mw added inline comments to D27666: Enable ASLR by default for 64-bit executables..
Nov 2 2021, 5:18 PM · PowerPC, security, arm64
dgr_semihalf.com added inline comments to D27666: Enable ASLR by default for 64-bit executables..
Nov 2 2021, 4:06 PM · PowerPC, security, arm64

Oct 29 2021

mw added a comment to D27666: Enable ASLR by default for 64-bit executables..

Hi! Any comments/remarks to the updated version?

Oct 29 2021, 9:33 AM · PowerPC, security, arm64

Oct 25 2021

mw added inline comments to D27666: Enable ASLR by default for 64-bit executables..
Oct 25 2021, 2:09 AM · PowerPC, security, arm64
mw updated the diff for D27666: Enable ASLR by default for 64-bit executables..
Oct 25 2021, 2:05 AM · PowerPC, security, arm64

Oct 23 2021

imp added inline comments to D27666: Enable ASLR by default for 64-bit executables..
Oct 23 2021, 1:11 AM · PowerPC, security, arm64

Oct 22 2021

emaste added inline comments to D27666: Enable ASLR by default for 64-bit executables..
Oct 22 2021, 11:22 PM · PowerPC, security, arm64

Oct 18 2021

mw added a comment to D27666: Enable ASLR by default for 64-bit executables..
In D27666#734443, @mw wrote:

Hi,

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

  1. 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.

Oct 18 2021, 1:55 PM · PowerPC, security, arm64
lattera-gmail.com added a comment to D27666: Enable ASLR by default for 64-bit executables..
In D27666#734443, @mw wrote:

Hi,

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

  1. 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.
Oct 18 2021, 12:09 PM · PowerPC, security, arm64
mw added a comment to D27666: Enable ASLR by default for 64-bit executables..

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.
Oct 18 2021, 11:36 AM · PowerPC, security, arm64

Sep 19 2021

kevans added inline comments to D20780: Add support for getting early entropy from the UEFI RNG protocol.
Sep 19 2021, 3:13 AM · csprng, security, arm64

Sep 17 2021

merv_soundabstractions.io added a watcher for security: merv_soundabstractions.io.
Sep 17 2021, 3:48 PM

Sep 6 2021

delphij accepted D20780: Add support for getting early entropy from the UEFI RNG protocol.

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

Sep 6 2021, 12:58 AM · csprng, security, arm64

Jul 27 2021

imp added inline comments to D20780: Add support for getting early entropy from the UEFI RNG protocol.
Jul 27 2021, 9:02 PM · csprng, security, arm64
greg_unrelenting.technology added inline comments to D20780: Add support for getting early entropy from the UEFI RNG protocol.
Jul 27 2021, 8:30 PM · csprng, security, arm64
imp added inline comments to D20780: Add support for getting early entropy from the UEFI RNG protocol.
Jul 27 2021, 7:42 PM · csprng, security, arm64
markm accepted D20780: Add support for getting early entropy from the UEFI RNG protocol.

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

Jul 27 2021, 7:29 PM · csprng, security, arm64
markm added a project to D20780: Add support for getting early entropy from the UEFI RNG protocol: csprng.
Jul 27 2021, 7:28 PM · csprng, security, arm64
markm added a reviewer for D20780: Add support for getting early entropy from the UEFI RNG protocol: csprng.
Jul 27 2021, 7:26 PM · csprng, security, arm64
greg_unrelenting.technology updated the diff for D20780: Add support for getting early entropy from the UEFI RNG protocol.

Now loading with a separate preload type

Jul 27 2021, 12:15 PM · csprng, security, arm64
greg_unrelenting.technology added inline comments to D20780: Add support for getting early entropy from the UEFI RNG protocol.
Jul 27 2021, 11:36 AM · csprng, security, arm64
markm added inline comments to D20780: Add support for getting early entropy from the UEFI RNG protocol.
Jul 27 2021, 7:26 AM · csprng, security, arm64

Jul 26 2021

cperciva added inline comments to D20780: Add support for getting early entropy from the UEFI RNG protocol.
Jul 26 2021, 7:38 PM · csprng, security, arm64
greg_unrelenting.technology updated the diff for D20780: Add support for getting early entropy from the UEFI RNG protocol.

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

Jul 26 2021, 6:44 PM · csprng, security, arm64

May 1 2021

d.oriented_gmail.com added a member for security: d.oriented_gmail.com.
May 1 2021, 10:16 PM

Apr 2 2021

dgr_semihalf.com added a comment to D27666: Enable ASLR by default for 64-bit executables..

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

Apr 2 2021, 2:14 PM · PowerPC, security, arm64

Jan 25 2021

mw updated the summary of D27666: Enable ASLR by default for 64-bit executables..
Jan 25 2021, 9:54 AM · PowerPC, security, arm64
mw updated the diff for D27666: Enable ASLR by default for 64-bit executables..

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

Jan 25 2021, 9:54 AM · PowerPC, security, arm64

Jan 15 2021

kbowling added a comment to D27666: Enable ASLR by default for 64-bit executables..
In D27666#629768, @mw 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?

Jan 15 2021, 6:40 PM · PowerPC, security, arm64
mw added a comment to D27666: Enable ASLR by default for 64-bit executables..
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.

Jan 15 2021, 6:06 PM · PowerPC, security, arm64
emaste added inline comments to D27666: Enable ASLR by default for 64-bit executables..
Jan 15 2021, 5:54 PM · PowerPC, security, arm64
mw added inline comments to D27666: Enable ASLR by default for 64-bit executables..
Jan 15 2021, 5:31 PM · PowerPC, security, arm64
emaste added inline comments to D27666: Enable ASLR by default for 64-bit executables..
Jan 15 2021, 2:52 PM · PowerPC, security, arm64

Jan 14 2021

emaste added a comment to D27666: Enable ASLR by default for 64-bit executables..
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.

Jan 14 2021, 9:55 PM · PowerPC, security, arm64
mw added a comment to D27666: Enable ASLR by default for 64-bit executables..
Jan 14 2021, 7:42 PM · PowerPC, security, arm64

Jan 13 2021

emaste added a comment to D27666: Enable ASLR by default for 64-bit executables..

Related PRs/reviews to check out:

Jan 13 2021, 7:29 PM · PowerPC, security, arm64
mw added a comment to D27666: Enable ASLR by default for 64-bit executables..

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

Jan 13 2021, 10:06 AM · PowerPC, security, arm64

Dec 29 2020

mw added a comment to D27666: Enable ASLR by default for 64-bit executables..

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

Dec 29 2020, 1:17 PM · PowerPC, security, arm64

Dec 24 2020

mw added inline comments to D27666: Enable ASLR by default for 64-bit executables..
Dec 24 2020, 7:32 AM · PowerPC, security, arm64

Dec 18 2020

greg_unrelenting.technology added inline comments to D27666: Enable ASLR by default for 64-bit executables..
Dec 18 2020, 4:37 PM · PowerPC, security, arm64
mw requested review of D27666: Enable ASLR by default for 64-bit executables..
Dec 18 2020, 4:51 AM · PowerPC, security, arm64

Nov 16 2020

tommi.pernila_iki.fi added a comment to D15713: Bug 182518 - [login.conf] Better Password Hashes .

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

Nov 16 2020, 1:41 PM · security

Nov 6 2020

nick added a member for security: nick.
Nov 6 2020, 10:49 PM

Sep 12 2020

shivank added a comment to D26243: Add audit(4) support to NFS(v3).

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

Sep 12 2020, 7:43 AM · security, GSoC Students, Audit

Sep 11 2020

asomers added a comment to D26243: Add audit(4) support to NFS(v3).
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.

Sep 11 2020, 11:11 PM · security, GSoC Students, Audit
shivank added a comment to D26243: Add audit(4) support to NFS(v3).
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.

Sep 11 2020, 11:10 AM · security, GSoC Students, Audit
shivank added a reviewer for D26243: Add audit(4) support to NFS(v3): mjg.
Sep 11 2020, 4:45 AM · security, GSoC Students, Audit
mjg added a comment to D26243: Add audit(4) support to NFS(v3).

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.

Sep 11 2020, 12:40 AM · security, GSoC Students, Audit

Sep 10 2020

shivank updated subscribers of D26243: Add audit(4) support to NFS(v3).

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.

Sep 10 2020, 3:05 PM · security, GSoC Students, Audit

Sep 7 2020

asomers requested changes to D26243: Add audit(4) support to NFS(v3).

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
Sep 7 2020, 5:30 PM · security, GSoC Students, Audit
shivank updated the diff for D26243: Add audit(4) support to NFS(v3).
  • merge vn_fullpath_any and vn_vptocnp with their locked counterpart to work for optionally locked vnodes.
Sep 7 2020, 10:52 AM · security, GSoC Students, Audit

Sep 6 2020

asomers added inline comments to D26243: Add audit(4) support to NFS(v3).
Sep 6 2020, 9:05 PM · security, GSoC Students, Audit

Aug 31 2020

shivank abandoned D25869: Add audit(4) support to NFS(v3).

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

Aug 31 2020, 5:06 AM · security, GSoC Students, Audit
shivank added a comment to D26243: Add audit(4) support to NFS(v3).

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.

Aug 31 2020, 5:03 AM · security, GSoC Students, Audit
shivank requested review of D26243: Add audit(4) support to NFS(v3).
Aug 31 2020, 4:57 AM · security, GSoC Students, Audit

Aug 30 2020

asomers added a comment to D25869: Add audit(4) support to NFS(v3).

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??

Aug 30 2020, 8:58 PM · security, GSoC Students, Audit