This bug was fixed in the package libvirt - 6.0.0-0ubuntu7
---
libvirt (6.0.0-0ubuntu7) focal; urgency=medium
* d/p/ubuntu-aa/lp-1871354*: fix apparmor denials on libpmem init
(LP: #1871354)
* d/p/ubuntu/CVE-CVE-2020-10701-api-disallow-virDomainAgentSetResponseTimeout
-on-
** Description changed:
[Impact]
- * Backport the apparmor rules that I upstreamed (have ack of JDstrand)
-to avoid nvdimm nitialization of libpmem (done always even if not used)
-to not spill Denials into the log all the time.
+ * Backport the apparmor rules that I upstreamed (hav
** Description changed:
+ [Impact]
+
+ * Backport the apparmor rules that I upstreamed (have ack of JDstrand)
+to avoid nvdimm nitialization of libpmem (done always even if not used)
+to not spill Denials into the log all the time.
+
+ [Test Case]
+
+ * Start qemu and check apparmor
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/libvirt/+git/libvirt/+merge/382309
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871354
Title:
apparmor denies relat
** Changed in: libvirt (Ubuntu)
Status: New => In Progress
** Changed in: libvirt (Ubuntu)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
** Changed in: libvirt (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubun
Upstream accepted as:
8f61fd6b apparmor: avoid denials on libpmem initialization
Ready to get into Focal
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871354
Title:
apparmor denies related to nv
These days, a lot of file reads from /sys and /proc is wrapped inside
ndctl rather than PMDK, so you'd need to review both. And, a good part
of accesses happen only on true NVDIMMs -- although if I recall
correctly, those are all under /sys/bus/nd/devices. There's also
/sys/devices, /sys/dev/char
FYI, Christian sent up a patch and I responded to it here:
https://www.redhat.com/archives/libvir-list/2020-April/msg00441.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871354
Title:
apparmor
...
[15:28] so adding a deny (btw I can only add to places users can't
modify) they can't allow it later right?
[15:28] cpaelzer: correct
[15:28] so how could I silence access to a given path
[15:28] but have the chance for user to later allow it?
...
[15:31] unfortunately deny is the only wa
If conditional a fix (once we know the paths) would be an extension of these
-
https://libvirt.org/git/?p=libvirt.git;a=commit;h=ac254f342ff59b18792394ce9b01b1c8c2da7e28
-
https://libvirt.org/git/?p=libvirt.git;a=commit;h=98a7920c11a3c8969bba6e32714ea810508c
Adding checks if [1]: is enable
Also adding Jeff:
cpaelzer: try jeff lane
(https://directory.canonical.com/orgchart/Jeff%20Lane/), he was driving the
ipmctl sru and he has nvdimms
Thanks Andreas for the hint
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https:/
libpmem would scan those two:
region0 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/region0/
region1 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/region1/
These faked entries have no "persistence_domain" entry.
I wonder:
- how predictable those path namings a
maybe
/sys/devices/LNXSYSTM:[0-9][0-9]/LNXSYBUS[0-9][0-9]/ACPI*/ndbus[0-9]/region[0-9]
r,
/sys/devices/LNXSYSTM:[0-9][0-9]/LNXSYBUS[0-9][0-9]/ACPI*/ndbus[0-9]/region[0-9]/persistence_domain
r,
But would those paths differ in other cases e.g. with real Hardware?
--
You received this bug n
Wow, this is very different ...
On a qemu system with faked nvdimms I got this:
ubuntu@focal-nvdimm:~$ ll /sys/bus/nd/devices/
total 0
drwxr-xr-x 2 root root 0 Apr 8 12:59 ./
drwxr-xr-x 4 root root 0 Apr 8 12:59 ../
lrwxrwxrwx 1 root root 0 Apr 8 12:59 btt0.0 ->
../../../devices/LNXSYSTM:00/LN
@Adam - I have subscribed you as I know you have worked on pmem. If on
such a system (best with all "kinds" of nvdimm use cases set up) one
could collect the full content of /sys so that I can track down the set
of paths that we will need to allow overall.
--
You received this bug notification be
Useful reference:
/sys/devices/platform/{e820_pmem,nfit_test.*}/region*/persistence_domain r,
But for a fix I'd need to get access to a system with the real thing or
detailed info about one.
Until then people that want to use it should allow it for "their setup" by
adding to:
/etc/apparmor.d/
On init amon other things libpmem will do:
161 /*
162 * os_auto_flush -- check if platform supports auto flush for all regions
163 *
As assumed libpmem init:
break open if strcmp($rdi,".") == 0
Breakpoint 1, __libc_open64 (file=file@entry=0x7734be26 ".",
oflag=oflag@entry=0) at ../sysdeps/unix/sysv/linux/open64.c:37
37 ../sysdeps/unix/sysv/linux/open64.c: No such file or directory.
(gdb) bt
#0 __libc_open64 (file=
It could be triggered right when loading the libpmem lib or similar.
>From strace:
63706 0.28 stat("/sys/bus/nd/devices", {st_mode=S_IFDIR|0755,
st_size=0, ...}) = 0 <0.11>
63706 0.50 stat("/sys/bus/nd/devices", {st_mode=S_IFDIR|0755,
st_size=0, ...}) = 0 <0.09>
63706
Debug approach #1 (Thanks amurray)
handle SIGUSR1 noprint nostop
set follow-fork-mode child
set $outside = 1
catch syscall openat
commands
silent
set $outside = ! $outside
if ($outside && $rax >= 0)
continue
end
if ( !$outside )
continue
end
if ($rax == -1 || $rax == -13)
/sys/bus/nd should be NFIT-ND as described in
https://lwn.net/Articles/640891/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871354
Title:
apparmor denies related to nvdimms/nfit
To manage notific
21 matches
Mail list logo
