* Re: Continuing the UAPI split
From: Szabolcs Nagy @ 2019-11-07 16:21 UTC (permalink / raw)
To: Elichai Turkel, Florian Weimer
Cc: nd, Christian Brauner, linux-api@vger.kernel.org, libc-alpha
In-Reply-To: <CALN7hCJ_umFqC1L0T19CuiGiGoVwac5807NDw4LiDqSD-VJL=Q@mail.gmail.com>
On 07/11/2019 13:03, Elichai Turkel wrote:
> A rename to the structs/types so they won't collide with libc?
> Prioritizing POSIX conformance in the kernel(I think that ship has long sailed)?
hosted c code can only use linux api headers reliably
if those respect the iso c and posix rules.
linux should maintain a clean set of c headers (or
interface descriptions from which such headers can be
generated).
providing clean headers that work in both hosted and
freestanding environments is not trivial: e.g. the
former requires type definitions to use libc types,
the latter requires type definitions that don't depend
on the libc.
e.g. a possible approach is to use iso c implementation
reserved namespace for all linux api identifiers, so
it's entirely independent of libc and non-conflicting,
then libc headers can replicate declarations that it
wants to expose (with different names and libc types).
(there are other ways, but the current headers are hard
to use which affects a lot of users)
> Or just giving up and telling users they can't just directly include
> both libc headers and kernel headers?
including both libc and linux headers is fragile and
will break differently across the different linux
libc implementations.
^ permalink raw reply
* Re: [pipe] d60337eff1: phoronix-test-suite.noise-level.0.activity_level 144.0% improvement
From: Linus Torvalds @ 2019-11-07 16:51 UTC (permalink / raw)
To: lkp report check
Cc: David Howells, Rasmus Villemoes, Greg Kroah-Hartman,
Peter Zijlstra, Nicolas Dichtel, raven, Christian Brauner,
keyrings, linux-usb, linux-block, LSM List, linux-fsdevel,
Linux API, Linux Kernel Mailing List, lkp
In-Reply-To: <20191107090306.GV29418@shao2-debian>
On Thu, Nov 7, 2019 at 1:03 AM lkp report check <rong.a.chen@intel.com> wrote:
>
> FYI, we noticed a 144.0% improvement of phoronix-test-suite.noise-level.0.activity_level due to commit:
>
> commit: d60337eff18a3c587832ab8053a567f1da9710d2 ("[RFC PATCH 04/11] pipe: Use head and tail pointers for the ring, not cursor and length [ver #3]")
That sounds nice, but is odd. That commit really shouldn't change
anything noticeable. David, any idea?
Linus
^ permalink raw reply
* Re: [RFC PATCH 05/14] pipe: Add general notification queue support [ver #2]
From: David Howells @ 2019-11-07 17:16 UTC (permalink / raw)
To: torvalds
Cc: dhowells, Greg Kroah-Hartman, Casey Schaufler, Stephen Smalley,
nicolas.dichtel, raven, Christian Brauner, keyrings, linux-usb,
linux-block, linux-security-module, linux-fsdevel, linux-api,
linux-kernel
In-Reply-To: <157313376558.29677.12389078014886241663.stgit@warthog.procyon.org.uk>
Sigh. I forgot to build it with the new config options disabled. I've fixed
that up and pushed it to the git tree.
David
^ permalink raw reply
* Re: [pipe] d60337eff1: phoronix-test-suite.noise-level.0.activity_level 144.0% improvement
From: David Howells @ 2019-11-07 17:42 UTC (permalink / raw)
To: Linus Torvalds
Cc: dhowells, lkp report check, Rasmus Villemoes, Greg Kroah-Hartman,
Peter Zijlstra, Nicolas Dichtel, raven, Christian Brauner,
keyrings, linux-usb, linux-block, LSM List, linux-fsdevel,
Linux API, Linux Kernel Mailing List, lkp
In-Reply-To: <CAHk-=wiJ+jaT5Ev-wCg7iGNNO_JFUyMDcat0KDdA2b_+n_cZCQ@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > FYI, we noticed a 144.0% improvement of phoronix-test-suite.noise-level.0.activity_level due to commit:
> >
> > commit: d60337eff18a3c587832ab8053a567f1da9710d2 ("[RFC PATCH 04/11] pipe: Use head and tail pointers for the ring, not cursor and length [ver #3]")
>
> That sounds nice, but is odd. That commit really shouldn't change
> anything noticeable. David, any idea?
Yeah, it does sound odd - the only thing that springs particularly to mind is
that maybe it's an effect of one of the preceding patches that affects the
waitqueue stuff.
TBH, I'm not sure what the Phoronix test suite is actually testing from the
report. "noise-level-1.1.0" seems more a reporting script than an actual
test.
David
^ permalink raw reply
* Re: Continuing the UAPI split
From: Carlos O'Donell @ 2019-11-07 18:02 UTC (permalink / raw)
To: Florian Weimer, Elichai Turkel; +Cc: Christian Brauner, linux-api, libc-alpha
In-Reply-To: <87zhh7hlbl.fsf@oldenburg2.str.redhat.com>
On 11/7/19 8:23 AM, Florian Weimer wrote:
> Officially, it's supposed to work today. We have one glibc developer
> who says that it's easy to solve, but I disagree strongly. The fact
> that the problems are not fixed promptly suggests that it's anything but
> simple.
Is that one glibc developer me? :-)
They aren't easy to solve, but there is a magic process in place.
Getting the definitions to line up is part of the work involved.
Sometimes they may not line up, in that case it doesn't work.
> What I've been doing instead is to include UAPI headers directly from
> glibc headers if it's technically feasible. (It's not possible in POSIX
> mode, where we have to manage the set of exported symbols closely, or
> generally with old compilers which do not have __has_include.) See
> <bits/statx.h>, <bits/statx-generic.h> etc. in current glibc for an
> example.
That's really the best way to solve it if you can.
> If you add more type definitions to kernel headers, this might interfere
> with such usage of UAPI headers because today, we need to provide our
> own definitions for many things not in UAPI headers, and the currently
> deployed glibc headers are simply not compatible with such future
> changes.
Right.
--
Cheers,
Carlos.
^ permalink raw reply
* Re: Continuing the UAPI split
From: Carlos O'Donell @ 2019-11-07 18:05 UTC (permalink / raw)
To: Szabolcs Nagy, Elichai Turkel, Florian Weimer
Cc: nd, Christian Brauner, linux-api@vger.kernel.org, libc-alpha
In-Reply-To: <facb4d0d-4e20-41f0-4c01-b210c677c24c@arm.com>
On 11/7/19 11:21 AM, Szabolcs Nagy wrote:
>> Or just giving up and telling users they can't just directly include
>> both libc headers and kernel headers?
>
> including both libc and linux headers is fragile and
> will break differently across the different linux
> libc implementations.
We saw this all the time working in embedded.
There ends up being a rather tight version coupling that
happens, and that's unfortunate, but a function of cost.
Fixing this so it works in the various cases is costly.
--
Cheers,
Carlos.
^ permalink raw reply
* Re: [RFC PATCH 08/14] pipe: Allow buffers to be marked read-whole-or-error for notifications [ver #2]
From: Andy Lutomirski @ 2019-11-07 18:15 UTC (permalink / raw)
To: David Howells
Cc: Linus Torvalds, Greg Kroah-Hartman, Casey Schaufler,
Stephen Smalley, Nicolas Dichtel, raven, Christian Brauner,
keyrings, USB list, linux-block, LSM List, Linux FS Devel,
Linux API, LKML
In-Reply-To: <157313379331.29677.5209561321495531328.stgit@warthog.procyon.org.uk>
On Thu, Nov 7, 2019 at 5:39 AM David Howells <dhowells@redhat.com> wrote:
>
> Allow a buffer to be marked such that read() must return the entire buffer
> in one go or return ENOBUFS. Multiple buffers can be amalgamated into a
> single read, but a short read will occur if the next "whole" buffer won't
> fit.
>
> This is useful for watch queue notifications to make sure we don't split a
> notification across multiple reads, especially given that we need to
> fabricate an overrun record under some circumstances - and that isn't in
> the buffers.
Hmm. I'm not totally in love with introducing a new error code like
this for read(), especially if it could affect the kind of pipe that
is bound to a file in a filesystem. But maybe it's not a problem.
^ permalink raw reply
* Re: [RFC PATCH 04/14] pipe: Add O_NOTIFICATION_PIPE [ver #2]
From: Andy Lutomirski @ 2019-11-07 18:16 UTC (permalink / raw)
To: David Howells
Cc: Linus Torvalds, Greg Kroah-Hartman, Casey Schaufler,
Stephen Smalley, Nicolas Dichtel, raven, Christian Brauner,
keyrings, USB list, linux-block, LSM List, Linux FS Devel,
Linux API, LKML
In-Reply-To: <157313375678.29677.15875689548927466028.stgit@warthog.procyon.org.uk>
On Thu, Nov 7, 2019 at 5:39 AM David Howells <dhowells@redhat.com> wrote:
>
> Add an O_NOTIFICATION_PIPE flag that can be passed to pipe2() to indicate
> that the pipe being created is going to be used for notifications. This
> suppresses the use of splice(), vmsplice(), tee() and sendfile() on the
> pipe as calling iov_iter_revert() on a pipe when a kernel notification
> message has been inserted into the middle of a multi-buffer splice will be
> messy.
How messy? And is there some way to make it impossible for this to
happen? Adding a new flag to pipe2() to avoid messy kernel code seems
like a poor tradeoff.
^ permalink raw reply
* Re: [PATCH 1/1] userfaultfd: require CAP_SYS_PTRACE for UFFD_FEATURE_EVENT_FORK
From: Andrea Arcangeli @ 2019-11-07 18:22 UTC (permalink / raw)
To: Daniel Colascione
Cc: Mike Rapoport, Andy Lutomirski, linux-kernel, Andrew Morton,
Jann Horn, Linus Torvalds, Lokesh Gidra, Nick Kralevich,
Nosh Minwalla, Pavel Emelyanov, Tim Murray, Linux API, linux-mm
In-Reply-To: <CAKOZueuKttjyRBgMkaBknzn+fzufZA+gJcd5wnKgiwmO37yN1g@mail.gmail.com>
On Thu, Nov 07, 2019 at 08:15:53AM -0800, Daniel Colascione wrote:
> You're already paying for bounds checking. Receiving a message via a
> datagram socket is basically the same thing as what UFFD's read is
> doing anyway.
Except it's synchronous and there are no dynamic allocations required
in uffd, while af_netlink and af_unix both all deal with queue of
events in skbs dynamically allocated.
Ultimately if we strip away the skbs for performance reasons, there
wouldn't be much code to share, so if the only benefit would be to
call recvmsg which would still be as insecure as read for the "worse"
case than suid, so I don't see the point.
And should then eventfd also become a netlink then? I mean uffd was
supposed to work like eventfd except it requires specialized events.
> Programs generally don't go calling recvmsg() on random FDs they get
> from the outside world. They do call read() on those FDs, which is why
That programs generally don't do something only means the attack is
less probable.
Programs generally aren't suid. Programs generally don't use
SCM_RIGHTS. Programs generally don't ignore the retval of
open/socket/uffd syscalls. Programs generally don't make assumptions
on the fd ID after one of those syscalls that install fds.
If all programs generally do the right thing (where the most important
is to not make assumptions on the fd IDs and to check all syscall
retvals), there was never an issue to begin with even in uffd API.
> read() having unexpected side effects is terrible.
If having unexpected side effects in read is "terrible" (i.e. I
personally prefer to use terms like terrible when there's at least
something that can be exploited in practice, not for theoretical
issues) for an SCM_RIGHTS receiving daemon, I just don't see how the
exact same unexpected (still theoretical) side effects in recvmsg with
an unexpected nested cmsg->cmsg_type == SCM_RIGHTS message being
returned, isn't terrible too.
> If you call it with a non-empty ancillary data buffer, you know to
> react to what you get. You're *opting into* the possibility of getting
> file descriptors. Sure, it's theoretically possible that a program
> calls recvmsg on random FDs it gets from unknown sources, sees
> SCM_RIGHTS unexpectedly, and just the SCM_RIGHTS message and its FD
> payload, but that's an outright bug, while calling read() on stdin is
> no bug.
I'm not talking about stdin and suid. recvmsg might mitigate the
concern for suid (not certain, depends on the suid, if it's generally
doing what you expect most suid to be doing or not), I was talking
about the SCM_RIGHTS receiving daemon instead, the "worse" more
concerning case than the suid.
I quote below Andy's relevant email:
======
It's worse if SCM_RIGHTS is involved.
======
Not all software will do this after calling recvmsg:
if (cmsg->cmsg_type == SCM_RIGHTS) {
/* oops we got attacked and an fd was involountarily installed
because we received another AF_UNIX from a malicious attacker
in control of the other end of the SCM_RIGHTS-receiving
AF_UNIX connection instead of our expected socket family
which doesn't even support SCM_RIGHTS so we would never have
noticed an fd was installed after recvmsg */
}
^ permalink raw reply
* Re: [RFC PATCH 08/14] pipe: Allow buffers to be marked read-whole-or-error for notifications [ver #2]
From: David Howells @ 2019-11-07 18:23 UTC (permalink / raw)
To: Andy Lutomirski
Cc: dhowells, Linus Torvalds, Greg Kroah-Hartman, Casey Schaufler,
Stephen Smalley, Nicolas Dichtel, raven, Christian Brauner,
keyrings, USB list, linux-block, LSM List, Linux FS Devel,
Linux API, LKML
In-Reply-To: <CALCETrWszYm9=-WEgSbhmGc3DYCvY6q3W4Lezm6YtKnGtRs_5g@mail.gmail.com>
Andy Lutomirski <luto@kernel.org> wrote:
> > Allow a buffer to be marked such that read() must return the entire buffer
> > in one go or return ENOBUFS. Multiple buffers can be amalgamated into a
> > single read, but a short read will occur if the next "whole" buffer won't
> > fit.
> >
> > This is useful for watch queue notifications to make sure we don't split a
> > notification across multiple reads, especially given that we need to
> > fabricate an overrun record under some circumstances - and that isn't in
> > the buffers.
>
> Hmm. I'm not totally in love with introducing a new error code like
> this for read(), especially if it could affect the kind of pipe that
> is bound to a file in a filesystem. But maybe it's not a problem.
EMSGSIZE might be better?
David
^ permalink raw reply
* Re: [RFC PATCH 04/14] pipe: Add O_NOTIFICATION_PIPE [ver #2]
From: David Howells @ 2019-11-07 18:48 UTC (permalink / raw)
To: Andy Lutomirski
Cc: dhowells, Linus Torvalds, Greg Kroah-Hartman, Casey Schaufler,
Stephen Smalley, Nicolas Dichtel, raven, Christian Brauner,
keyrings, USB list, linux-block, LSM List, Linux FS Devel,
Linux API, LKML
In-Reply-To: <CALCETrUka9KaOKFbNKUXcA6XvoFxiXPftctSHtN4DL35Cay61w@mail.gmail.com>
Andy Lutomirski <luto@kernel.org> wrote:
> > Add an O_NOTIFICATION_PIPE flag that can be passed to pipe2() to indicate
> > that the pipe being created is going to be used for notifications. This
> > suppresses the use of splice(), vmsplice(), tee() and sendfile() on the
> > pipe as calling iov_iter_revert() on a pipe when a kernel notification
> > message has been inserted into the middle of a multi-buffer splice will be
> > messy.
>
> How messy?
Well, iov_iter_revert() on a pipe iterator simply walks backwards along the
ring discarding the last N contiguous slots (where N is normally the number of
slots that were filled by whatever operation is being reverted).
However, unless the code that transfers stuff into the pipe takes the spinlock
spinlock and disables softirqs for the duration of its ring filling, what were
N contiguous slots may now have kernel notifications interspersed - even if it
has been holding the pipe mutex.
So, now what do you do? You have to free up just the buffers relevant to the
iterator and then you can either compact down the ring to free up the space or
you can leave null slots and let the read side clean them up, thereby
reducing the capacity of the pipe temporarily.
Either way, iov_iter_revert() gets more complex and has to hold the spinlock.
And if you don't take the spinlock whilst you're reverting, more notifications
can come in to make your life more interesting.
There's also a problem with splicing out from a notification pipe that the
messages are scribed onto preallocated buffers, but now the buffers need
refcounts and, in any case, are of limited quantity.
> And is there some way to make it impossible for this to happen?
Yes. That's what I'm doing by declaring the pipe to be unspliceable up front.
> Adding a new flag to pipe2() to avoid messy kernel code seems
> like a poor tradeoff.
By far the easiest place to check whether a pipe can be spliced to is in
get_pipe_info(). That's checking the file anyway. After that, you can't make
the check until the pipe is locked.
Furthermore, if it's not done upfront, the change to the pipe might happen
during a splicing operation that's residing in pipe_wait()... which drops the
pipe mutex.
David
^ permalink raw reply
* Re: [PATCH 1/1] userfaultfd: require CAP_SYS_PTRACE for UFFD_FEATURE_EVENT_FORK
From: Daniel Colascione @ 2019-11-07 18:50 UTC (permalink / raw)
To: Andrea Arcangeli
Cc: Mike Rapoport, Andy Lutomirski, linux-kernel, Andrew Morton,
Jann Horn, Linus Torvalds, Lokesh Gidra, Nick Kralevich,
Nosh Minwalla, Pavel Emelyanov, Tim Murray, Linux API, linux-mm
In-Reply-To: <20191107182259.GK17896@redhat.com>
On Thu, Nov 7, 2019 at 10:23 AM Andrea Arcangeli <aarcange@redhat.com> wrote:
>
> On Thu, Nov 07, 2019 at 08:15:53AM -0800, Daniel Colascione wrote:
> > You're already paying for bounds checking. Receiving a message via a
> > datagram socket is basically the same thing as what UFFD's read is
> > doing anyway.
>
> Except it's synchronous and there are no dynamic allocations required
> in uffd, while af_netlink and af_unix both all deal with queue of
> events in skbs dynamically allocated.
Do you have any evidence that skb allocation is a significant cost
compared to a page fault and schedule? Regardless: if you don't want
to use skbs, don't. My point is that recvmsg is the ideal interface
for UFFD and i'm agnostic on the implementation of this interface.
> And should then eventfd also become a netlink then? I mean uffd was
> supposed to work like eventfd except it requires specialized events.
You've raised eventfd as a model for UFFD on several occasions. I
don't think eventfd is a good reference point. An eventfd is a single
object with 64 bits of state. It can notify interested parties in
changes to that state. Eventfd does not provide a queue. UFFD,
however, *is* a queue. It provides an arbitrary number of state change
notifications to a reader. In this way, UFFD is much more like a
socket than it's like eventfd. That is, eventfd is about level-change
notifications, but UFFD is about sending messages.
> > Programs generally don't go calling recvmsg() on random FDs they get
> > from the outside world. They do call read() on those FDs, which is why
>
> That programs generally don't do something only means the attack is
> less probable.
>
> Programs generally aren't suid. Programs generally don't use
> SCM_RIGHTS. Programs generally don't ignore the retval of
> open/socket/uffd syscalls. Programs generally don't make assumptions
> on the fd ID after one of those syscalls that install fds.
>
> If all programs generally do the right thing (where the most important
> is to not make assumptions on the fd IDs and to check all syscall
> retvals), there was never an issue to begin with even in uffd API.
"The right thing" is a matter of contracts. If a program calls read()
and behaves as if read() has only the effects read() is documented to
have, that means that from the kernel's point of view, the program is
doing the right thing. That you think certain practices are more
prudent than others is irrelevant here. UFFD is a violation of
read()'s *contract* and so if programs break after calling read(),
it's the *kernel*'s fault.
> > read() having unexpected side effects is terrible.
>
> If having unexpected side effects in read is "terrible" (i.e. I
> personally prefer to use terms like terrible when there's at least
> something that can be exploited in practice, not for theoretical
> issues) for an SCM_RIGHTS receiving daemon, I just don't see how the
> exact same unexpected (still theoretical) side effects in recvmsg with
> an unexpected nested cmsg->cmsg_type == SCM_RIGHTS message being
> returned, isn't terrible too.
If a program calls recvmsg on an FD of unknown provenance, it *must*
be prepared to receive file descriptors via SCM_RIGHTS. If it doesn't,
it's a bug. The contract the kernel makes with userspace for recvmsg()
includes the possibility of creating file descriptors. The contract
the kernel makes with userspace for read() does not ordinarily involve
creating file descriptors, so if the kernel does in fact do that, it's
the kernel's problem.
> > If you call it with a non-empty ancillary data buffer, you know to
> > react to what you get. You're *opting into* the possibility of getting
> > file descriptors. Sure, it's theoretically possible that a program
> > calls recvmsg on random FDs it gets from unknown sources, sees
> > SCM_RIGHTS unexpectedly, and just the SCM_RIGHTS message and its FD
> > payload, but that's an outright bug, while calling read() on stdin is
> > no bug.
>
> I'm not talking about stdin and suid. recvmsg might mitigate the
> concern for suid (not certain, depends on the suid, if it's generally
> doing what you expect most suid to be doing or not), I was talking
> about the SCM_RIGHTS receiving daemon instead, the "worse" more
> concerning case than the suid.
>
> I quote below Andy's relevant email:
>
> ======
> It's worse if SCM_RIGHTS is involved.
> ======
>
> Not all software will do this after calling recvmsg:
>
> if (cmsg->cmsg_type == SCM_RIGHTS) {
> /* oops we got attacked and an fd was involountarily installed
> because we received another AF_UNIX from a malicious attacker
> in control of the other end of the SCM_RIGHTS-receiving
> AF_UNIX connection instead of our expected socket family
> which doesn't even support SCM_RIGHTS so we would never have
> noticed an fd was installed after recvmsg */
> }
If a program omits this code after calling recvmsg on a file
descriptor of unknown provenance and the program breaks, it's the
program's fault. It's reasonable to epect that recvmsg might create
file descriptors if you call it on an unknown FD. It's unreasonable to
expect a program to consider the possibility of read() creating file
descriptors because read isn't documented to do that.
>
^ permalink raw reply
* Re: [PATCH 1/1] userfaultfd: require CAP_SYS_PTRACE for UFFD_FEATURE_EVENT_FORK
From: Andrea Arcangeli @ 2019-11-07 19:27 UTC (permalink / raw)
To: Daniel Colascione
Cc: Mike Rapoport, Andy Lutomirski, linux-kernel, Andrew Morton,
Jann Horn, Linus Torvalds, Lokesh Gidra, Nick Kralevich,
Nosh Minwalla, Pavel Emelyanov, Tim Murray, Linux API, linux-mm
In-Reply-To: <CAKOZueubtyuTZC5zPTL3qDpVS5RFYFMqx727Bj4fjMHDSY5rMg@mail.gmail.com>
On Thu, Nov 07, 2019 at 10:50:26AM -0800, Daniel Colascione wrote:
> On Thu, Nov 7, 2019 at 10:23 AM Andrea Arcangeli <aarcange@redhat.com> wrote:
> > Not all software will do this after calling recvmsg:
> >
> > if (cmsg->cmsg_type == SCM_RIGHTS) {
> > /* oops we got attacked and an fd was involountarily installed
> > because we received another AF_UNIX from a malicious attacker
> > in control of the other end of the SCM_RIGHTS-receiving
> > AF_UNIX connection instead of our expected socket family
> > which doesn't even support SCM_RIGHTS so we would never have
> > noticed an fd was installed after recvmsg */
> > }
>
> If a program omits this code after calling recvmsg on a file
> descriptor of unknown provenance and the program breaks, it's the
> program's fault. [..]
Hmm, ok, would it be possible to do a research effort and check how
much software that receives an fd through SCM_RIGHTS and then calls
recvmsg on it, always remembers to follow the recvsmg with a if
(cmsg->cmsg_type == SCM_RIGHTS) path that closes the involuntarily
opened fd?
Frankly until today, I didn't realize that not adding a specialized
"cmsg->cmsg_type == SCM_RIGHTS" check after every recvmsg executed on
any fd received with SCM_RIGHTS, was a program's fault and it made the
program vulnerable (non robust) from an attack from the other end of
the AF_UNIX pipe just like if the program issued a read() with uffd
event fork being sent through SCM_RIGHTS (except in that case it
wasn't program's fault because read had not to install the fd while
recvmsg can always install fd if cmsg_type == SCM_RIGHTS is returned).
The main argument in favor of recvmsg would be that even if we use it
for uffd too, it won't make recvmsg on an fd received from SCM_RIGHTS
any less secure than it already is, but it's not exactly an example of
robustness in terms of API if it's a program's fault if it doesn't
follow every recvmsg with the above quoted check.
The ioctl is much more robust because there's no chance that somebody
can be attacked by forgetting a specialized non intuitive check after
calling the specialized ioctl that installs the fd.
Thanks,
Andrea
^ permalink raw reply
* Re: Continuing the UAPI split
From: Florian Weimer @ 2019-11-07 20:32 UTC (permalink / raw)
To: Carlos O'Donell
Cc: Szabolcs Nagy, Elichai Turkel, nd, Christian Brauner,
linux-api@vger.kernel.org, libc-alpha
In-Reply-To: <086ffddf-553f-453d-a046-4d5e6abead21@redhat.com>
* Carlos O'Donell:
> On 11/7/19 11:21 AM, Szabolcs Nagy wrote:
>>> Or just giving up and telling users they can't just directly include
>>> both libc headers and kernel headers?
>>
>> including both libc and linux headers is fragile and
>> will break differently across the different linux
>> libc implementations.
>
> We saw this all the time working in embedded.
Do you mean you saw problems while you working in the embedded space?
^ permalink raw reply
* [man-pages RFC PATCH] statx.2: document STATX_ATTR_VERITY
From: Eric Biggers @ 2019-11-07 22:02 UTC (permalink / raw)
To: linux-man
Cc: tytso, darrick.wong, linux-api, linux-f2fs-devel, dhowells,
linux-fscrypt, linux-fsdevel, jaegeuk, linux-ext4, victorhsieh
In-Reply-To: <20191107014420.GD15212@magnolia>
From: Eric Biggers <ebiggers@google.com>
Document the verity attribute for statx().
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
man2/statx.2 | 4 ++++
1 file changed, 4 insertions(+)
RFC since the kernel patches are currently under review.
The kernel patches can be found here:
https://lkml.kernel.org/linux-fscrypt/20191029204141.145309-1-ebiggers@kernel.org/T/#u
diff --git a/man2/statx.2 b/man2/statx.2
index d2f1b07b8..713bd1260 100644
--- a/man2/statx.2
+++ b/man2/statx.2
@@ -461,6 +461,10 @@ See
.TP
.B STATX_ATTR_ENCRYPTED
A key is required for the file to be encrypted by the filesystem.
+.TP
+.B STATX_ATTR_VERITY
+The file has fs-verity enabled. It cannot be written to, and all reads from it
+will be verified against a Merkle tree.
.SH RETURN VALUE
On success, zero is returned.
On error, \-1 is returned, and
--
2.24.0.rc1.363.gb1bccd3e3d-goog
^ permalink raw reply related
* Re: [PATCH 1/4] statx: define STATX_ATTR_VERITY
From: Eric Biggers @ 2019-11-07 22:12 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Theodore Ts'o, linux-api, linux-f2fs-devel, David Howells,
linux-fscrypt, linux-fsdevel, Jaegeuk Kim, linux-ext4,
Victor Hsieh
In-Reply-To: <20191107014420.GD15212@magnolia>
On Wed, Nov 06, 2019 at 05:44:20PM -0800, Darrick J. Wong wrote:
> On Tue, Oct 29, 2019 at 01:41:38PM -0700, Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@google.com>
> >
> > Add a statx attribute bit STATX_ATTR_VERITY which will be set if the
> > file has fs-verity enabled. This is the statx() equivalent of
> > FS_VERITY_FL which is returned by FS_IOC_GETFLAGS.
> >
> > This is useful because it allows applications to check whether a file is
> > a verity file without opening it. Opening a verity file can be
> > expensive because the fsverity_info is set up on open, which involves
> > parsing metadata and optionally verifying a cryptographic signature.
> >
> > This is analogous to how various other bits are exposed through both
> > FS_IOC_GETFLAGS and statx(), e.g. the encrypt bit.
> >
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > ---
> > include/linux/stat.h | 3 ++-
> > include/uapi/linux/stat.h | 2 +-
> > 2 files changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/stat.h b/include/linux/stat.h
> > index 765573dc17d659..528c4baad09146 100644
> > --- a/include/linux/stat.h
> > +++ b/include/linux/stat.h
> > @@ -33,7 +33,8 @@ struct kstat {
> > STATX_ATTR_IMMUTABLE | \
> > STATX_ATTR_APPEND | \
> > STATX_ATTR_NODUMP | \
> > - STATX_ATTR_ENCRYPTED \
> > + STATX_ATTR_ENCRYPTED | \
> > + STATX_ATTR_VERITY \
> > )/* Attrs corresponding to FS_*_FL flags */
> > u64 ino;
> > dev_t dev;
> > diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h
> > index 7b35e98d3c58b1..ad80a5c885d598 100644
> > --- a/include/uapi/linux/stat.h
> > +++ b/include/uapi/linux/stat.h
> > @@ -167,8 +167,8 @@ struct statx {
> > #define STATX_ATTR_APPEND 0x00000020 /* [I] File is append-only */
> > #define STATX_ATTR_NODUMP 0x00000040 /* [I] File is not to be dumped */
> > #define STATX_ATTR_ENCRYPTED 0x00000800 /* [I] File requires key to decrypt in fs */
> > -
> > #define STATX_ATTR_AUTOMOUNT 0x00001000 /* Dir: Automount trigger */
> > +#define STATX_ATTR_VERITY 0x00100000 /* [I] Verity protected file */
>
> Any reason why this wasn't 0x2000?
Yes, as Andreas pointed out, the value is chosen to match the corresponding
FS_IOC_GETFLAGS bit, like the other bits above marked [I].
>
> If there's a manpage update that goes with this, then...
> Acked-by: Darrick J. Wong <darrick.wong@oracle.com>
>
It's pretty trivial to add it to the statx(2) man page.
I've sent out a patch for comment:
https://lkml.kernel.org/linux-fscrypt/20191107220248.32025-1-ebiggers@kernel.org/
- Eric
^ permalink raw reply
* Re: Continuing the UAPI split
From: Carlos O'Donell @ 2019-11-07 22:32 UTC (permalink / raw)
To: Florian Weimer
Cc: Szabolcs Nagy, Elichai Turkel, nd, Christian Brauner,
linux-api@vger.kernel.org, libc-alpha
In-Reply-To: <875zjvo2be.fsf@mid.deneb.enyo.de>
On 11/7/19 3:32 PM, Florian Weimer wrote:
> * Carlos O'Donell:
>
>> On 11/7/19 11:21 AM, Szabolcs Nagy wrote:
>>>> Or just giving up and telling users they can't just directly include
>>>> both libc headers and kernel headers?
>>>
>>> including both libc and linux headers is fragile and
>>> will break differently across the different linux
>>> libc implementations.
>>
>> We saw this all the time working in embedded.
>
> Do you mean you saw problems while you working in the embedded space?
Yes, embedded Linux to be specific.
There is a strong coupling between the kernel version and the toolchain
version, specifically because the strategies we take to solve these
problems end up being brittle in this regard.
Too new a kernel and you get new header problems not solved by your
old libc. Too new a libc and the kernel doesn't have the header
coordination fixes required for the newer software that needed the
newer libc.
Does that clarify my point?
--
Cheers,
Carlos.
^ permalink raw reply
* Re: [man-pages RFC PATCH] statx.2: document STATX_ATTR_VERITY
From: Darrick J. Wong @ 2019-11-08 0:47 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-man, tytso, linux-api, linux-f2fs-devel, dhowells,
linux-fscrypt, linux-fsdevel, jaegeuk, linux-ext4, victorhsieh
In-Reply-To: <20191107220248.32025-1-ebiggers@kernel.org>
On Thu, Nov 07, 2019 at 02:02:48PM -0800, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> Document the verity attribute for statx().
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
> man2/statx.2 | 4 ++++
> 1 file changed, 4 insertions(+)
>
> RFC since the kernel patches are currently under review.
> The kernel patches can be found here:
> https://lkml.kernel.org/linux-fscrypt/20191029204141.145309-1-ebiggers@kernel.org/T/#u
>
> diff --git a/man2/statx.2 b/man2/statx.2
> index d2f1b07b8..713bd1260 100644
> --- a/man2/statx.2
> +++ b/man2/statx.2
> @@ -461,6 +461,10 @@ See
> .TP
> .B STATX_ATTR_ENCRYPTED
> A key is required for the file to be encrypted by the filesystem.
> +.TP
> +.B STATX_ATTR_VERITY
> +The file has fs-verity enabled. It cannot be written to, and all reads from it
> +will be verified against a Merkle tree.
mkerrisk might ask you to start the new sentence on a separate line, but
otherwise looks good to me. :)
--D
> .SH RETURN VALUE
> On success, zero is returned.
> On error, \-1 is returned, and
> --
> 2.24.0.rc1.363.gb1bccd3e3d-goog
>
^ permalink raw reply
* Re: [RFC PATCH 04/14] pipe: Add O_NOTIFICATION_PIPE [ver #2]
From: Andy Lutomirski @ 2019-11-08 5:06 UTC (permalink / raw)
To: David Howells
Cc: Andy Lutomirski, Linus Torvalds, Greg Kroah-Hartman,
Casey Schaufler, Stephen Smalley, Nicolas Dichtel, raven,
Christian Brauner, keyrings, USB list, linux-block, LSM List,
Linux FS Devel, Linux API, LKML
In-Reply-To: <6964.1573152517@warthog.procyon.org.uk>
On Thu, Nov 7, 2019 at 10:48 AM David Howells <dhowells@redhat.com> wrote:
>
> Andy Lutomirski <luto@kernel.org> wrote:
>
> > > Add an O_NOTIFICATION_PIPE flag that can be passed to pipe2() to indicate
> > > that the pipe being created is going to be used for notifications. This
> > > suppresses the use of splice(), vmsplice(), tee() and sendfile() on the
> > > pipe as calling iov_iter_revert() on a pipe when a kernel notification
> > > message has been inserted into the middle of a multi-buffer splice will be
> > > messy.
> >
> > How messy?
>
> Well, iov_iter_revert() on a pipe iterator simply walks backwards along the
> ring discarding the last N contiguous slots (where N is normally the number of
> slots that were filled by whatever operation is being reverted).
>
> However, unless the code that transfers stuff into the pipe takes the spinlock
> spinlock and disables softirqs for the duration of its ring filling, what were
> N contiguous slots may now have kernel notifications interspersed - even if it
> has been holding the pipe mutex.
>
> So, now what do you do? You have to free up just the buffers relevant to the
> iterator and then you can either compact down the ring to free up the space or
> you can leave null slots and let the read side clean them up, thereby
> reducing the capacity of the pipe temporarily.
>
> Either way, iov_iter_revert() gets more complex and has to hold the spinlock.
I feel like I'm missing something fundamental here.
I can open a normal pipe from userspace (with pipe() or pipe2()), and
I can have two threads. One thread writes to the pipe with write().
The other thread writes with splice(). Everything works fine. What's
special about notifications?
^ permalink raw reply
* Re: [RFC PATCH 04/14] pipe: Add O_NOTIFICATION_PIPE [ver #2]
From: David Howells @ 2019-11-08 6:42 UTC (permalink / raw)
To: Andy Lutomirski
Cc: dhowells, Linus Torvalds, Greg Kroah-Hartman, Casey Schaufler,
Stephen Smalley, Nicolas Dichtel, raven, Christian Brauner,
keyrings, USB list, linux-block, LSM List, Linux FS Devel,
Linux API, LKML
In-Reply-To: <CALCETrWeN9CGJHz0dzG1uH5Qjbr+xG3OKZuEd33eBY_rAzVkqQ@mail.gmail.com>
Andy Lutomirski <luto@kernel.org> wrote:
> I can open a normal pipe from userspace (with pipe() or pipe2()), and
> I can have two threads. One thread writes to the pipe with write().
> The other thread writes with splice(). Everything works fine.
Yes. Every operation you do on a pipe from userspace is serialised with the
pipe mutex - and both ends share the same pipe.
> What's special about notifications?
The post_notification() cannot take the pipe mutex. It has to be callable
from softirq context. Linus's idea is that when you're actually altering the
ring pointers you should hold the wake-queue spinlock, and post_notification()
holds the wake queue spinlock for the duration of the operation.
This means that post_notification() can be writing to the pipe whilst a
userspace-invoked operation is holding the pipe mutex and is also doing
something to the ring.
David
^ permalink raw reply
* Re: Continuing the UAPI split
From: Florian Weimer @ 2019-11-08 7:28 UTC (permalink / raw)
To: Carlos O'Donell
Cc: Szabolcs Nagy, Elichai Turkel, nd, Christian Brauner,
linux-api@vger.kernel.org, libc-alpha
In-Reply-To: <70a264b5-427f-fa6e-7f70-768724202d14@redhat.com>
* Carlos O'Donell:
> On 11/7/19 3:32 PM, Florian Weimer wrote:
>> * Carlos O'Donell:
>>
>>> On 11/7/19 11:21 AM, Szabolcs Nagy wrote:
>>>>> Or just giving up and telling users they can't just directly include
>>>>> both libc headers and kernel headers?
>>>>
>>>> including both libc and linux headers is fragile and
>>>> will break differently across the different linux
>>>> libc implementations.
>>>
>>> We saw this all the time working in embedded.
>>
>> Do you mean you saw problems while you working in the embedded space?
>
> Yes, embedded Linux to be specific.
>
> There is a strong coupling between the kernel version and the toolchain
> version, specifically because the strategies we take to solve these
> problems end up being brittle in this regard.
>
> Too new a kernel and you get new header problems not solved by your
> old libc. Too new a libc and the kernel doesn't have the header
> coordination fixes required for the newer software that needed the
> newer libc.
>
> Does that clarify my point?
Yes, it does. It wasn't clear to me if you wanted to say that this
was actually working for the embedded case.
^ permalink raw reply
* Re: [PATCH v8 07/14] x86/cet/ibt: Add ENDBR to op-code-map
From: Adrian Hunter @ 2019-11-08 13:19 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, Borislav Petkov,
Cyrill Gorcunov, Dave Hansen, Eugene Syromiatnikov,
Florian Weimer, H.J. Lu, Jann Horn, Jonathan Corbet, Kees Cook,
Mike Kravetz
In-Reply-To: <20190813205359.12196-8-yu-cheng.yu@intel.com>
On 13/08/19 11:53 PM, Yu-cheng Yu wrote:
> Add control transfer terminating instructions:
>
> ENDBR64/ENDBR32:
> Mark a valid 64/32-bit control transfer endpoint.
>
> Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> ---
> arch/x86/lib/x86-opcode-map.txt | 13 +++++++++++--
> tools/objtool/arch/x86/lib/x86-opcode-map.txt | 13 +++++++++++--
> 2 files changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/lib/x86-opcode-map.txt b/arch/x86/lib/x86-opcode-map.txt
> index c5e825d44766..fbc53481bc59 100644
> --- a/arch/x86/lib/x86-opcode-map.txt
> +++ b/arch/x86/lib/x86-opcode-map.txt
> @@ -620,7 +620,16 @@ ea: SAVEPREVSSP (f3)
> # Skip 0xeb-0xff
> EndTable
>
> -Table: 3-byte opcode 2 (0x0f 0x38)
> +Table: 3-byte opcode 2 (0x0f 0x1e)
> +Referrer:
> +AVXcode:
> +# Skip 0x00-0xf9
> +fa: ENDBR64 (f3)
> +fb: ENDBR32 (f3)
endbr32 and endbr64 have 2-byte opcodes (0F 1E) and a ModRM byte, so a new
Grp is needed
> +#skip 0xfc-0xff
> +EndTable
> +
> +Table: 3-byte opcode 3 (0x0f 0x38)
> Referrer: 3-byte escape 1
> AVXcode: 2
> # 0x0f 0x38 0x00-0x0f
> @@ -804,7 +813,7 @@ f6: ADCX Gy,Ey (66) | ADOX Gy,Ey (F3) | MULX By,Gy,rDX,Ey (F2),(v) | WRSS Pq,Qq
> f7: BEXTR Gy,Ey,By (v) | SHLX Gy,Ey,By (66),(v) | SARX Gy,Ey,By (F3),(v) | SHRX Gy,Ey,By (F2),(v)
> EndTable
>
> -Table: 3-byte opcode 3 (0x0f 0x3a)
> +Table: 3-byte opcode 4 (0x0f 0x3a)
> Referrer: 3-byte escape 2
> AVXcode: 3
> # 0x0f 0x3a 0x00-0xff
> diff --git a/tools/objtool/arch/x86/lib/x86-opcode-map.txt b/tools/objtool/arch/x86/lib/x86-opcode-map.txt
> index c5e825d44766..fbc53481bc59 100644
> --- a/tools/objtool/arch/x86/lib/x86-opcode-map.txt
> +++ b/tools/objtool/arch/x86/lib/x86-opcode-map.txt
> @@ -620,7 +620,16 @@ ea: SAVEPREVSSP (f3)
> # Skip 0xeb-0xff
> EndTable
>
> -Table: 3-byte opcode 2 (0x0f 0x38)
> +Table: 3-byte opcode 2 (0x0f 0x1e)
> +Referrer:
> +AVXcode:
> +# Skip 0x00-0xf9
> +fa: ENDBR64 (f3)
> +fb: ENDBR32 (f3)
> +#skip 0xfc-0xff
> +EndTable
> +
> +Table: 3-byte opcode 3 (0x0f 0x38)
> Referrer: 3-byte escape 1
> AVXcode: 2
> # 0x0f 0x38 0x00-0x0f
> @@ -804,7 +813,7 @@ f6: ADCX Gy,Ey (66) | ADOX Gy,Ey (F3) | MULX By,Gy,rDX,Ey (F2),(v) | WRSS Pq,Qq
> f7: BEXTR Gy,Ey,By (v) | SHLX Gy,Ey,By (66),(v) | SARX Gy,Ey,By (F3),(v) | SHRX Gy,Ey,By (F2),(v)
> EndTable
>
> -Table: 3-byte opcode 3 (0x0f 0x3a)
> +Table: 3-byte opcode 4 (0x0f 0x3a)
> Referrer: 3-byte escape 2
> AVXcode: 3
> # 0x0f 0x3a 0x00-0xff
>
^ permalink raw reply
* Re: [PATCH v8 27/27] x86/cet/shstk: Add Shadow Stack instructions to opcode map
From: Adrian Hunter @ 2019-11-08 13:27 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, Borislav Petkov,
Cyrill Gorcunov, Dave Hansen, Eugene Syromiatnikov,
Florian Weimer, H.J. Lu, Jann Horn, Jonathan Corbet, Kees Cook,
Mike Kravetz
In-Reply-To: <20190813205225.12032-28-yu-cheng.yu@intel.com>
On 13/08/19 11:52 PM, Yu-cheng Yu wrote:
> Add the following shadow stack management instructions.
>
> INCSSP:
> Increment shadow stack pointer by the steps specified.
>
> RDSSP:
> Read SSP register into a GPR.
>
> SAVEPREVSSP:
> Use "prev ssp" token at top of current shadow stack to
> create a "restore token" on previous shadow stack.
>
> RSTORSSP:
> Restore from a "restore token" pointed by a GPR to SSP.
>
> WRSS:
> Write to kernel-mode shadow stack (kernel-mode instruction).
>
> WRUSS:
> Write to user-mode shadow stack (kernel-mode instruction).
>
> SETSSBSY:
> Verify the "supervisor token" pointed by IA32_PL0_SSP MSR,
> if valid, set the token to busy, and set SSP to the value
> of IA32_PL0_SSP MSR.
>
> CLRSSBSY:
> Verify the "supervisor token" pointed by a GPR, if valid,
> clear the busy bit from the token.
>
> Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> ---
> arch/x86/lib/x86-opcode-map.txt | 26 +++++++++++++------
> tools/objtool/arch/x86/lib/x86-opcode-map.txt | 26 +++++++++++++------
> 2 files changed, 36 insertions(+), 16 deletions(-)
>
> diff --git a/arch/x86/lib/x86-opcode-map.txt b/arch/x86/lib/x86-opcode-map.txt
> index e0b85930dd77..c5e825d44766 100644
> --- a/arch/x86/lib/x86-opcode-map.txt
> +++ b/arch/x86/lib/x86-opcode-map.txt
> @@ -366,7 +366,7 @@ AVXcode: 1
> 1b: BNDCN Gv,Ev (F2) | BNDMOV Ev,Gv (66) | BNDMK Gv,Ev (F3) | BNDSTX Ev,Gv
> 1c:
> 1d:
> -1e:
> +1e: RDSSP Rd (F3),REX.W
> 1f: NOP Ev
> # 0x0f 0x20-0x2f
> 20: MOV Rd,Cd
> @@ -610,7 +610,17 @@ fe: paddd Pq,Qq | vpaddd Vx,Hx,Wx (66),(v1)
> ff: UD0
> EndTable
>
> -Table: 3-byte opcode 1 (0x0f 0x38)
> +Table: 3-byte opcode 1 (0x0f 0x01)
> +Referrer:
> +AVXcode:
> +# Skip 0x00-0xe7
> +e8: SETSSBSY (f3)
> +e9:
> +ea: SAVEPREVSSP (f3)
> +# Skip 0xeb-0xff
> +EndTable
> +
> +Table: 3-byte opcode 2 (0x0f 0x38)
> Referrer: 3-byte escape 1
> AVXcode: 2
> # 0x0f 0x38 0x00-0x0f
> @@ -789,12 +799,12 @@ f0: MOVBE Gy,My | MOVBE Gw,Mw (66) | CRC32 Gd,Eb (F2) | CRC32 Gd,Eb (66&F2)
> f1: MOVBE My,Gy | MOVBE Mw,Gw (66) | CRC32 Gd,Ey (F2) | CRC32 Gd,Ew (66&F2)
> f2: ANDN Gy,By,Ey (v)
> f3: Grp17 (1A)
> -f5: BZHI Gy,Ey,By (v) | PEXT Gy,By,Ey (F3),(v) | PDEP Gy,By,Ey (F2),(v)
> -f6: ADCX Gy,Ey (66) | ADOX Gy,Ey (F3) | MULX By,Gy,rDX,Ey (F2),(v)
> +f5: BZHI Gy,Ey,By (v) | PEXT Gy,By,Ey (F3),(v) | PDEP Gy,By,Ey (F2),(v) | WRUSS Pq,Qq (66),REX.W
> +f6: ADCX Gy,Ey (66) | ADOX Gy,Ey (F3) | MULX By,Gy,rDX,Ey (F2),(v) | WRSS Pq,Qq (66),REX.W
> f7: BEXTR Gy,Ey,By (v) | SHLX Gy,Ey,By (66),(v) | SARX Gy,Ey,By (F3),(v) | SHRX Gy,Ey,By (F2),(v)
> EndTable
>
> -Table: 3-byte opcode 2 (0x0f 0x3a)
> +Table: 3-byte opcode 3 (0x0f 0x3a)
> Referrer: 3-byte escape 2
> AVXcode: 3
> # 0x0f 0x3a 0x00-0xff
> @@ -948,7 +958,7 @@ GrpTable: Grp7
> 2: LGDT Ms | XGETBV (000),(11B) | XSETBV (001),(11B) | VMFUNC (100),(11B) | XEND (101)(11B) | XTEST (110)(11B)
> 3: LIDT Ms
> 4: SMSW Mw/Rv
> -5: rdpkru (110),(11B) | wrpkru (111),(11B)
> +5: rdpkru (110),(11B) | wrpkru (111),(11B) | RSTORSSP Mq (F3)
> 6: LMSW Ew
> 7: INVLPG Mb | SWAPGS (o64),(000),(11B) | RDTSCP (001),(11B)
> EndTable
> @@ -1019,8 +1029,8 @@ GrpTable: Grp15
> 2: vldmxcsr Md (v1) | WRFSBASE Ry (F3),(11B)
> 3: vstmxcsr Md (v1) | WRGSBASE Ry (F3),(11B)
> 4: XSAVE | ptwrite Ey (F3),(11B)
> -5: XRSTOR | lfence (11B)
> -6: XSAVEOPT | clwb (66) | mfence (11B)
> +5: XRSTOR | lfence (11B) | INCSSP Rd (F3),REX.W
> +6: XSAVEOPT | clwb (66) | mfence (11B) | CLRSSBSY Mq (F3)
> 7: clflush | clflushopt (66) | sfence (11B)
> EndTable
>
> diff --git a/tools/objtool/arch/x86/lib/x86-opcode-map.txt b/tools/objtool/arch/x86/lib/x86-opcode-map.txt
> index e0b85930dd77..c5e825d44766 100644
> --- a/tools/objtool/arch/x86/lib/x86-opcode-map.txt
> +++ b/tools/objtool/arch/x86/lib/x86-opcode-map.txt
> @@ -366,7 +366,7 @@ AVXcode: 1
> 1b: BNDCN Gv,Ev (F2) | BNDMOV Ev,Gv (66) | BNDMK Gv,Ev (F3) | BNDSTX Ev,Gv
> 1c:
> 1d:
> -1e:
> +1e: RDSSP Rd (F3),REX.W
RDSSP is in a Grp with ENDBR32 and ENDBR64
> 1f: NOP Ev
> # 0x0f 0x20-0x2f
> 20: MOV Rd,Cd
> @@ -610,7 +610,17 @@ fe: paddd Pq,Qq | vpaddd Vx,Hx,Wx (66),(v1)
> ff: UD0
> EndTable
>
> -Table: 3-byte opcode 1 (0x0f 0x38)
> +Table: 3-byte opcode 1 (0x0f 0x01)
> +Referrer:
> +AVXcode:
> +# Skip 0x00-0xe7
> +e8: SETSSBSY (f3)
> +e9:
> +ea: SAVEPREVSSP (f3)
SETSSBSY and SAVEPREVSSP should be in Grp7
> +# Skip 0xeb-0xff
> +EndTable
> +
> +Table: 3-byte opcode 2 (0x0f 0x38)
> Referrer: 3-byte escape 1
> AVXcode: 2
> # 0x0f 0x38 0x00-0x0f
> @@ -789,12 +799,12 @@ f0: MOVBE Gy,My | MOVBE Gw,Mw (66) | CRC32 Gd,Eb (F2) | CRC32 Gd,Eb (66&F2)
> f1: MOVBE My,Gy | MOVBE Mw,Gw (66) | CRC32 Gd,Ey (F2) | CRC32 Gd,Ew (66&F2)
> f2: ANDN Gy,By,Ey (v)
> f3: Grp17 (1A)
> -f5: BZHI Gy,Ey,By (v) | PEXT Gy,By,Ey (F3),(v) | PDEP Gy,By,Ey (F2),(v)
> -f6: ADCX Gy,Ey (66) | ADOX Gy,Ey (F3) | MULX By,Gy,rDX,Ey (F2),(v)
> +f5: BZHI Gy,Ey,By (v) | PEXT Gy,By,Ey (F3),(v) | PDEP Gy,By,Ey (F2),(v) | WRUSS Pq,Qq (66),REX.W
> +f6: ADCX Gy,Ey (66) | ADOX Gy,Ey (F3) | MULX By,Gy,rDX,Ey (F2),(v) | WRSS Pq,Qq (66),REX.W
I know already commented on this, but WRSS does not have (66) prefix
Also no other instructions have been annotated with REX.W so maybe omit that
> f7: BEXTR Gy,Ey,By (v) | SHLX Gy,Ey,By (66),(v) | SARX Gy,Ey,By (F3),(v) | SHRX Gy,Ey,By (F2),(v)
> EndTable
>
> -Table: 3-byte opcode 2 (0x0f 0x3a)
> +Table: 3-byte opcode 3 (0x0f 0x3a)
> Referrer: 3-byte escape 2
> AVXcode: 3
> # 0x0f 0x3a 0x00-0xff
> @@ -948,7 +958,7 @@ GrpTable: Grp7
> 2: LGDT Ms | XGETBV (000),(11B) | XSETBV (001),(11B) | VMFUNC (100),(11B) | XEND (101)(11B) | XTEST (110)(11B)
> 3: LIDT Ms
> 4: SMSW Mw/Rv
> -5: rdpkru (110),(11B) | wrpkru (111),(11B)
> +5: rdpkru (110),(11B) | wrpkru (111),(11B) | RSTORSSP Mq (F3)
> 6: LMSW Ew
> 7: INVLPG Mb | SWAPGS (o64),(000),(11B) | RDTSCP (001),(11B)
> EndTable
> @@ -1019,8 +1029,8 @@ GrpTable: Grp15
> 2: vldmxcsr Md (v1) | WRFSBASE Ry (F3),(11B)
> 3: vstmxcsr Md (v1) | WRGSBASE Ry (F3),(11B)
> 4: XSAVE | ptwrite Ey (F3),(11B)
> -5: XRSTOR | lfence (11B)
> -6: XSAVEOPT | clwb (66) | mfence (11B)
> +5: XRSTOR | lfence (11B) | INCSSP Rd (F3),REX.W
> +6: XSAVEOPT | clwb (66) | mfence (11B) | CLRSSBSY Mq (F3)
> 7: clflush | clflushopt (66) | sfence (11B)
> EndTable
>
>
^ permalink raw reply
* Re: [PATCH bpf-next v13 4/7] landlock: Add ptrace LSM hooks
From: Mickaël Salaün @ 2019-11-08 14:08 UTC (permalink / raw)
To: KP Singh
Cc: Alexei Starovoitov, linux-kernel, Alexei Starovoitov,
Andy Lutomirski, Casey Schaufler, Daniel Borkmann, David Drysdale,
Florent Revest, James Morris, Jann Horn, John Johansen,
Jonathan Corbet, Kees Cook, Michael Kerrisk,
Mickaël Salaün, Paul Moore, Sargun Dhillon,
Serge E . Hallyn, Shuah Khan, Stephen Smalley
In-Reply-To: <20191106214526.GA22244@chromium.org>
On 06/11/2019 22:45, KP Singh wrote:
> On 06-Nov 17:55, Mickaël Salaün wrote:
>>
>> On 06/11/2019 11:06, KP Singh wrote:
>>> On 05-Nov 11:34, Alexei Starovoitov wrote:
>>>> On Tue, Nov 05, 2019 at 07:01:41PM +0100, Mickaël Salaün wrote:
>>>>> On 05/11/2019 18:18, Alexei Starovoitov wrote:
>>
>> [...]
>>
>>>>>> I think the only way bpf-based LSM can land is both landlock and KRSI
>>>>>> developers work together on a design that solves all use cases.
>>>>>
>>>>> As I said in a previous cover letter [1], that would be great. I think
>>>>> that the current Landlock bases (almost everything from this series
>>>>> except the seccomp interface) should meet both needs, but I would like
>>>>> to have the point of view of the KRSI developers.
>>>>>
>>>>> [1] https://lore.kernel.org/lkml/20191029171505.6650-1-mic@digikod.net/
>>>>>
>>>>>> BPF is capable
>>>>>> to be a superset of all existing LSMs whereas landlock and KRSI propsals today
>>>>>> are custom solutions to specific security concerns. BPF subsystem was extended
>>>>>> with custom things in the past. In networking we have lwt, skb, tc, xdp, sk
>>>>>> program types with a lot of overlapping functionality. We couldn't figure out
>>>>>> how to generalize them into single 'networking' program. Now we can and we
>>>>>> should. Accepting two partially overlapping bpf-based LSMs would be repeating
>>>>>> the same mistake again.
>>>>>
>>>>> I'll let the LSM maintainers comment on whether BPF could be a superset
>>>>> of all LSM, but given the complexity of an access-control system, I have
>>>>> some doubts though. Anyway, we need to start somewhere and then iterate.
>>>>> This patch series is a first step.
>>>>
>>>> I would like KRSI folks to speak up. So far I don't see any sharing happening
>>>> between landlock and KRSI. You're claiming this set is a first step. They're
>>>> claiming the same about their patches. I'd like to set a patchset that was
>>>> jointly developed.
>>>
>>> We are willing to collaborate with the Landlock developers and come up
>>> with a common approach that would work for Landlock and KRSI. I want
>>> to mention that this collaboration and the current Landlock approach
>>> of using an eBPF based LSM for unprivileged sandboxing only makes sense
>>> if unprivileged usage of eBPF is going to be ever allowed.
>>
>> The ability to *potentially* do unprivileged sandboxing is definitely
>> not tied nor a blocker to the unprivileged usage of eBPF. As explained
>> in the documentation [1] (cf. Guiding principles / Unprivileged use),
>> Landlock is designed to be as safe as possible (from a security point of
>> view). The impact is more complex and important than just using
>> unprivileged eBPF, which may not be required. Unprivileged use of eBPF
>> would be nice, but I think the current direction is to extend the Linux
>> capabilities with one or multiple dedicated to eBPF [2] (e.g. CAP_BPF +
>> something else), which may be even better (and a huge difference with
>> CAP_SYS_ADMIN, a.k.a. privileged mode or root). Landlock is designed to
>> deal with unprivileged (i.e. non-root) use cases, but of course, if the
>> Landlock architecture may enable to do unprivileged stuff, it definitely
>> can do privileged stuff too. However, having an architecture designed
>> with safe unprivileged use in mind can't be achieve afterwards.
>>
>> [1] https://lore.kernel.org/lkml/20191104172146.30797-8-mic@digikod.net/
>> [2] https://lore.kernel.org/bpf/20190827205213.456318-1-ast@kernel.org/
>>
>>
>>>
>>> Purely from a technical standpoint, both the current designs for
>>> Landlock and KRSI target separate use cases and it would not be
>>> possible to build "one on top of the other". We've tried to identify
>>> the lowest denominator ("eBPF+LSM") requirements for both Landlock
>>> (unprivileged sandboxing / Discretionary Access Control) and KRSI
>>> (flexibility and unification of privileged MAC and Audit) and
>>> prototyped an implementation based on the newly added / upcoming
>>> features in BPF.
>>
>> This is not as binary as that. Sandboxing can be seen as DAC but also as
>> MAC, depending on the subject which apply the security policy and the
>> subjects which are enforced by this policy. If the sandboxing is applied
>> system-wide, it is what we usually call MAC. DAC, in the Linux world,
>> enables any user to restrict access to their files to other users.
>>
>> With Landlock it is not the same because a process can restrict itself
>> but also enforce these restrictions on all its future children (which
>> may be malicious, whatever their UID/GID). The threat and the definition
>> of the attacker are not the same in both cases. With the Linux DAC the
>> potentially malicious subjects are the other users, whereas with
>> Landlock the potentially malicious subjects are (for now) the current
>> process and all its children. Another way to explain it, and how
>> Landlock is designed, is that a specific enforcement (i.e. a set of BPF
>> programs) is tied to a domain, in which a set of subject are. From this
>> perspective, this approach (subjects/tasks in a domain) is orthogonal to
>> the DAC system (subjects/users). This design may apply to a system-wide
>> MAC system by putting all the system tasks in one domain, and managing
>> restrictions (by subject) with other means (e.g. task's UID,
>> command-line strings, environment variables). In short, Landlock (in
>> this patch series) is closer to a (potentially scoped) MAC system. But
>> thanks to eBPF, Landlock is firstly a programmatic access-control, which
>> means that the one who write the programs and tie them to a set of
>> tasks, can implement their own access-control system (e.g. RBAC,
>> time-based…), or something else (e.g. an audit system).
>>
>> The audit part can simply be achieve with dedicated helpers and programs
>> that always allow accesses.
>>
>> Landlock evolved over multiple iterations and is now designed to be very
>> flexible. The current way to enforce a security policy is to go through
>> the seccomp syscall (which makes sense for multiple reasons explained
>> and accepted before). But Landlock is designed to enable similar
>> enforcements (or audit) with other ways to define a domain (e.g. cgroups
>> [3], or system-wide securityfs as done in KRSI). Indeed, the only part
>> tied to this scoped enforcement is in the domain_syscall.c file. A new
>> file domain_fs.c could be added to implement a securityfs for a
>> system-wide enforcement (and have other features as KRSI does).
>>
>
> Given the current way landlock exposes LSM hooks, I don't think it's
> possible to build system-wide detections.
Why ?
> But let’s try to come to a
> consensus on the semantics of the how the LSM hooks are exposed to
> BPF. At the moment I think we should:
>
>
> * Bring the core interface exposed to eBPF closer to the LSM surface in
> a way that supports both use cases. One way Landlock can still provide
> a more abstract interface is by providing some BPF helper libraries
> that build on top of the core framework.
I still don't get why you think it is the only way or the better. I gave
a lot of arguments and I explained why Landlock is designed the way it
is, especially in the documentation (Guiding principles). Is there
something similar for KRSI?
>
> * Use a single BPF program type; this is necessary for a key requirement
> of KRSI, i.e. runtime instrumentation. The upcoming prototype should
> illustrate how this works for KRSI - note that it’s possible to vary
> the context types exposed by different hooks.
Why a single BPF program type? Do you mean *attach* types? Landlock only
use one program type, but will use multiple attach types.
Why do you think it is necessary for KRSI or for runtime instrumentation?
If it is justified, it could be a dedicated program attach type (e.g.
BPF_LANDLOCK_INTROSPECTION).
What is the advantage to have the possibility to vary the context types
over dedicated *typed* contexts? I don't see any advantages, but at
least one main drawback: to require runtime checks (when helpers use
this generic context) instead of load time checks (thanks to static type
checking of the context).
> It would be nice to get the BPF maintainers’ opinion on these points.
>
>
>> [3] https://lore.kernel.org/lkml/20160914072415.26021-17-mic@digikod.net/
>>
>> One possible important difference between Landlock and KRSI right now is
>> the BPF program management. Both manage a list of programs per hook.
>> However KRSI needs to be able to replace a program in these lists. This
>> is not implemented in this Landlock patch series, first because it is
>> not the main use-case and it is safer to have an append-only way to add
>> restrictions (cf. seccomp-bpf model), and second because it is simpler
>> to deal with immutable lists. However, it is worth considering extending
>> the Landlock domain management with the ability to update the program
>> lists. One challenge may be to identify which program should be replaced
>> (which KRSI does with the program name). I think it would be wiser to
>> implement this in a second step though, maybe not for the syscall
>> interface (thanks to a new seccomp operation), but first with the
>> securityfs one.
>>
>>
>>>
>>> We've been successfully able to prototype the use cases for KRSI
>>> (privileged MAC and Audit) using this "eBPF+LSM" and shared our
>>> approach at the Linux Security Summit [1]:
>>>
>>> * Use the new in-kernel BTF (CO-RE eBPF programs) [2] and the ability
>>> of the BPF verifier to use the BTF information for access validation
>>> to provide a more generic way to attach to the various LSM hooks.
>>> This potentially saves a lot of redundant work:
>>>
>>> - Creation of new program types.
>>> - Multiple types of contexts (or a single context with Unions).
>>> - Changes to the verifier and creation of new BPF argument types
>>> (eg. PTR_TO_TASK)
>>
>> As I understood from the LSS talk, KRSI's approach is to use the same
>> hooks as LSM (cf. the securityfs). As said Alexei [4] "It must not make
>> LSM hooks into stable ABI". Moveover, the LSM hooks may change
>> according to internal kernel evolution, and their semantic may not make
>
> I think you misunderstand Alexei here. I will let him elaborate.
>
>> sense from a user space point of view. This is one reason for which
>> Lanlock abstract those hooks into something that is simpler and designed
>> to fit well with eBPF (program contexts and their attached types, as
>> explained in the documentation).
>>
>> [4]
>> https://lore.kernel.org/lkml/20191105215453.szhdkrvuekwfz6le@ast-mbp.dhcp.thefacebook.com/
>>
>> How does KRSI plan to deal with one LSM hook being split in two hooks in
>> a next version of the kernel (cf. [5])?
>
> How often has that happened in the past? And even if it does happen,
> it can still be handled as a part of the base framework we are trying
> to implement.
I guess the security maintainers should have an opinion on this.
I don't clearly see the properties of this base framework. Could this be
elaborated?
>> [5] https://lore.kernel.org/lkml/20190910115527.5235-6-kpsingh@chromium.org/
>>
>>
>> Another reason to have multiple different attach types/contexts (cf.
>> landlock_domain->programs[]) is to limit useless BPF program
>> interpretation (in addition to the non-system-wide scoped of programs).
>> It also enables to handle and verify strict context use (which is also
>> explain in the Guiding principles). It would be a huge wast of time to
>> run every BPF programs for all LSM hooks. KRSI does the same but instead
>> of relying on the program type it rely on the list tied to the
>> securityfs file.
>>
>> BTF is great, but as far as I know, it's goal is to easily deal with the
>> moving kernel ABI (e.g. task_struct layout, config/constant variables),
>> and it is definitely useful to programs using bpf_probe_read() and
>> similar accessors. However, I don't see how KRSI would avoid BPF types
>> thanks to BTF.
>>
>
> This should become clearer once we post our updated patch-set. Do note
> that I am currently traveling and will be away for the next couple of
> weeks.
>
>> There is only one program type for Landlock (i.e.
>> BPF_PROG_TYPE_LANDLOCK_HOOK), and I don't see why adding new program
>> *attach* types (e.g. BPF_LANDLOCK_PTRACE) may be an issue. The kernel
>> will still need to be modified to implement new hooks and the new BPF
>> helpers anyway, BTF will not change that, except maybe if the internal
>> LSM API is exposed in a way or another to BPF (thanks to BTF), which
>> does not seem acceptable. Am I missing something?
>>
>>
>> The current KRSI approach is to allow a common set of helpers to be
>> called by all programs (because there is no way to differentiate them
>> with their type).
>> How KRSI would deal with kernel objects other than the current task
>> (e.g. a ptrace hook with a tracer and a tracee, a file open/read) with
>> the struct krsi_ctx unions [6]?
>>
>> [6] https://lore.kernel.org/lkml/20190910115527.5235-7-kpsingh@chromium.org/
>>
>
> The best part of BTF is that it can provide a common way to pass
> different contexts to the various attachments points and the verifier
> can use the BTF information to validate accesses which essentially
> allows us to change the helpers from:
>
> is_running_executable(magical_krsi_ctx)
>
> to
>
> is_running_executable(inode)
>
>
> which can work on any inode (ARG_PTR_TO_BTF_ID = btf_id(struct inode))
>
> This makes the helpers much more useful and generic. All this is
> better explained in our upcoming patch-set.
I get the usefulness of BTF for future helper evolution and for moving
kernel API, but again, I don't see advantages over static typing check
of (well abstract/generic) kernel object handles in the context.
For instance, how BTF would replace the current BPF_LANDLOCK_PTRACE
context and the associated helper?
Does this mean that the KRSI v1 design is outdated and superseded by the
(future) v2 because of the more important use of BTF?
>> How does KRSI plan to deal with security blobs?
>
> The new prototype uses security blobs but does not expose them to
> user-space. These blobs are then used in various helpers like
> “is_running_executable” which uses blobs on the inode and the
> task_struct. This should become clearer when the next patchset is
> posted.
>
> I don’t think it’s currently possible to allow the blobs to be set
> using eBPF programs with the main reason being that the blob will only
> be set after the program is loaded. The answer to
> “is_running_executable” becomes dependent on whether the file was
> executed before the blob setting eBPF program was loaded.
>
> Blob management with eBPF is not possible unless we can load eBPF
> programs that can set blobs at boot-time.
> In short, the next KRSI version will not give eBPF
> programs access to arbitrarily write security blobs.
A previous version of Landlock enabled programs to tag inodes (cf.
FS_GET): https://lore.kernel.org/lkml/20180227004121.3633-8-mic@digikod.net/
>>>
>>> * These new BPF features also alleviate the original concerns that we
>>> raised when initially proposing KRSI and designing for precise BPF
>>> helpers. We have some patches coming up which incorporate these new
>>> changes and will be sharing something on the mailing list after some
>>> cleanup.
>>>
>>> We can use the common "eBPF+LSM" for both privileged MAC and Audit and
>>> unprivileged sandboxing i.e. Discretionary Access Control.
>>> Here's what it could look like:
>>>
>>> * Common infrastructure allows attachment to all hooks which works well
>>> for privileged MAC and Audit. This could be extended to provide
>>> another attachment type for unprivileged DAC, which can restrict the
>>> hooks that can be attached to, and also the information that is
>>> exposed to the eBPF programs which is something that Landlock could
>>> build.
>>
>> I agree that the "privileged-only" hooks should be a superset of the
>> "security-safe-and-potentially-unprivileged" hooks. :)
>> However, as said previously, I'm convinced it is a requirement to have
>> abstract hooks (and associated program attach types) as defined by Landlock.
>
> I would like to hear the BPF maintainers’ perspective on this. I am
> not sure they agree with you here.
>
> - KP Singh
>
>>
>> I'm not sure what you mean by "the information that is exposed to the
>> eBPF program". Is it the current Landlock implementation of specific
>> contexts and attach types?
…or does BTF could magically solve this?
>>
>>>
>>> * This attachment could use the proposed landlock domains and attach to
>>> the task_struct providing the discretionary access control semantics.
>>
>> Not task_struct but creds, yes. This is a characteristic of sandboxing,
>> which may not be useful for the KRSI use case. It makes sense for KRSI
>> to attach program sets (or Landlock domains) to the whole system, then
>> using the creds does not make sense here. This difference is small and a
>> previous version of Landlock already validated this use case with
>> cgroups [3] (which is postponed to simplify the patch series).
>>
>> [3] https://lore.kernel.org/lkml/20160914072415.26021-17-mic@digikod.net/
>>
>>
>>>
>>> [1] https://static.sched.com/hosted_files/lsseu2019/a2/Kernel%20Runtime%20Security%20Instrumentation.pdf
>>> [2] http://vger.kernel.org/bpfconf2019_talks/bpf-core.pdf
>>>
>>> - KP Singh
>>
>> I think it should be OK to first land something close to this Landlock
>> patch series and then we could extend the domain management features and
>> add the securityfs support that KRSI needs. The main concern seems to be
>> about hook definitions.
>>
>> Another approach would be to land Landlock and KRSI as distinct LSM
>> while trying as much as possible to mutualize code/helpers.
>
^ permalink raw reply
* Re: [PATCH bpf-next v13 4/7] landlock: Add ptrace LSM hooks
From: Daniel Borkmann @ 2019-11-08 14:34 UTC (permalink / raw)
To: Mickaël Salaün, KP Singh
Cc: Alexei Starovoitov, linux-kernel, Alexei Starovoitov,
Andy Lutomirski, Casey Schaufler, David Drysdale, Florent Revest,
James Morris, Jann Horn, John Johansen, Jonathan Corbet,
Kees Cook, Michael Kerrisk, Mickaël Salaün, Paul Moore,
Sargun Dhillon, Serge E . Hallyn, Shuah Khan, Stephen Smalley,
Tejun Heo
In-Reply-To: <3e208632-e7ab-3405-5196-ab1d770e20c3@digikod.net>
On 11/8/19 3:08 PM, Mickaël Salaün wrote:
> On 06/11/2019 22:45, KP Singh wrote:
>> On 06-Nov 17:55, Mickaël Salaün wrote:
>>> On 06/11/2019 11:06, KP Singh wrote:
>>>> On 05-Nov 11:34, Alexei Starovoitov wrote:
>>>>> On Tue, Nov 05, 2019 at 07:01:41PM +0100, Mickaël Salaün wrote:
>>>>>> On 05/11/2019 18:18, Alexei Starovoitov wrote:
[...]
>> * Use a single BPF program type; this is necessary for a key requirement
>> of KRSI, i.e. runtime instrumentation. The upcoming prototype should
>> illustrate how this works for KRSI - note that it’s possible to vary
>> the context types exposed by different hooks.
>
> Why a single BPF program type? Do you mean *attach* types? Landlock only
> use one program type, but will use multiple attach types.
>
> Why do you think it is necessary for KRSI or for runtime instrumentation?
>
> If it is justified, it could be a dedicated program attach type (e.g.
> BPF_LANDLOCK_INTROSPECTION).
>
> What is the advantage to have the possibility to vary the context types
> over dedicated *typed* contexts? I don't see any advantages, but at
> least one main drawback: to require runtime checks (when helpers use
> this generic context) instead of load time checks (thanks to static type
> checking of the context).
Lets take security_sock_rcv_skb(struct sock *sk, struct sk_buff *skb)
as one specific example here: the running kernel has its own internal
btf_vmlinux and therefore a complete description of itself. From verifier
side we can retrieve & introspect the security_sock_rcv_skb signatue and
thus know that the given BPF attachment point has struct sock and struct
sk_buff as input arguments which can then be accessed generically by the
prog in order to allow sk_filter_trim_cap() to pass or to drop the skb.
The same generic approach can be done for many of the other lsm hooks, so
single program type would be enough there and context is derived automatically,
no dedicated extra context per attach type would be needed and no runtime
checks as you mentioned above since its still all asserted at verification
time.
Thanks,
Daniel
^ 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