[06:04] <mborzecki> morning
[06:07] <mardy> hi mborzecki 
[07:06] <pstolowski> morning
[07:09] <mardy> hi pstolowski 
[07:12] <mborzecki> heya
[07:12] <mborzecki> i'm investigating a curious case of seccomp blocking copy_file_range
[07:12] <mborzecki> copy_file_range takes 6 args, but somehow amtching agains 0 in the last arg, seems to fail?
[07:37] <jamesh> mborzecki: it's weird, I can duplicate it in a test program using the steam runtime's python but not core20's
[07:38] <jamesh> in both cases "snap run --strace" shows the same syscall arguments
[07:44] <mborzecki> jamesh: left some info i collected while investigating this: https://forum.snapcraft.io/t/cannot-write-in-home-directory/24436/24 i'm open to ideas
[07:44] <mborzecki> actually, i wonder why docker-support uses `copy_file_range` without any arguments
[07:44] <mborzecki> perhaps the match didn't work back then too?
[07:44] <jamesh> mborzecki: I ran into this with steam
[07:45] <mborzecki> jamesh: btw. does it break steam? can you patch the profile manually and drop the args match?
[07:46] <jamesh> mborzecki: manually adding copy_file_range (no args at all) to the seccomp source works
[07:47] <mborzecki> let's see if i can get that libseccomp bpf simulator to work
[07:49] <mborzecki> hahah
[07:49] <mborzecki> `./scmp_bpf_sim -f /var/lib/snapd/seccomp/bpf/snap.recollectr.recollectr.bin -s 326 -0 29 -1 123 -2 39 -3 0 -4 10836 -5 0` -> ALLOW
[07:49] <mborzecki> `./scmp_bpf_sim -f /var/lib/snapd/seccomp/bpf/snap.recollectr.recollectr.bin -s 326 -0 29 -1 123 -2 39 -3 0 -4 10836 -5 1` -> ERRNO(1)
[07:50] <mborzecki> heh, yet somehow it fails on a live system
[07:58] <jamesh> mborzecki: I've put down what I know from the Steam snap here: https://forum.snapcraft.io/t/cannot-write-in-home-directory/24436/25?u=jamesh
[07:59] <mborzecki> jamesh: thank you!
[08:00] <mup> PR snapcraft#3737 closed: Main merge <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3737>
[08:05] <mborzecki> is there a way to run something with a seccomp profile? like aa-exec or runcon?
[08:42] <jamesh> mborzecki: I think I know what's going on.
[08:43] <mborzecki> jamesh: please share 🙂
[08:43] <jamesh> mborzecki: the 6th syscall argument is 32-bit, so there's probably garbage in the high 32-bits of the register
[08:43] <jamesh> just posted a reply on the forum
[08:44] <jamesh> I could make my test program work with the steam runtime Python by setting the last argument to ulong instead of uint
[08:44] <jamesh> which basically just ensures it zeroes out the high bits of the register
[08:46] <mborzecki> jamesh: ohh, that's intersting, maybe the seccomp_data is not zeroed in the kernel then?
[08:47] <jamesh> mborzecki: presumably it gets invoked before it knows how the registers are being used
[08:47] <mborzecki> then copy_file_range uses int as the last field, the args in seccomp_data are 8 byte, if that int flag is copied any garbage would remain?
[08:47] <jamesh> yes
[08:48] <mborzecki> jamesh: i think this is where it gets populated https://elixir.bootlin.com/linux/v5.17.5/source/kernel/seccomp.c#L239
[08:49] <mborzecki> the structure that's passed there is on the caller's stack and isn't cleared
[08:50] <jamesh> mborzecki: https://stackoverflow.com/a/2538212/721283 seems to indicate the syscall arguments are passed as 6 64-bit registers
[08:51] <jamesh> so I don't think the high bits are being cleared
[08:52] <mborzecki> jamesh: yeah, man syscall also states that arg1+ are passed in`x86-64        rdi   rsi   rdx   r10   r8    r9` which are all 64bit wide
[08:54] <mup> PR snapd#11759 opened: interfaces: Allow locking in block-devices <Created by stgraber> <https://github.com/snapcore/snapd/pull/11759>
[08:55] <jamesh> mborzecki: there is a seccomp.CompareMaskedEqual operation that could handle this, but would need some extensions to the snap-seccomp language
[08:56] <jamesh> the "|" operator passes the same value twice to CompareMaskedEqual, while here we'd want 0xffffffff and 0
[08:57] <jamesh> this sounds like an actual explanation for what's going on
[09:01] <jamesh> mborzecki: actually, maybe just adding it to syscallsWithNegArgsMaskHi32 will do the trick (even though we're not dealing with negative values here)
[09:50] <jamesh> mborzecki: success by changing syscallsWithNegArgsMaskHi32: https://forum.snapcraft.io/t/cannot-write-in-home-directory/24436/27?u=jamesh
[09:54] <mborzecki> jamesh: fyi, if you want to try it without snaps: https://github.com/seccomp/libseccomp/pull/382
[09:54] <mup> PR seccomp/libseccomp#382: tools: add a tool to run command with a given BPF profile <Created by bboozzoo> <https://github.com/seccomp/libseccomp/pull/382>
[09:55] <jamesh> mborzecki: I just modified snap-seccomp and rebuilt my snap's BPF
[10:00] <mborzecki> jamesh: do you want to open a PR to snap-seccomp?
[10:00] <jamesh> mborzecki: do you think the simple syscallsWithNegArgsMaskHi32 based fix is appropriate, given we're not dealing with signed values?
[10:01] <jamesh> I can open the PR.
[10:02] <mborzecki> jamesh: i'd rather have something more explicit, it's a single argument, and that map is more like a catch all
[10:02] <mborzecki> jamesh: but we can flesh out the details in the PR, i guess pedronis will have some input too
[10:02] <jamesh> mborzecki: they should probably all be per-argument
[10:03] <mborzecki> yeah, maybe something like `i32(value)`
[10:04] <mborzecki> so `copy_file_range - - - - - i32(value)` ? too bad there's no way of knowing what are the sizes of respective arguments without going though manpages
[10:06] <mborzecki> jamesh: our use of `|` is a bit weird
[10:07] <jamesh> mborzecki: we must have seen similar issues with these other syscalls and just assumed it was related to sign extension.
[10:22] <jamesh> PR filed at https://github.com/snapcore/snapd/pull/11760
[10:22] <mup> PR #11760: cmd/snap-seccomp: only compare the bottom 32-bits of the flags arg of copy_file_range <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/11760>
[10:25] <mborzecki> jamesh: thanks, in the meantime i came up with this strawman: https://paste.ubuntu.com/p/N9MDCBRJWj/
[10:25] <mup> PR snapd#9585 closed: interfaces/builtin: Add device-mapper and LVM interfaces <Needs Samuele review> <:birthday:> <Needs security review> <Created by fnordahl> <Closed by fnordahl> <https://github.com/snapcore/snapd/pull/9585>
[10:25] <mup> PR snapd#11760 opened: cmd/snap-seccomp: only compare the bottom 32-bits of the flags arg of copy_file_range <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/11760>
[10:27] <jamesh> mborzecki: I wonder if there are any 16-bit arguments we compare against? :-)
[10:27] <mborzecki> jamesh: oh, please no 🙂
[12:00] <mup> PR snapd#11755 closed: tests/main/user-session-env: remove openSUSE-specific tweaks <Simple 😃> <Created by mardy> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/11755>
[12:41] <mup> PR snapd#11761 opened: image/preseed: umount the base snap last after writable paths <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/11761>
[13:26] <eoli3n> Hi
[13:26] <eoli3n> would you like to check that one please ? https://forum.snapcraft.io/t/cannot-open-path-of-the-current-working-directory-permission-denied-bis/28704
[13:28] <eoli3n> we mount home with NFS4 on /home
[13:29] <eoli3n> then snap packages doesn't work
[13:30] <eoli3n> mborzecki ogra
[13:58] <mborzecki> eoli3n: probably this https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662552
[13:58] <mup> Bug #1662552: snaps don't work with NFS home <snapd:Fix Released by zyga> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1662552>
[14:00] <eoli3n> fixed ?
[17:38] <mardy> eoli3n: hi, can you please paste the output of the "mount" command?
[17:47] <eoli3n> mardy, at home right now, but I'll do it at work tommorow (france)