* Re: [RFC PATCH v2 22/27] x86/cet/ibt: User-mode indirect branch tracking support
From: Yu-cheng Yu @ 2018-07-11 23:00 UTC (permalink / raw)
To: Dave Hansen, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Andy Lutomirski, Balbir Singh, Cyrill Gorcunov,
Florian Weimer, H.J. Lu, Jann Horn, Jonathan Corbet, Kees Cook,
Mike Kravetz, Nadav Amit, Oleg Nesterov, Pavel Machek
In-Reply-To: <f97ce234-52fa-e666-2250-098925cf3c39@linux.intel.com>
On Wed, 2018-07-11 at 15:40 -0700, Dave Hansen wrote:
> On 07/11/2018 03:10 PM, Yu-cheng Yu wrote:
> >
> > On Tue, 2018-07-10 at 17:11 -0700, Dave Hansen wrote:
> > >
> > > Is this feature *integral* to shadow stacks? Or, should it just
> > > be
> > > in a
> > > different series?
> > The whole CET series is mostly about SHSTK and only a minority for
> > IBT.
> > IBT changes cannot be applied by itself without first applying
> > SHSTK
> > changes. Would the titles help, e.g. x86/cet/ibt, x86/cet/shstk,
> > etc.?
> That doesn't really answer what I asked, though.
>
> Do shadow stacks *require* IBT? Or, should we concentrate on merging
> shadow stacks themselves first and then do IBT at a later time, in a
> different patch series?
>
> But, yes, better patch titles would help, although I'm not sure
> that's
> quite the format that Ingo and Thomas prefer.
Shadow stack does not require IBT, but they complement each other. If
we can resolve the legacy bitmap, both features can be merged at the
same time.
>
> >
> > >
> > > >
> > > > +int cet_setup_ibt_bitmap(void)
> > > > +{
> > > > + u64 r;
> > > > + unsigned long bitmap;
> > > > + unsigned long size;
> > > > +
> > > > + if (!cpu_feature_enabled(X86_FEATURE_IBT))
> > > > + return -EOPNOTSUPP;
> > > > +
> > > > + size = TASK_SIZE_MAX / PAGE_SIZE / BITS_PER_BYTE;
> > > Just a note: this table is going to be gigantic on 5-level paging
> > > systems, and userspace won't, by default use any of that extra
> > > address
> > > space. I think it ends up being a 512GB allocation in a 128TB
> > > address
> > > space.
> > >
> > > Is that a problem?
> > >
> > > On 5-level paging systems, maybe we should just stick it up in
> > > the
> > > high part of the address space.
> > We do not know in advance if dlopen() needs to create the bitmap.
> > Do
> > we always reserve high address or force legacy libs to low address?
> Does it matter? Does code ever get pointers to this area? Might
> they
> be depending on high address bits for the IBT being clear?
GLIBC does the bitmap setup. It sets bits in there.
I thought you wanted a smaller bitmap? One way is forcing legacy libs
to low address, or not having the bitmap at all, i.e. turn IBT off.
>
>
> >
> > >
> > > >
> > > > + bitmap = ibt_mmap(0, size);
> > > > +
> > > > + if (bitmap >= TASK_SIZE_MAX)
> > > > + return -ENOMEM;
> > > > +
> > > > + bitmap &= PAGE_MASK;
> > > We're page-aligning the result of an mmap()? Why?
> > This may not be necessary. The lower bits of MSR_IA32_U_CET are
> > settings and not part of the bitmap address. Is this is safer?
> No. If we have mmap() returning non-page-aligned addresses, we have
> bigger problems. Worst-case, do
>
> WARN_ON_ONCE(bitmap & ~PAGE_MASK);
>
Ok.
> >
> > >
> > > >
> > > > + current->thread.cet.ibt_bitmap_addr = bitmap;
> > > > + current->thread.cet.ibt_bitmap_size = size;
> > > > + return 0;
> > > > +}
> > > > +
> > > > +void cet_disable_ibt(void)
> > > > +{
> > > > + u64 r;
> > > > +
> > > > + if (!cpu_feature_enabled(X86_FEATURE_IBT))
> > > > + return;
> > > Does this need a check for being already disabled?
> > We need that. We cannot write to those MSRs if the CPU does not
> > support it.
> No, I mean for code doing cet_disable_ibt() twice in a row.
Got it.
>
> >
> > >
> > > >
> > > > + rdmsrl(MSR_IA32_U_CET, r);
> > > > + r &= ~(MSR_IA32_CET_ENDBR_EN | MSR_IA32_CET_LEG_IW_EN
> > > > |
> > > > + MSR_IA32_CET_NO_TRACK_EN);
> > > > + wrmsrl(MSR_IA32_U_CET, r);
> > > > + current->thread.cet.ibt_enabled = 0;
> > > > +}
> > > What's the locking for current->thread.cet?
> > Now CET is not locked until the application calls ARCH_CET_LOCK.
> No, I mean what is the in-kernel locking for the current->thread.cet
> data structure? Is there none because it's only every modified via
> current->thread and it's entirely thread-local?
Yes, that is the case.
^ permalink raw reply
* Re: [RFC PATCH v2 22/27] x86/cet/ibt: User-mode indirect branch tracking support
From: Dave Hansen @ 2018-07-11 23:16 UTC (permalink / raw)
To: Yu-cheng Yu, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Andy Lutomirski, Balbir Singh, Cyrill Gorcunov,
Florian Weimer, H.J. Lu, Jann Horn, Jonathan Corbet, Kees Cook,
Mike Kravetz, Nadav Amit, Oleg Nesterov, Pavel Machek,
Peter Zijlstra <pet>
In-Reply-To: <1531350028.15351.102.camel@intel.com>
On 07/11/2018 04:00 PM, Yu-cheng Yu wrote:
> On Wed, 2018-07-11 at 15:40 -0700, Dave Hansen wrote:
>> On 07/11/2018 03:10 PM, Yu-cheng Yu wrote:
>>>
>>> On Tue, 2018-07-10 at 17:11 -0700, Dave Hansen wrote:
>>>>
>>>> Is this feature *integral* to shadow stacks? Or, should it just
>>>> be
>>>> in a
>>>> different series?
>>> The whole CET series is mostly about SHSTK and only a minority for
>>> IBT.
>>> IBT changes cannot be applied by itself without first applying
>>> SHSTK
>>> changes. Would the titles help, e.g. x86/cet/ibt, x86/cet/shstk,
>>> etc.?
>> That doesn't really answer what I asked, though.
>>
>> Do shadow stacks *require* IBT? Or, should we concentrate on merging
>> shadow stacks themselves first and then do IBT at a later time, in a
>> different patch series?
>>
>> But, yes, better patch titles would help, although I'm not sure
>> that's
>> quite the format that Ingo and Thomas prefer.
>
> Shadow stack does not require IBT, but they complement each other. If
> we can resolve the legacy bitmap, both features can be merged at the
> same time.
As large as this patch set is, I'd really prefer to see you get shadow
stacks merged and then move on to IBT. I say separate them.
> GLIBC does the bitmap setup. It sets bits in there.
> I thought you wanted a smaller bitmap? One way is forcing legacy libs
> to low address, or not having the bitmap at all, i.e. turn IBT off.
I'm concerned with two things:
1. the virtual address space consumption, especially the *default* case
which will be apps using 4-level address space amounts, but having
5-level-sized tables.
2. the driving a truck-sized hole in the address space limits
You can force legacy libs to low addresses, but you can't stop anyone
from putting code into a high address *later*, at least with the code we
have today.
>>>>> + rdmsrl(MSR_IA32_U_CET, r);
>>>>> + r &= ~(MSR_IA32_CET_ENDBR_EN | MSR_IA32_CET_LEG_IW_EN
>>>>> |
>>>>> + MSR_IA32_CET_NO_TRACK_EN);
>>>>> + wrmsrl(MSR_IA32_U_CET, r);
>>>>> + current->thread.cet.ibt_enabled = 0;
>>>>> +}
>>>> What's the locking for current->thread.cet?
>>> Now CET is not locked until the application calls ARCH_CET_LOCK.
>> No, I mean what is the in-kernel locking for the current->thread.cet
>> data structure? Is there none because it's only every modified via
>> current->thread and it's entirely thread-local?
>
> Yes, that is the case.
^ permalink raw reply
* Re: [PATCH v3 7/7] timex: change syscalls to use struct __kernel_timex
From: Christoph Hellwig @ 2018-07-12 8:29 UTC (permalink / raw)
To: Deepa Dinamani; +Cc: tglx, linux-kernel, arnd, y2038, linux-api
In-Reply-To: <20180707054247.19802-8-deepa.kernel@gmail.com>
On Fri, Jul 06, 2018 at 10:42:47PM -0700, Deepa Dinamani wrote:
> struct timex is not y2038 safe.
> Switch all the syscall apis to use y2038 safe __kernel_timex.
So you switch existing syscalls to use a different structure.
If this actually happens to be safe it needs a big explanation
in the commit log.
> -#ifdef CONFIG_COMPAT
> -
> COMPAT_SYSCALL_DEFINE2(clock_adjtime, clockid_t, which_clock,
> struct compat_timex __user *, utp)
> {
> @@ -1187,10 +1183,6 @@ COMPAT_SYSCALL_DEFINE2(clock_adjtime, clockid_t, which_clock,
> return err;
> }
>
> -#endif
And this unconditionally defines clock_adjtime, but doesn't actually
seem to add callers, which looks rather odd. Same for other bits
in the patch.
^ permalink raw reply
* Re: [PATCH v16 00/13] support "task_isolation" mode
From: Yury Norov @ 2018-07-12 12:29 UTC (permalink / raw)
To: Chris Metcalf
Cc: Steven Rostedt, Ingo Molnar, Peter Zijlstra, Andrew Morton,
Rik van Riel, Tejun Heo, Frederic Weisbecker, Thomas Gleixner,
Paul E. McKenney, Christoph Lameter, Viresh Kumar,
Catalin Marinas, Will Deacon, Andy Lutomirski, Daniel Lezcano,
Francis Giraldeau, Sunil Goutham, linux-mm, linux-doc, linux-api,
linux-kernel
In-Reply-To: <1509728692-10460-1-git-send-email-cmetcalf@mellanox.com>
On Fri, Nov 03, 2017 at 01:04:39PM -0400, Chris Metcalf wrote:
> Here, finally, is a new spin of the task isolation work (v16), with
> changes based on the issues that were raised at last year's Linux
> Plumbers Conference and in the email discussion that followed.
Hi Chris,
There's another possible way to break task isolation, by net subsystem.
See patch below.
Yury
>From 8025e9330bf06ce146d4ba96833aad6eafe24759 Mon Sep 17 00:00:00 2001
From: Yury Norov <ynorov@caviumnetworks.com>
Date: Sun, 8 Jul 2018 00:40:46 +0300
Subject: [PATCH] net: don't let user assign task isolation CPUs for RPS
Receive Packet Steering (RPS) subsystem distributes network traffic
handling to CPUs defined by user in
/sys/class/net/<dev>/queues/rx-<n>/rps_cpus.
If rps_cpus intersects with task_isolation_map, RPS may break task
isolation by assigning RPS work to CPU that runs isolated task.
In this patch user-provided rps_cpus map filtered to avoid that.
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
---
include/linux/isolation.h | 2 ++
net/core/net-sysfs.c | 13 +++++++++++++
2 files changed, 15 insertions(+)
diff --git a/include/linux/isolation.h b/include/linux/isolation.h
index f467545ad37d..b7f0a9085b13 100644
--- a/include/linux/isolation.h
+++ b/include/linux/isolation.h
@@ -14,6 +14,8 @@ struct task_struct;
#ifdef CONFIG_TASK_ISOLATION
+extern cpumask_var_t task_isolation_map;
+
/**
* task_isolation_request() - prctl hook to request task isolation
* @flags: Flags from <linux/prctl.h> PR_TASK_ISOLATION_xxx.
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 927a6dcbad96..18e576893984 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -11,6 +11,7 @@
#include <linux/capability.h>
#include <linux/kernel.h>
+#include <linux/isolation.h>
#include <linux/netdevice.h>
#include <net/switchdev.h>
#include <linux/if_arp.h>
@@ -727,6 +728,18 @@ static ssize_t store_rps_map(struct netdev_rx_queue *queue,
return err;
}
+#ifdef CONFIG_TASK_ISOLATION
+ if (cpumask_intersects(mask, task_isolation_map)) {
+ char tmp[256];
+
+ pr_warn("RPS is not allowed on CPUs allocated for isolated tasks\n");
+
+ cpumask_andnot(mask, mask, task_isolation_map);
+ cpumap_print_to_pagebuf(1, tmp, mask);
+ pr_warn("RPS CPUs list is reduced to: %s\n", tmp);
+ }
+#endif
+
map = kzalloc(max_t(unsigned int,
RPS_MAP_SIZE(cpumask_weight(mask)), L1_CACHE_BYTES),
GFP_KERNEL);
--
2.17.1
^ permalink raw reply related
* Re: [RFC PATCH v2 25/27] x86/cet: Add PTRACE interface for CET
From: Ingo Molnar @ 2018-07-12 14:03 UTC (permalink / raw)
To: Yu-cheng Yu
Cc: x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, linux-kernel,
linux-doc, linux-mm, linux-arch, linux-api, Arnd Bergmann,
Andy Lutomirski, Balbir Singh, Cyrill Gorcunov, Dave Hansen,
Florian Weimer, H.J. Lu, Jann Horn, Jonathan Corbet, Kees Cook,
Mike Kravetz, Nadav Amit, Oleg Nesterov, Pavel Machek
In-Reply-To: <1531323638.13297.24.camel@intel.com>
* Yu-cheng Yu <yu-cheng.yu@intel.com> wrote:
> > > diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
> > > index e2ee403865eb..ac2bc3a18427 100644
> > > --- a/arch/x86/kernel/ptrace.c
> > > +++ b/arch/x86/kernel/ptrace.c
> > > @@ -49,7 +49,9 @@ enum x86_regset {
> > > REGSET_IOPERM64 = REGSET_XFP,
> > > REGSET_XSTATE,
> > > REGSET_TLS,
> > > + REGSET_CET64 = REGSET_TLS,
> > > REGSET_IOPERM32,
> > > + REGSET_CET32,
> > > };
> > Why does REGSET_CET64 alias on REGSET_TLS?
>
> In x86_64_regsets[], there is no [REGSET_TLS]. The core dump code
> cannot handle holes in the array.
Is there a fundamental (ABI) reason for that?
> > to "CET" (which is a well-known acronym for "Central European Time"),
> > not to CFE?
> >
>
> I don't know if I can change that, will find out.
So what I'd suggest is something pretty simple: to use CFT/cft in kernel internal
names, except for the Intel feature bit and any MSR enumeration which can be CET
if Intel named it that way, and a short comment explaining the acronym difference.
Or something like that.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH v3 7/7] timex: change syscalls to use struct __kernel_timex
From: Arnd Bergmann @ 2018-07-12 14:40 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Deepa Dinamani, Thomas Gleixner, Linux Kernel Mailing List,
y2038 Mailman List, Linux API
In-Reply-To: <20180712082956.GD8802@infradead.org>
On Thu, Jul 12, 2018 at 10:29 AM, Christoph Hellwig <hch@infradead.org> wrote:
> On Fri, Jul 06, 2018 at 10:42:47PM -0700, Deepa Dinamani wrote:
>
>> -#ifdef CONFIG_COMPAT
>> -
>> COMPAT_SYSCALL_DEFINE2(clock_adjtime, clockid_t, which_clock,
>> struct compat_timex __user *, utp)
>> {
>> @@ -1187,10 +1183,6 @@ COMPAT_SYSCALL_DEFINE2(clock_adjtime, clockid_t, which_clock,
>> return err;
>> }
>>
>> -#endif
>
> And this unconditionally defines clock_adjtime, but doesn't actually
> seem to add callers, which looks rather odd. Same for other bits
> in the patch.
It really just moves compat_sys_clock_adjtime() into the same
#ifdef CONFIG_COMPAT_32BIT_TIME that hides the surrounding
functions.
Currently CONFIG_COMPAT_32BIT_TIME is used only as a subset
of CONFIG_COMPAT, and the plan was to have 32-bit architectures
enable it later so they could get access to all the functions
implementing 32-bit time with a patch similar to what I'm testing
with, see https://pastebin.com/F3QZdyin for the current draft that
I use for testing.
We already spent several review rounds coming just discussing the
naming of the macros etc before we decided on the
CONFIG_64BIT_TIME and CONFIG_COMPAT_32BIT_TIME
symbol, but if you have a better suggestion (as part of moving
away from the compat_ naming), we can change all that again.
Arnd
^ permalink raw reply
* Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]
From: David Howells @ 2018-07-12 14:54 UTC (permalink / raw)
To: Andy Lutomirski
Cc: dhowells, Al Viro, Linux API, Linux FS Devel, Linus Torvalds,
LKML, Jann Horn
In-Reply-To: <CALCETrU3kbh-ZRHDj7-Asq+OH-35dQ2p_erpHpYUvN5+BdAoVQ@mail.gmail.com>
Andy Lutomirski <luto@kernel.org> wrote:
> > On Jul 11, 2018, at 12:22 AM, David Howells <dhowells@redhat.com> wrote:
> >
> > Andy Lutomirski <luto@amacapital.net> wrote:
> >
> >>> sfd = fsopen("ext4", FSOPEN_CLOEXEC);
> >>> write(sfd, "s /dev/sdb1"); // note I'm ignoring write's length arg
> >>
> >> Imagine some malicious program passes sfd as stdout to a setuid
> >> program. That program gets persuaded to write "s /etc/shadow". What
> >> happens? You’re okay as long as *every single fs* gets it right, but
> >> that’s asking a lot.
> >
> > Do note that you must already have CAP_SYS_ADMIN to be able to call
> > fsopen().
>
> If you're not allowing it already, someone will want user namespace
> root to be able to use this very, very soon.
Yeah, I'm sure. And I've been thinking on how to deal with it.
I think we *have* to open the source files/devices with the creds of whoever
called fsopen() or fspick() - that way you can't upgrade your privs by passing
your context fd to a suid program. To enforce this, I think it's simplest for
fscontext_write() to call override_creds() right after taking the uapi_mutex
and then call revert_creds() right before dropping the mutex.
Another thing we might want to look at is to allow a supervisory process to
examine the context before permitting the create/reconfigure action to
proceed. It might also be possible to do this through the LSM.
David
^ permalink raw reply
* Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]
From: Linus Torvalds @ 2018-07-12 15:50 UTC (permalink / raw)
To: David Howells
Cc: Andrew Lutomirski, Al Viro, Linux API, linux-fsdevel,
Linux Kernel Mailing List, Jann Horn
In-Reply-To: <7002.1531407244@warthog.procyon.org.uk>
On Thu, Jul 12, 2018 at 7:54 AM David Howells <dhowells@redhat.com> wrote:
>
> I think we *have* to open the source files/devices with the creds of whoever
> called fsopen() or fspick() - that way you can't upgrade your privs by passing
> your context fd to a suid program. To enforce this, I think it's simplest for
> fscontext_write() to call override_creds() right after taking the uapi_mutex
> and then call revert_creds() right before dropping the mutex.
No.
Don't play games with override_creds. It's wrong.
You have to use file->f_creds - no games, no garbage.
But "write()" simply is *NOT* a good "command" interface. If you want
to send a command, use an ioctl or a system call.
Because it's not just about credentials. It's not just about fooling a
suid app into writing an error message to a descriptor you wrote. It's
also about things like "splice()", which can write to your target
using a kernel buffer, and thus trick you into doing a command while
we have the context set to kernel addresses.
Are we trying to get away from that issue? Yes. But it's just another
example of why "write()" IS NOT TO BE USED FOR COMMANDS.
Only use write() for data.
That's final. We're not adding yet another clueless fuck-up of an
interface just because people cannot understand this very simple rule:
"write()" is for data, not for commands.
No more excuses.
Linus
^ permalink raw reply
* Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]
From: Al Viro @ 2018-07-12 16:00 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Howells, Andrew Lutomirski, Linux API, linux-fsdevel,
Linux Kernel Mailing List, Jann Horn
In-Reply-To: <CA+55aFx+xm333ZZ7d2Z39QuhDu=0XM6nTMChbHvWQOXNk32yxw@mail.gmail.com>
On Thu, Jul 12, 2018 at 08:50:46AM -0700, Linus Torvalds wrote:
> But "write()" simply is *NOT* a good "command" interface. If you want
> to send a command, use an ioctl or a system call.
>
> Because it's not just about credentials. It's not just about fooling a
> suid app into writing an error message to a descriptor you wrote. It's
> also about things like "splice()", which can write to your target
> using a kernel buffer, and thus trick you into doing a command while
> we have the context set to kernel addresses.
Wait a sec - that's only a problem if your command contains pointer-chasing
et.al. Which is why e.g. /dev/sg is fucked in head. But for something that
is plain text, what's the problem with splice/write/sendmsg/whatever?
I'm not talking about this particular interface, but "write is bad for
commands" as general policy looks missing the point. If anything, it's
pointer-chasing crap that should be banned everywhere. Just look at SG_IO -
it's a ioctl, and it's absolute garbage...
^ permalink raw reply
* Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]
From: Linus Torvalds @ 2018-07-12 16:07 UTC (permalink / raw)
To: Al Viro
Cc: David Howells, Andrew Lutomirski, Linux API, linux-fsdevel,
Linux Kernel Mailing List, Jann Horn
In-Reply-To: <20180712160030.GV30522@ZenIV.linux.org.uk>
On Thu, Jul 12, 2018 at 9:00 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> Wait a sec - that's only a problem if your command contains pointer-chasing
> et.al.
No.
It's a problem if anybody ever does something like "let's have a
helper splice thread that uses splice to move data automatically from
one buffer to another".
And yes, it's something people have wanted.
Seriously. I'm putting my foot down. NO COMMANDS IN WRITE DATA!
We have made that mistake in the past. Having done stupid things in
the past is not an excuse for doing so again. Quite the reverse.
Making the same mistake and not learning from your mistakes is the
sign of stupidity.
So I repeat: write is for data. If you want an action, you do it with
ioctl, or you do it with a system call.
Linus
^ permalink raw reply
* Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]
From: Andy Lutomirski @ 2018-07-12 16:23 UTC (permalink / raw)
To: David Howells
Cc: Andy Lutomirski, Al Viro, Linux API, Linux FS Devel,
Linus Torvalds, LKML, Jann Horn, tycho
In-Reply-To: <7002.1531407244@warthog.procyon.org.uk>
> On Jul 12, 2018, at 7:54 AM, David Howells <dhowells@redhat.com> wrote:
>
> Andy Lutomirski <luto@kernel.org> wrote:
>
>>> On Jul 11, 2018, at 12:22 AM, David Howells <dhowells@redhat.com> wrote:
>>>
>>> Andy Lutomirski <luto@amacapital.net> wrote:
>>>
>>>>> sfd = fsopen("ext4", FSOPEN_CLOEXEC);
>>>>> write(sfd, "s /dev/sdb1"); // note I'm ignoring write's length arg
>>>>
>>>> Imagine some malicious program passes sfd as stdout to a setuid
>>>> program. That program gets persuaded to write "s /etc/shadow". What
>>>> happens? You’re okay as long as *every single fs* gets it right, but
>>>> that’s asking a lot.
>>>
>>> Do note that you must already have CAP_SYS_ADMIN to be able to call
>>> fsopen().
>>
>> If you're not allowing it already, someone will want user namespace
>> root to be able to use this very, very soon.
>
> Yeah, I'm sure. And I've been thinking on how to deal with it.
>
> I think we *have* to open the source files/devices with the creds of whoever
> called fsopen() or fspick() - that way you can't upgrade your privs by passing
> your context fd to a suid program. To enforce this, I think it's simplest for
> fscontext_write() to call override_creds() right after taking the uapi_mutex
> and then call revert_creds() right before dropping the mutex.
>
If you make a syscall that attaches a block device to an fscontext, you don’t need any of this. Heck, someone might actually *want* to grab a block device from a different namespace.
All this override_creds() stuff is maybe okay if we were fixing an old broken thing. But this is brand new. And having write() call override_creds() and do nontrivial things is a fascinating attack surface.
Just imagine what blows up if I abuse fscontext to open a block device on a path that traverses an AFS mount or /proc/.../fd or similar. Or if I splice() from a network filesystem into fscontext.
(Al- can’t we just stop allowing splice() at all on things that don’t use iov_iter?)
> Another thing we might want to look at is to allow a supervisory process to
> examine the context before permitting the create/reconfigure action to
> proceed. It might also be possible to do this through the LSM.
Cc Tycho. He’s working on this exact idea using seccomp. And he’d probably much, much prefer if configuration of an fscontext didn’t use a performance-critical syscall like write().
As a straw man, I suggest:
fsconfigure(contextfd, ADD_BLOCKDEV, dfd, path, flags);
fsconfigure(contextfd, ADD_OPTION, 0, “foo=bar”, flags);
Etc.
^ permalink raw reply
* Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]
From: Al Viro @ 2018-07-12 16:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Howells, Andrew Lutomirski, Linux API, linux-fsdevel,
Linux Kernel Mailing List, Jann Horn
In-Reply-To: <CA+55aFwkiFdhGmT8gaSohAQGMWpGUZBQ0dhGNGWEN4cpjK7XHA@mail.gmail.com>
On Thu, Jul 12, 2018 at 09:07:36AM -0700, Linus Torvalds wrote:
> On Thu, Jul 12, 2018 at 9:00 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > Wait a sec - that's only a problem if your command contains pointer-chasing
> > et.al.
>
> No.
>
> It's a problem if anybody ever does something like "let's have a
> helper splice thread that uses splice to move data automatically from
> one buffer to another".
>
> And yes, it's something people have wanted.
>
> Seriously. I'm putting my foot down. NO COMMANDS IN WRITE DATA!
>
> We have made that mistake in the past. Having done stupid things in
> the past is not an excuse for doing so again. Quite the reverse.
> Making the same mistake and not learning from your mistakes is the
> sign of stupidity.
>
> So I repeat: write is for data. If you want an action, you do it with
> ioctl, or you do it with a system call.
*shrug*
I think you are wrong[1], but it's your decision. And seriously, ioctl?
_That_ has a great track record...
[1] one man's data is another man's commands, for starters. All networking
protocols would fit your description. So would ANSI escape sequences ("move
cursor to line 12 column 45" does sound like a command), so would writing
postscript to printer, etc.
IME it's more about data structures that are not marshalled cleanly - that
tends to go badly wrong. Again, see SG_IO for recent example...
Anyway, your tree, your policy.
^ permalink raw reply
* Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]
From: Linus Torvalds @ 2018-07-12 16:31 UTC (permalink / raw)
To: Andy Lutomirski
Cc: David Howells, Andrew Lutomirski, Al Viro, Linux API,
linux-fsdevel, Linux Kernel Mailing List, Jann Horn,
Tycho Andersen
In-Reply-To: <338BC3C4-F3E7-48F0-A82E-2C7295B6640E@amacapital.net>
On Thu, Jul 12, 2018 at 9:23 AM Andy Lutomirski <luto@amacapital.net> wrote:
>
> (Al- can’t we just stop allowing splice() at all on things that don’t use iov_iter?)
We could add a FMODE_SPLICE_READ/WRITE bit, and let people opt in to
splice. We probably should have.
But again, that really doesn't change the fundamentals. Using write()
for commands is stupid.
It also means that you have to _parse_ all the damn input at that
level, which is a mistake too. It easily leads to insane decisions
like "you have to use 'write()' calls without buffering", because
re-buffering the stream is a f*cking pain.
Just say no. Seriously. Stop this idiotic discussion.
I'm just happy this came up early, because that way I know to look out
for it and not merge it.
Linus
^ permalink raw reply
* Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]
From: Linus Torvalds @ 2018-07-12 16:39 UTC (permalink / raw)
To: Al Viro
Cc: David Howells, Andrew Lutomirski, Linux API, linux-fsdevel,
Linux Kernel Mailing List, Jann Horn
In-Reply-To: <20180712163107.GW30522@ZenIV.linux.org.uk>
On Thu, Jul 12, 2018 at 9:31 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> And seriously, ioctl? _That_ has a great track record...
I agree that a system call is likely saner. Especially since we'd have
one to _start_ this (ie "fsopen()") it would make sense to have the
one to finalize it.
> [1] one man's data is another man's commands, for starters. All networking
> protocols would fit your description. So would ANSI escape sequences ("move
> cursor to line 12 column 45" does sound like a command), so would writing
> postscript to printer, etc.
.. and all of that is just data to the kernel.
Yes, vt100 escape sequences etc _are_ commands, and boy have we had
bugs in that area. But there the excuse is "that's how the world is".
The thing is, "reality" is the ultimate argument. You can't argue with
cold hard facts.
But when designing a new interface that doesn't have that kind of
constraints, do it right.
> IME it's more about data structures that are not marshalled cleanly - that
> tends to go badly wrong. Again, see SG_IO for recent example...
SG_IO actually gets it right. It doesn't do async, but that's part of
the design (and a big part of why it's a lot simpler - the read-write
thing is actually broken too and just forces user space to basically
know SCSI).
Linus
^ permalink raw reply
* Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]
From: Al Viro @ 2018-07-12 16:41 UTC (permalink / raw)
To: Andy Lutomirski
Cc: David Howells, Andy Lutomirski, Linux API, Linux FS Devel,
Linus Torvalds, LKML, Jann Horn, tycho
In-Reply-To: <338BC3C4-F3E7-48F0-A82E-2C7295B6640E@amacapital.net>
On Thu, Jul 12, 2018 at 09:23:22AM -0700, Andy Lutomirski wrote:
> If you make a syscall that attaches a block device to an fscontext, you don’t need any of this. Heck, someone might actually *want* to grab a block device from a different namespace.
Fuck, NO. The whole notion of "block device of filesystem" is fucking
garbage. It's up to filesystem driver whether it uses any block
devices. For backing store or otherwise. Single or multiple. Moreover,
it's up to filesystem driver whether it cares if backing store is
a block device, or mtd device, or...
Repeat after me: syscall that attaches a block device to an fscontext
makes as much sense as a syscall that attaches a charset name to the
same. With a special syscall for attaching a timestamp granularity,
and another for selecting GID semantics on subdirectory creation.
Commit vs. write separation is one thing; fuckloads of special syscalls
for passing vaguely defined classes of mount options (which device
name *is*) is quite different.
^ permalink raw reply
* Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]
From: Al Viro @ 2018-07-12 16:58 UTC (permalink / raw)
To: Andy Lutomirski
Cc: David Howells, Andy Lutomirski, Linux API, Linux FS Devel,
Linus Torvalds, LKML, Jann Horn, tycho
In-Reply-To: <338BC3C4-F3E7-48F0-A82E-2C7295B6640E@amacapital.net>
On Thu, Jul 12, 2018 at 09:23:22AM -0700, Andy Lutomirski wrote:
> As a straw man, I suggest:
>
> fsconfigure(contextfd, ADD_BLOCKDEV, dfd, path, flags);
>
> fsconfigure(contextfd, ADD_OPTION, 0, “foo=bar”, flags);
Bollocks. First of all, block device *IS* a fucking option.
Always had been. It's not even that it's passed as a separate
argument for historical reasons - just look at NFS. That argument
is a detached part of options, parsed (yes, *parsed*) by filesystem
in question in whatever way it prefers.
Look at the things like e.g. cramfs. That argument is interpreted
as pathname of block device. Or that of mtd device. Or the magic
string "mtd" followed by mtd number.
What's more, filesystems can and do live on more than one device.
Like e.g. btrfs. Or like something journalled with the journal
on separate device. So you do *NOT* get away from the need to
open stuff while doing mount - not unless you introduce arseloads
of ADD_... shite in your scheme. And create a huge centralized
pile of code dealing with it. ADD_NFS_IPV4_SERVER_AND_PATH, etc.?
You can't avoid parsing stuff. It's one thing to argue at which
*point* you prefer doing that, but it has to be done kernel-side.
Format of filesystem options is fundamentally up to filesystem,
whichever syscall you use.
^ permalink raw reply
* Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]
From: Linus Torvalds @ 2018-07-12 17:14 UTC (permalink / raw)
To: Al Viro
Cc: David Howells, Andrew Lutomirski, Linux API, linux-fsdevel,
Linux Kernel Mailing List, Jann Horn
In-Reply-To: <CA+55aFz6Uaqag5qPcT2M3Q07-yc_6y2cAarfw7hjXEiQq4tTYw@mail.gmail.com>
On Thu, Jul 12, 2018 at 9:39 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> I agree that a system call is likely saner. Especially since we'd have
> one to _start_ this (ie "fsopen()") it would make sense to have the
> one to finalize it.
Side note: if we can make do with just a buffer, then we wouldn't need
"fsopen()". You could literally just open a pipe, and write to it.
It's got 16 pages worth of buffers by default, and you can increase it
(within reason) as root.
Of course, depending on IO patterns, not all the buffer pages are
necessarily fully used, so it's not like you get a buffer of size
PAGE_SIZE*16, but we do merge buffers so you should be fairly close.
Then you really could do without a fsopen(). Just fill a pipe with
data, and do "fsmount()" on the pipe contents.
Added upside? You can use "iov_iter_pipe()" to iterate over all that data.
I'm only half joking.
Linus
^ permalink raw reply
* Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]
From: Greg KH @ 2018-07-12 17:15 UTC (permalink / raw)
To: David Howells; +Cc: viro, linux-api, linux-fsdevel, torvalds, linux-kernel
In-Reply-To: <153126264966.14533.3388004240803696769.stgit@warthog.procyon.org.uk>
On Tue, Jul 10, 2018 at 11:44:09PM +0100, David Howells wrote:
> Provide an fsopen() system call that starts the process of preparing to
> create a superblock that will then be mountable, using an fd as a context
> handle. fsopen() is given the name of the filesystem that will be used:
>
> int mfd = fsopen(const char *fsname, unsigned int flags);
>
> where flags can be 0 or FSOPEN_CLOEXEC.
>
> For example:
>
> sfd = fsopen("ext4", FSOPEN_CLOEXEC);
> write(sfd, "s /dev/sdb1"); // note I'm ignoring write's length arg
> write(sfd, "o noatime");
> write(sfd, "o acl");
> write(sfd, "o user_attr");
> write(sfd, "o iversion");
> write(sfd, "o ");
> write(sfd, "r /my/container"); // root inside the fs
> write(sfd, "x create"); // create the superblock
Ugh, creating configfs again in a syscall form? I know people love
file descriptors, but can't you do this with a configfs entry instead if
you really want to do this type of thing from userspace in this type of
"style"?
Why reinvent the wheel again?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]
From: Al Viro @ 2018-07-12 17:20 UTC (permalink / raw)
To: Greg KH; +Cc: David Howells, linux-api, linux-fsdevel, torvalds, linux-kernel
In-Reply-To: <20180712171505.GA23780@kroah.com>
On Thu, Jul 12, 2018 at 07:15:05PM +0200, Greg KH wrote:
> On Tue, Jul 10, 2018 at 11:44:09PM +0100, David Howells wrote:
> > Provide an fsopen() system call that starts the process of preparing to
> > create a superblock that will then be mountable, using an fd as a context
> > handle. fsopen() is given the name of the filesystem that will be used:
> >
> > int mfd = fsopen(const char *fsname, unsigned int flags);
> >
> > where flags can be 0 or FSOPEN_CLOEXEC.
> >
> > For example:
> >
> > sfd = fsopen("ext4", FSOPEN_CLOEXEC);
> > write(sfd, "s /dev/sdb1"); // note I'm ignoring write's length arg
> > write(sfd, "o noatime");
> > write(sfd, "o acl");
> > write(sfd, "o user_attr");
> > write(sfd, "o iversion");
> > write(sfd, "o ");
> > write(sfd, "r /my/container"); // root inside the fs
> > write(sfd, "x create"); // create the superblock
>
> Ugh, creating configfs again in a syscall form? I know people love
> file descriptors, but can't you do this with a configfs entry instead if
> you really want to do this type of thing from userspace in this type of
> "style"?
>
> Why reinvent the wheel again?
The damn thing REALLY, REALLY depends upon the fs type. How would
you map it on configfs?
^ permalink raw reply
* Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]
From: Al Viro @ 2018-07-12 17:44 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Howells, Andrew Lutomirski, Linux API, linux-fsdevel,
Linux Kernel Mailing List, Jann Horn
In-Reply-To: <CA+55aFw9WuyGqRHerhESw+Shzg1UtCjORLVYT=uCMh8jXbLWmg@mail.gmail.com>
On Thu, Jul 12, 2018 at 10:14:05AM -0700, Linus Torvalds wrote:
> On Thu, Jul 12, 2018 at 9:39 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > I agree that a system call is likely saner. Especially since we'd have
> > one to _start_ this (ie "fsopen()") it would make sense to have the
> > one to finalize it.
>
> Side note: if we can make do with just a buffer, then we wouldn't need
> "fsopen()". You could literally just open a pipe, and write to it.
> It's got 16 pages worth of buffers by default, and you can increase it
> (within reason) as root.
>
> Of course, depending on IO patterns, not all the buffer pages are
> necessarily fully used, so it's not like you get a buffer of size
> PAGE_SIZE*16, but we do merge buffers so you should be fairly close.
>
> Then you really could do without a fsopen(). Just fill a pipe with
> data, and do "fsmount()" on the pipe contents.
>
> Added upside? You can use "iov_iter_pipe()" to iterate over all that data.
>
> I'm only half joking.
One semi-historical note here.
Originally, mount(2) (and it had been there since v1) had only one filesystem
type to deal with. So it was really just "mount <block device pathname> on
<mountpoint pathname>, read-only or read-write". 3 arguments, two strings and
one flag (flag, BTW, was a later addition).
It didn't last. I can dig out the archaeological notes and cut'n'paste the
whole horror story here, but that'll be way too long and scary.
By 4.2BSD times there had been essentially an enum encoding the filesystem
type and type-tagged union of structs with type-dependent options. Plus
some options taking more bits in what used to be "is it r/w?" flag.
Leaving aside the whole "mount new/bind/remount/etc." overloading we have
in mount(2) today, we have a bunch of named filesystems, each with its
own set of options. Device name has ceased to be something special for
many decades; the type name is what's universally present and that's what
decides how the rest (including "device name") is to be interpreted.
Fundamentally, we start with selecting (by name) a filesystem driver we'll
be talking to. The rest (device name + string options + flags like noexec
that are not handled on VFS level) is given to that driver, which either
tells us to take a hike or gives us a dentry tree that can be attached.
Separating type name from everything else makes a lot of sense, simply
because it's what determines the parsing and interpretation of the rest.
Speaking of half-joking, I suggested AF_FSTYPE at some point. Then
fsopen(2) would be connect(2)...
I think that having that (connection used to talk to fs driver, with or
without an already set up fs instance we are talking about) as first-class
object makes sense. That's completely unrelated to the question of buffering,
of course.
^ permalink raw reply
* Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]
From: Al Viro @ 2018-07-12 17:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Howells, Andrew Lutomirski, Linux API, linux-fsdevel,
Linux Kernel Mailing List, Jann Horn
In-Reply-To: <CA+55aFz6Uaqag5qPcT2M3Q07-yc_6y2cAarfw7hjXEiQq4tTYw@mail.gmail.com>
On Thu, Jul 12, 2018 at 09:39:31AM -0700, Linus Torvalds wrote:
> > [1] one man's data is another man's commands, for starters. All networking
> > protocols would fit your description. So would ANSI escape sequences ("move
> > cursor to line 12 column 45" does sound like a command), so would writing
> > postscript to printer, etc.
>
> .. and all of that is just data to the kernel.
>
> Yes, vt100 escape sequences etc _are_ commands, and boy have we had
> bugs in that area. But there the excuse is "that's how the world is".
... along with "something similar to ncurses-based programs usable over
ssh is a good thing to have, without having said ssh somehow intercept
and marshal ioctls" ;-) I can just imagine something e.g. RDMA people
would've designed instead... OTOH, I'm eating right now, so better
not go there...
^ permalink raw reply
* Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]
From: Linus Torvalds @ 2018-07-12 17:54 UTC (permalink / raw)
To: Al Viro
Cc: David Howells, Andrew Lutomirski, Linux API, linux-fsdevel,
Linux Kernel Mailing List, Jann Horn
In-Reply-To: <20180712174403.GA30522@ZenIV.linux.org.uk>
On Thu, Jul 12, 2018 at 10:44 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> Separating type name from everything else makes a lot of sense
I do not dispute that at all.
But you can specify the type name in the "commit" phase, it doesn't
have to be at "fsopen" time.
In fact, doing so would _force_ a certain cleanliness to the
interfaces - it would force the rest to be filesystem-agnostic, rather
than possibly have semantic hacks for some part.
Linus
^ permalink raw reply
* Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]
From: Andy Lutomirski @ 2018-07-12 17:54 UTC (permalink / raw)
To: Al Viro
Cc: David Howells, Andy Lutomirski, Linux API, Linux FS Devel,
Linus Torvalds, LKML, Jann Horn, tycho
In-Reply-To: <20180712165821.GY30522@ZenIV.linux.org.uk>
> On Jul 12, 2018, at 9:58 AM, Al Viro <viro@ZenIV.linux.org.uk> wrote:
>
>> On Thu, Jul 12, 2018 at 09:23:22AM -0700, Andy Lutomirski wrote:
>>
>> As a straw man, I suggest:
>>
>> fsconfigure(contextfd, ADD_BLOCKDEV, dfd, path, flags);
>>
>> fsconfigure(contextfd, ADD_OPTION, 0, “foo=bar”, flags);
>
> Bollocks. First of all, block device *IS* a fucking option.
> Always had been. It's not even that it's passed as a separate
> argument for historical reasons - just look at NFS. That argument
> is a detached part of options, parsed (yes, *parsed*) by filesystem
> in question in whatever way it prefers.
Fine, then generalize it. fsconfigure(context, ADD_FD, “some fs-specific string explaining what’s going on”, fd); The point being that there are tons of cases where the filesystem wants to identify some backing store by some device node, and it seems like we should support something along the lines of a modern *at interface.
If I’m writing a daemon that deals with filesystems, I don’t want an API that looks like do_god_knows_what(context, “filesystem specific string that may contain a path to a device node or a network address”). That API will be a pain to use, since that opaque string may come from some random config file and I have no clue what it does. If I want to pass a device node or other object to a filesystem, I want to pass an fd (so I can use openat, SCM_CREDS, etc), and I want it to be crystal clear that I’m passing some object in. And if I tell a filesystem to access the network, I want it to be entirely clear which network namespace is in use.
I realize that doing this right is tricky when there are lots of legacy filesystems that parse opaque strings. That’s fine. We can convert things slowly.
^ permalink raw reply
* Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]
From: Greg KH @ 2018-07-12 18:03 UTC (permalink / raw)
To: Al Viro; +Cc: David Howells, linux-api, linux-fsdevel, torvalds, linux-kernel
In-Reply-To: <20180712172024.GZ30522@ZenIV.linux.org.uk>
On Thu, Jul 12, 2018 at 06:20:24PM +0100, Al Viro wrote:
> On Thu, Jul 12, 2018 at 07:15:05PM +0200, Greg KH wrote:
> > On Tue, Jul 10, 2018 at 11:44:09PM +0100, David Howells wrote:
> > > Provide an fsopen() system call that starts the process of preparing to
> > > create a superblock that will then be mountable, using an fd as a context
> > > handle. fsopen() is given the name of the filesystem that will be used:
> > >
> > > int mfd = fsopen(const char *fsname, unsigned int flags);
> > >
> > > where flags can be 0 or FSOPEN_CLOEXEC.
> > >
> > > For example:
> > >
> > > sfd = fsopen("ext4", FSOPEN_CLOEXEC);
> > > write(sfd, "s /dev/sdb1"); // note I'm ignoring write's length arg
> > > write(sfd, "o noatime");
> > > write(sfd, "o acl");
> > > write(sfd, "o user_attr");
> > > write(sfd, "o iversion");
> > > write(sfd, "o ");
> > > write(sfd, "r /my/container"); // root inside the fs
> > > write(sfd, "x create"); // create the superblock
> >
> > Ugh, creating configfs again in a syscall form? I know people love
> > file descriptors, but can't you do this with a configfs entry instead if
> > you really want to do this type of thing from userspace in this type of
> > "style"?
> >
> > Why reinvent the wheel again?
>
> The damn thing REALLY, REALLY depends upon the fs type. How would
> you map it on configfs?
/sys/kernel/config/fs/ext4/ would work, right? Each fs "type" would be
listed there.
Anyway, the whole "write a bunch of options and then do a 'create'" is
exactly the way configfs works. Why not use that?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]
From: Andy Lutomirski @ 2018-07-12 18:30 UTC (permalink / raw)
To: Greg KH
Cc: Al Viro, David Howells, linux-api, linux-fsdevel, torvalds,
linux-kernel
In-Reply-To: <20180712180304.GA27758@kroah.com>
> On Jul 12, 2018, at 11:03 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>
>> On Thu, Jul 12, 2018 at 06:20:24PM +0100, Al Viro wrote:
>>> On Thu, Jul 12, 2018 at 07:15:05PM +0200, Greg KH wrote:
>>>> On Tue, Jul 10, 2018 at 11:44:09PM +0100, David Howells wrote:
>>>> Provide an fsopen() system call that starts the process of preparing to
>>>> create a superblock that will then be mountable, using an fd as a context
>>>> handle. fsopen() is given the name of the filesystem that will be used:
>>>>
>>>> int mfd = fsopen(const char *fsname, unsigned int flags);
>>>>
>>>> where flags can be 0 or FSOPEN_CLOEXEC.
>>>>
>>>> For example:
>>>>
>>>> sfd = fsopen("ext4", FSOPEN_CLOEXEC);
>>>> write(sfd, "s /dev/sdb1"); // note I'm ignoring write's length arg
>>>> write(sfd, "o noatime");
>>>> write(sfd, "o acl");
>>>> write(sfd, "o user_attr");
>>>> write(sfd, "o iversion");
>>>> write(sfd, "o ");
>>>> write(sfd, "r /my/container"); // root inside the fs
>>>> write(sfd, "x create"); // create the superblock
>>>
>>> Ugh, creating configfs again in a syscall form? I know people love
>>> file descriptors, but can't you do this with a configfs entry instead if
>>> you really want to do this type of thing from userspace in this type of
>>> "style"?
>>>
>>> Why reinvent the wheel again?
>>
>> The damn thing REALLY, REALLY depends upon the fs type. How would
>> you map it on configfs?
>
> /sys/kernel/config/fs/ext4/ would work, right? Each fs "type" would be
> listed there.
>
> Anyway, the whole "write a bunch of options and then do a 'create'" is
> exactly the way configfs works. Why not use that?
>
>
How do you mount configfs in the first place? And how do you use this in a mount namespace without a private configfs instance or where you don’t want configfs mounted?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox