* Re: RFC: renameat(): Add a RENAME_REMOVE flag to unlink hardlinks
From: Pádraig Brady @ 2014-11-21 18:39 UTC (permalink / raw)
To: Andy Lutomirski, Linux FS Devel; +Cc: Linux API
In-Reply-To: <CALCETrXvVxvG+s39v+NMdvfkeb8YjbYjb6UXgDFg5ifYOjeKsA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 21/11/14 18:09, Andy Lutomirski wrote:
> On Fri, Nov 21, 2014 at 6:17 AM, Pádraig Brady <P@draigbrady.com> wrote:
>> If 'a' and 'b' are hardlinks, then the command `mv a b & mv b a`
>> can result in both being removed as mv needs to emulate the
>> move with an unlink of the source file. This can only be done
>> without races in the kernel and so mv was recently changed
>> to not allow this operation at all. mv could safely reintroduce
>> this feature by leveraging a new flag for renameat() for which
>> an illustrative/untested patch is attached.
>
> ISTM the issue is that rename(2) does nothing if the source and dest
> are hardlinks to each other. Is that intentional? I don't see that
> behavior as required in the POSIX rename docs.
It's surprising and annoying that existing systems do this,
but they're conforming to the wording of POSIX I thinkg as
it says that rename() does nothing when the source and dest
_file_ is the same. What POSIX really meant I suppose was _file name_.
Eric, perhaps an adjustment could be proposed to POSIX, as I can't
see anything relying on the current behavior?
> If we indeed need to keep that behavior around for legacy reasons,
> then can we at least give RENAME_REMOVE a better name?
Definitely not attached to the name :)
Let's see if we can change it without a flag, though I guess
that would mean that mv on older systems would
silently do nothing in this case.
thanks,
Pádraig.
^ permalink raw reply
* Re: RFC: renameat(): Add a RENAME_REMOVE flag to unlink hardlinks
From: Andy Lutomirski @ 2014-11-21 18:09 UTC (permalink / raw)
To: Pádraig Brady, Linux FS Devel; +Cc: Linux API
In-Reply-To: <546F4981.8080907-V8g9lnOeT5ydJdNcDFJN0w@public.gmane.org>
On Fri, Nov 21, 2014 at 6:17 AM, Pádraig Brady <P@draigbrady.com> wrote:
> If 'a' and 'b' are hardlinks, then the command `mv a b & mv b a`
> can result in both being removed as mv needs to emulate the
> move with an unlink of the source file. This can only be done
> without races in the kernel and so mv was recently changed
> to not allow this operation at all. mv could safely reintroduce
> this feature by leveraging a new flag for renameat() for which
> an illustrative/untested patch is attached.
ISTM the issue is that rename(2) does nothing if the source and dest
are hardlinks to each other. Is that intentional? I don't see that
behavior as required in the POSIX rename docs.
If we indeed need to keep that behavior around for legacy reasons,
then can we at least give RENAME_REMOVE a better name?
--Andy
>
> thanks,
> Pádraig.
--
Andy Lutomirski
AMA Capital Management, LLC
^ permalink raw reply
* Re: kdbus: add node and filesystem implementation
From: Greg Kroah-Hartman @ 2014-11-21 17:55 UTC (permalink / raw)
To: Sasha Levin
Cc: David Herrmann, Arnd Bergmann, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
One Thousand Gnomes, Tom Gundersen, Jiri Kosina, Andy Lutomirski,
Linux API, linux-kernel, Daniel Mack, Djalal Harouni
In-Reply-To: <546F7077.4010200-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
On Fri, Nov 21, 2014 at 12:03:51PM -0500, Sasha Levin wrote:
> On 11/21/2014 11:56 AM, Greg Kroah-Hartman wrote:
> >>> Maybe it's worth basing your git tree on top of Al's rather than a random
> >>> > > -rc, since it's now a filesystem?
> >> >
> >> > Sure, sounds good.
> > No, I'll keep it as is, we can handle the merge issues later when it
> > hits Linus's tree, this makes it easier for me and others to test it
> > out properly.
>
> It should be hitting -next, not Linus's tree. This is why we have an
> integration tree, no?
Yes, it will hit -next, and the merge issue can be resolved there.
^ permalink raw reply
* Re: kdbus: add documentation
From: Andy Lutomirski @ 2014-11-21 17:12 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Arnd Bergmann, Eric W. Biederman, One Thousand Gnomes,
Tom Gundersen, Jiri Kosina, Linux API,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Daniel Mack,
David Herrmann, Djalal Harouni
In-Reply-To: <1416546149-24799-2-git-send-email-gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
On Thu, Nov 20, 2014 at 9:02 PM, Greg Kroah-Hartman
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
> From: Daniel Mack <daniel-cYrQPVfZoowdnm+yROfE0A@public.gmane.org>
>
> kdbus is a system for low-latency, low-overhead, easy to use
> interprocess communication (IPC).
>
> The interface to all functions in this driver is implemented through
> ioctls on files exposed through the mount point of a kdbusfs. This
> patch adds detailed documentation about the kernel level API design.
>
> Signed-off-by: Daniel Mack <daniel-cYrQPVfZoowdnm+yROfE0A@public.gmane.org>
> Signed-off-by: David Herrmann <dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Djalal Harouni <tixxdz-Umm1ozX2/EEdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
> ---
> + Pool:
> + Each connection allocates a piece of shmem-backed memory that is used
> + to receive messages and answers to ioctl command from the kernel. It is
> + never used to send anything to the kernel. In order to access that memory,
> + userspace must mmap() it into its task.
> + See section 12 for more details.
At the risk of opening a can of worms, wouldn't this be much more
useful if you could share a pool between multiple connections?
> +
> +
> +4. Items
> +===============================================================================
> +
> +To flexibly augment transport structures used by kdbus, data blobs of type
> +struct kdbus_item are used. An item has a fixed-sized header that only stores
> +the type of the item and the overall size. The total size is variable and is
> +in some cases defined by the item type, in other cases, they can be of
> +arbitrary length (for instance, a string).
> +
> +In the external kernel API, items are used for many ioctls to transport
> +optional information from userspace to kernelspace. They are also used for
> +information stored in a connection's pool, such as messages, name lists or
> +requested connection information.
> +
> +In all such occasions where items are used as part of the kdbus kernel API,
> +they are embedded in structs that have an overall size of their own, so there
> +can be many of them.
> +
> +The kernel expects all items to be aligned to 8-byte boundaries.
> +
> +A simple iterator in userspace would iterate over the items until the items
> +have reached the embedding structure's overall size. An example implementation
> +of such an iterator can be found in tools/testing/selftests/kdbus/kdbus-util.h.
It looks like many (all?) item consumers ignore unknown items. This
seems like a compatbility problem.
Would it be better to have a bit in each item that toggles between
"ignore me if you don't recognize me" and "error out if you don't
recognize me"?
> +KDBUS_CMD_BUS_MAKE, and KDBUS_CMD_ENDPOINT_MAKE take a
> +struct kdbus_cmd_make argument.
> +
> +struct kdbus_cmd_make {
> + __u64 size;
> + The overall size of the struct, including its items.
> +
> + __u64 flags;
> + The flags for creation.
> +
> + KDBUS_MAKE_ACCESS_GROUP
> + Make the device file group-accessible
> +
> + KDBUS_MAKE_ACCESS_WORLD
> + Make the device file world-accessible
This thing is a file. What's wrong with using a normal POSIX mode?
(And what to the read, write, and exec modes do?)
> +
> +
> +6.2 Creating connections
> +------------------------
> +
> +A connection to a bus is created by opening an endpoint file of a bus and
> +becoming an active client with the KDBUS_CMD_HELLO ioctl. Every connected client
> +connection has a unique identifier on the bus and can address messages to every
> +other connection on the same bus by using the peer's connection id as the
> +destination.
> +
> +The KDBUS_CMD_HELLO ioctl takes the following struct as argument.
> +
> +struct kdbus_cmd_hello {
> + __u64 size;
> + The overall size of the struct, including all attached items.
> +
> + __u64 conn_flags;
> + Flags to apply to this connection:
> +
> + KDBUS_HELLO_ACCEPT_FD
> + When this flag is set, the connection can be sent file descriptors
> + as message payload. If it's not set, any attempt of doing so will
> + result in -ECOMM on the sender's side.
> +
> + KDBUS_HELLO_ACTIVATOR
> + Make this connection an activator (see below). With this bit set,
> + an item of type KDBUS_ITEM_NAME has to be attached which describes
> + the well-known name this connection should be an activator for.
> +
> + KDBUS_HELLO_POLICY_HOLDER
> + Make this connection a policy holder (see below). With this bit set,
> + an item of type KDBUS_ITEM_NAME has to be attached which describes
> + the well-known name this connection should hold a policy for.
> +
> + KDBUS_HELLO_MONITOR
> + Make this connection an eaves-dropping connection that receives all
> + unicast messages sent on the bus. To also receive broadcast messages,
> + the connection has to upload appropriate matches as well.
> + This flag is only valid for privileged bus connections.
> +
> + __u64 attach_flags_send;
> + Set the bits for metadata this connection permits to be sent to the
> + receiving peer. Only metadata items that are both allowed to be sent by
> + the sender and that are requested by the receiver will effectively be
> + attached to the message eventually. Note, however, that the bus may
> + optionally enforce some of those bits to be set. If the match fails,
> + -ECONNREFUSED will be returned. In either case, this field will be set
> + to the mask of metadata items that are enforced by the bus. The
> + KDBUS_FLAGS_KERNEL bit will as well be set.
> +
> + __u64 attach_flags_recv;
> + Request the attachment of metadata for each message received by this
> + connection. The metadata actually attached may actually augment the list
> + of requested items. See section 13 for more details.
> +
> + __u64 bus_flags;
> + Upon successful completion of the ioctl, this member will contain the
> + flags of the bus it connected to.
> +
> + __u64 id;
> + Upon successful completion of the ioctl, this member will contain the
> + id of the new connection.
> +
> + __u64 pool_size;
> + The size of the communication pool, in bytes. The pool can be accessed
> + by calling mmap() on the file descriptor that was used to issue the
> + KDBUS_CMD_HELLO ioctl.
> +
> + struct kdbus_bloom_parameter bloom;
> + Bloom filter parameter (see below).
> +
> + __u8 id128[16];
> + Upon successful completion of the ioctl, this member will contain the
> + 128 bit wide UUID of the connected bus.
> +
> + struct kdbus_item items[0];
> + Variable list of items to add optional additional information. The
> + following items are currently expected/valid:
> +
> + KDBUS_ITEM_CONN_DESCRIPTION
> + Contains a string to describes this connection's name, so it can be
> + identified later.
> +
> + KDBUS_ITEM_NAME
> + KDBUS_ITEM_POLICY_ACCESS
> + For activators and policy holders only, combinations of these two
> + items describe policy access entries (see section about policy).
> +
> + KDBUS_ITEM_CREDS
> + KDBUS_ITEM_SECLABEL
> + Privileged bus users may submit these types in order to create
> + connections with faked credentials. The only real use case for this
> + is a proxy service which acts on behalf of some other tasks. For a
> + connection that runs in that mode, the message's metadata items will
> + be limited to what's specified here. See section 13 for more
> + information.
This is still confusing. There are multiple places in which metadata
is attached. Which does this apply to? And why are only creds and
seclabel listed?
> +
> +6.4 Retrieving information on a connection
> +------------------------------------------
> +
> +The KDBUS_CMD_CONN_INFO ioctl can be used to retrieve credentials and
> +properties of the initial creator of a connection. This ioctl uses the
> +following struct:
> +
> +struct kdbus_cmd_info {
> + __u64 size;
> + The overall size of the struct, including the name with its 0-byte string
> + terminator.
> +
> + __u64 flags;
> + Specify which metadata items should be attached to the answer.
> + See section 13 for more details.
> +
> + After the ioctl returns, this field will contain the current metadata
> + attach flags of the connection.
> +
> + __u64 kernel_flags;
> + Valid flags for this command, returned by the kernel upon each call.
> +
> + __u64 id;
> + The connection's numerical ID to retrieve information for. If set to
> + non-zero value, the 'name' field is ignored.
> +
> + __u64 offset;
> + When the ioctl returns, this value will yield the offset of the connection
> + information inside the caller's pool.
> +
> + struct kdbus_item items[0];
> + The optional item list, containing the well-known name to look up as
> + a KDBUS_ITEM_OWNED_NAME. Only required if the 'id' field is set to 0.
> + All other items are currently ignored.
> +};
> +
> +After the ioctl returns, the following struct will be stored in the caller's
> +pool at 'offset'.
> +
> +struct kdbus_info {
> + __u64 size;
> + The overall size of the struct, including all its items.
> +
> + __u64 id;
> + The connection's unique ID.
> +
> + __u64 flags;
> + The connection's flags as specified when it was created.
> +
> + __u64 kernel_flags;
> + Valid flags for this command, returned by the kernel upon each call.
> +
> + struct kdbus_item items[0];
> + Depending on the 'flags' field in struct kdbus_cmd_info, items of
> + types KDBUS_ITEM_OWNED_NAME and KDBUS_ITEM_CONN_DESCRIPTION are followed
> + here.
> +};
> +
> +Once the caller is finished with parsing the return buffer, it needs to call
> +KDBUS_CMD_FREE for the offset.
> +
> +
> +6.5 Getting information about a connection's bus creator
> +--------------------------------------------------------
> +
> +The KDBUS_CMD_BUS_CREATOR_INFO ioctl takes the same struct as
> +KDBUS_CMD_CONN_INFO but is used to retrieve information about the creator of
> +the bus the connection is attached to. The metadata returned by this call is
> +collected during the creation of the bus and is never altered afterwards, so
> +it provides pristine information on the task that created the bus, at the
> +moment when it did so.
What's this for? I understand the need for the creator of busses to
be authenticated, but doing it like this mean that anyone who will
*fail* authentication can DoS the authentic creator.
> +
> +7.3 Passing of Payload Data
> +---------------------------
> +
> +When connecting to the bus, receivers request a memory pool of a given size,
> +large enough to carry all backlog of data enqueued for the connection. The
> +pool is internally backed by a shared memory file which can be mmap()ed by
> +the receiver.
> +
> +KDBUS_MSG_PAYLOAD_VEC:
> + Messages are directly copied by the sending process into the receiver's pool,
> + that way two peers can exchange data by effectively doing a single-copy from
> + one process to another, the kernel will not buffer the data anywhere else.
> +
> +KDBUS_MSG_PAYLOAD_MEMFD:
> + Messages can reference memfd files which contain the data.
> + memfd files are tmpfs-backed files that allow sealing of the content of the
> + file, which prevents all writable access to the file content.
> + Only sealed memfd files are accepted as payload data, which enforces
> + reliable passing of data; the receiver can assume that neither the sender nor
> + anyone else can alter the content after the message is sent.
This should specify *which* seals are checked.
> +
> +Apart from the sender filling-in the content into memfd files, the data will
> +be passed as zero-copy from one process to another, read-only, shared between
> +the peers.
> +
> +
> +7.4 Receiving messages
> +----------------------
> +
> +Messages are received by the client with the KDBUS_CMD_MSG_RECV ioctl. The
> +endpoint file of the bus supports poll() to wake up the receiving process when
> +new messages are queued up to be received.
> +
> +With the KDBUS_CMD_MSG_RECV ioctl, a struct kdbus_cmd_recv is used.
> +
> +struct kdbus_cmd_recv {
> + __u64 flags;
> + Flags to control the receive command.
> +
> + KDBUS_RECV_PEEK
> + Just return the location of the next message. Do not install file
> + descriptors or anything else. This is usually used to determine the
> + sender of the next queued message.
> +
> + KDBUS_RECV_DROP
> + Drop the next message without doing anything else with it, and free the
> + pool slice. This a short-cut for KDBUS_RECV_PEEK and KDBUS_CMD_FREE.
> +
> + KDBUS_RECV_USE_PRIORITY
> + Use the priority field (see below).
> +
> + __u64 kernel_flags;
> + Valid flags for this command, returned by the kernel upon each call.
> +
> + __s64 priority;
> + With KDBUS_RECV_USE_PRIORITY set in flags, receive the next message in
> + the queue with at least the given priority. If no such message is waiting
> + in the queue, -ENOMSG is returned.
> +
> + __u64 offset;
> + Upon return of the ioctl, this field contains the offset in the
> + receiver's memory pool.
> +};
> +
> +Unless KDBUS_RECV_DROP was passed, and given that the ioctl succeeded, the
> +offset field contains the location of the new message inside the receiver's
> +pool. The message is stored as struct kdbus_msg at this offset, and can be
> +interpreted with the semantics described above.
I'm confused here. Is sent data written to the pool when send is
called or when recv is called?
If the former, what prevents DoS, especially DoS due to sending too many fds?
If the latter, where is the data buffered in the mean time?
> +
> +Also, if the connection allowed for file descriptor to be passed
> +(KDBUS_HELLO_ACCEPT_FD), and if the message contained any, they will be
> +installed into the receiving process after the KDBUS_CMD_MSG_RECV ioctl
> +returns. The receiving task is obliged to close all of them appropriately.
This makes it sound like fds are installed at receive time. What
prevents resource exhaustion due to having excessive numbers of fds in
transit (that are presumably not accounted to anyone)?
> +
> +7.5 Canceling messages synchronously waiting for replies
> +--------------------------------------------------------
> +
> +When a connection sends a message with KDBUS_MSG_FLAGS_SYNC_REPLY and
> +blocks while waiting for the reply, the KDBUS_CMD_MSG_CANCEL ioctl can be
> +used on the same file descriptor to cancel the message, based on its cookie.
> +If there are multiple messages with the same cookie that are all synchronously
> +waiting for a reply, all of them will be canceled. Obviously, this is only
> +possible in multi-threaded applications.
What does "cancel the message" mean? Does it just mean that the wait
for the reply is cancelled?
> +11. Policy
> +===============================================================================
> +
> +A policy databases restrict the possibilities of connections to own, see and
> +talk to well-known names. It can be associated with a bus (through a policy
> +holder connection) or a custom endpoint.
ISTM metadata items on bus names should be replaced with policy that
applies to the domain as a whole and governs bus creation.
> +A set of policy rules is described by a name and multiple access rules, defined
> +by the following struct.
> +
> +struct kdbus_policy_access {
> + __u64 type; /* USER, GROUP, WORLD */
> + One of the following.
> +
> + KDBUS_POLICY_ACCESS_USER
> + Grant access to a user with the uid stored in the 'id' field.
> +
> + KDBUS_POLICY_ACCESS_GROUP
> + Grant access to a user with the gid stored in the 'id' field.
> +
> + KDBUS_POLICY_ACCESS_WORLD
> + Grant access to everyone. The 'id' field is ignored.
> +
> + __u64 access; /* OWN, TALK, SEE */
> + The access to grant.
> +
> + KDBUS_POLICY_SEE
> + Allow the name to be seen.
> +
> + KDBUS_POLICY_TALK
> + Allow the name to be talked to.
> +
> + KDBUS_POLICY_OWN
> + Allow the name to be owned.
> +
> + __u64 id;
> + For KDBUS_POLICY_ACCESS_USER, stores the uid.
> + For KDBUS_POLICY_ACCESS_GROUP, stores the gid.
> +};
What happens if there are multiple matches?
> +
> +11.4 TALK access and multiple well-known names per connection
> +-------------------------------------------------------------
> +
> +Note that TALK access is checked against all names of a connection.
> +For example, if a connection owns both 'org.foo.bar' and 'org.blah.baz', and
> +the policy database allows 'org.blah.baz' to be talked to by WORLD, then this
> +permission is also granted to 'org.foo.bar'. That might sound illogical, but
> +after all, we allow messages to be directed to either the name or a well-known
> +name, and policy is applied to the connection, not the name. In other words,
> +the effective TALK policy for a connection is the most permissive of all names
> +the connection owns.
This does seem illogical. Does the recipient at least know which
well-known name was addressed?
> +11.5 Implicit policies
> +----------------------
> +
> +Depending on the type of the endpoint, a set of implicit rules might be
> +enforced. On default endpoints, the following set is enforced:
> +
How do these rules interact with installed policy?
> + * Privileged connections always override any installed policy. Those
> + connections could easily install their own policies, so there is no
> + reason to enforce installed policies.
> + * Connections can always talk to connections of the same user. This
> + includes broadcast messages.
Why? If anyone ever strengthens the concept of identity to include
things other than users (hmm -- there are already groups), this could
be very limiting.
> + * Connections that own names might send broadcast messages to other
> + connections that belong to a different user, but only if that
> + destination connection does not own any name.
> +
This is weird. It is also differently illogical than the "illogical"
thing above.
How about restricting access per name and making sure that the
receivers check what name was addressed before taking any action?
> +12. Pool
> +===============================================================================
> +
> +A pool for data received from the kernel is installed for every connection of
> +the bus, and is sized according to kdbus_cmd_hello.pool_size. It is accessed
> +when one of the following ioctls is issued:
> +
> + * KDBUS_CMD_MSG_RECV, to receive a message
> + * KDBUS_CMD_NAME_LIST, to dump the name registry
> + * KDBUS_CMD_CONN_INFO, to retrieve information on a connection
> +
> +Internally, the pool is organized in slices, stored in an rb-tree. The offsets
> +returned by either one of the aforementioned ioctls describe offsets inside the
> +pool. In order to make the slice available for subsequent calls, KDBUS_CMD_FREE
> +has to be called on the offset.
Why are you documenting that the slices are stored in an rb-tree?
That's just an implementation details, right?
> +
> +To access the memory, the caller is expected to mmap() it to its task, like
> +this:
> +
> + /*
> + * POOL_SIZE has to be a multiple of PAGE_SIZE, and it must match the
> + * value that was previously passed in the .pool_size field of struct
> + * kdbus_cmd_hello.
> + */
> +
> + buf = mmap(NULL, POOL_SIZE, PROT_READ, MAP_PRIVATE, conn_fd, 0);
> +
Will mapping with PROT_WRITE fail? What about MAP_SHARED?
And why are you suggesting MAP_PRIVATE? That's just strange.
> +
> +13. Metadata
> +===============================================================================
> +
> +When a message is delivered to a receiver connection, it is augmented by
> +metadata items in accordance to the destination's current attach flags. The
> +information stored in those metadata items refer to the sender task at the
> +time of sending the message, so even if any detail of the sender task has
> +already changed upon message reception (or if the sender task does not exist
> +anymore), the information is still preserved and won't be modfied until the
> +message is freed.
> +
> +Note that there are two exceptions to the above rules:
> +
> + a) Kernel generated messages don't have a source connection, so they won't be
> + augmented.
> +
> + b) If a connection was created with faked credentials (see section 6.2),
> + the only attached metadata items are the ones provided by the connection
> + itself. Other bits in the destination's attach_flags_recv won't have any
> + effect in such cases.
> +
> +Also, there are two things to be considered by userspace programs regarding
> +those metadata items:
> +
> + a) Userspace must cope with the fact that it might get more metadata than
> + they requested. That happens, for example, when a broadcast message is
> + sent and receivers have different attach flags. Items that haven't been
> + requested should hence be silently ignored.
> +
> + b) Userspace might not always get all requested metadata items that it
> + requested. That is because some of those items are only added if a
> + corresponding kernel feature has been enabled. Also, the two exceptions
> + described above will as well lead to less items be attached than
> + requested.
> +
> +
> +13.1 Known item types
> +---------------------
> +
> +The following attach flags are currently supported.
> +
> + KDBUS_ATTACH_TIMESTAMP
> + Attaches an item of type KDBUS_ITEM_TIMESTAMP which contains both the
> + monotonic and the realtime timestamp, taken when the message was
> + processed on the kernel side.
> +
> + KDBUS_ATTACH_CREDS
> + Attaches an item of type KDBUS_ITEM_CREDS, containing credentials as
> + described in kdbus_creds: the uid, gid, pid, tid and starttime of the task.
> +
As mentioned last time, please remove or justify starttime.
> + KDBUS_ATTACH_AUXGROUPS
> + Attaches an item of type KDBUS_ITEM_AUXGROUPS, containing a dynamic
> + number of auxiliary groups the sending task was a member of.
> +
> + KDBUS_ATTACH_NAMES
> + Attaches items of type KDBUS_ITEM_OWNED_NAME, one for each name the sending
> + connection currently owns. The name and flags are stored in kdbus_item.name
> + for each of them.
> +
That's interesting. What's it for?
> + KDBUS_ATTACH_TID_COMM
> + Attaches an items of type KDBUS_ITEM_TID_COMM, transporting the sending
> + task's 'comm', for the tid. The string is stored in kdbus_item.str.
> +
> + KDBUS_ATTACH_PID_COMM
> + Attaches an items of type KDBUS_ITEM_PID_COMM, transporting the sending
> + task's 'comm', for the pid. The string is stored in kdbus_item.str.
> +
> + KDBUS_ATTACH_EXE
> + Attaches an item of type KDBUS_ITEM_EXE, containing the path to the
> + executable of the sending task, stored in kdbus_item.str.
> +
> + KDBUS_ATTACH_CMDLINE
> + Attaches an item of type KDBUS_ITEM_CMDLINE, containing the command line
> + arguments of the sending task, as an array of strings, stored in
> + kdbus_item.str.
Please remove these four items. They are genuinely useless. Anything
that uses them for anything is either buggy or should have asked the
sender to put the value in the payload (and immediately wondered why
it was doing that).
> +
> + KDBUS_ATTACH_CGROUP
> + Attaches an item of type KDBUS_ITEM_CGROUP with the task's cgroup path.
> +
> + KDBUS_ATTACH_CAPS
> + Attaches an item of type KDBUS_ITEM_CAPS, carrying sets of capabilities
> + that should be accessed via kdbus_item.caps.caps. Also, userspace should
> + be written in a way that it takes kdbus_item.caps.last_cap into account,
> + and derive the number of sets and rows from the item size and the reported
> + number of valid capability bits.
> +
Please remove this, too, or justify its use.
> + KDBUS_ATTACH_SECLABEL
> + Attaches an item of type KDBUS_ITEM_SECLABEL, which contains the SELinux
> + security label of the sending task. Access via kdbus_item->str.
> +
This one, too, and please justify why code that uses it will work in
containers an on non-selinux systems.
> + KDBUS_ATTACH_AUDIT
> + Attaches an item of type KDBUS_ITEM_AUDIT, which contains the audio label
> + of the sending taskj. Access via kdbus_item->str.
> +
I will NAK the hell out of this until, at the very least, someone
documents what this means, how to parse it, what its stability rules
are, who is allowed to see the value it contains, why that value will
never evolve to become *more* security sensitive than it is now, etc.
Audit gets to do crazy sh*t because it's restricted to privileged
receivers. This isn't restricted like that, so it doesn't deserve the
same dispensation. (And, honestly, I'm not sure that audit really
deserves its free pass on making sense.)
> + KDBUS_ATTACH_CONN_DESCRIPTION
> + Attaches an item of type KDBUS_ITEM_CONN_DESCRIPTION that contains the
> + sender connection's current name in kdbus_item.str.
> +
Which name? Can't there be several?
> +
> +13.1 Metadata and namespaces
> +----------------------------
> +
> +Metadata such as PIDs, UIDs or GIDs are automatically translated to the
> +namespaces of the domain that is used to send a message over. The namespaces
> +of a domain are pinned at creation time, which is when the filesystem has been
> +mounted.
> +
> +Metadata items that cannot be translated are dropped.
What if the receiver said that the item was mandatory?
Thanks,
Andy
^ permalink raw reply
* Re: kdbus: add node and filesystem implementation
From: Sasha Levin @ 2014-11-21 17:03 UTC (permalink / raw)
To: Greg Kroah-Hartman, David Herrmann
Cc: Arnd Bergmann, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
One Thousand Gnomes, Tom Gundersen, Jiri Kosina, Andy Lutomirski,
Linux API, linux-kernel, Daniel Mack, Djalal Harouni
In-Reply-To: <20141121165638.GA24866-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On 11/21/2014 11:56 AM, Greg Kroah-Hartman wrote:
>>> Maybe it's worth basing your git tree on top of Al's rather than a random
>>> > > -rc, since it's now a filesystem?
>> >
>> > Sure, sounds good.
> No, I'll keep it as is, we can handle the merge issues later when it
> hits Linus's tree, this makes it easier for me and others to test it
> out properly.
It should be hitting -next, not Linus's tree. This is why we have an
integration tree, no?
Thanks,
Sasha
^ permalink raw reply
* Re: kdbus: add node and filesystem implementation
From: Greg Kroah-Hartman @ 2014-11-21 16:56 UTC (permalink / raw)
To: David Herrmann
Cc: Sasha Levin, Arnd Bergmann, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
One Thousand Gnomes, Tom Gundersen, Jiri Kosina, Andy Lutomirski,
Linux API, linux-kernel, Daniel Mack, Djalal Harouni
In-Reply-To: <CANq1E4QkXv9Ak6eT+NZPsy+5nTGKE8oypLvdr97cFcvmtigS_A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Nov 21, 2014 at 05:13:26PM +0100, David Herrmann wrote:
> Hi
>
> On Fri, Nov 21, 2014 at 4:55 PM, Sasha Levin <sasha.levin-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
> > On 11/21/2014 12:02 AM, Greg Kroah-Hartman wrote:
> >> +static struct dentry *fs_dir_iop_lookup(struct inode *dir,
> >> + struct dentry *dentry,
> >> + unsigned int flags)
> >> +{
> >> + struct dentry *dnew = NULL;
> >> + struct kdbus_node *parent;
> >> + struct kdbus_node *node;
> >> + struct inode *inode;
> >> +
> >> + parent = kdbus_node_from_dentry(dentry->d_parent);
> >> + if (!kdbus_node_acquire(parent))
> >> + return NULL;
> >> +
> >> + /* returns reference to _acquired_ child node */
> >> + node = kdbus_node_find_child(parent, dentry->d_name.name);
> >> + if (node) {
> >> + dentry->d_fsdata = node;
> >> + inode = fs_inode_get(dir->i_sb, node);
> >> + if (IS_ERR(inode))
> >> + dnew = ERR_CAST(inode);
> >> + else
> >> + dnew = d_materialise_unique(dentry, inode);
> >
> > d_materialise_unique() is gone in Al's fs tree:
> >
> > [mandatory]
> > d_materialise_unique() is gone; d_splice_alias() does everything you
> > need now. Remember that they have opposite orders of arguments ;-/
>
> That was actually pushed after we prepared v2, so I haven't seen it
> yet. I now rebased on top of vfs.git#for-next, with
> d_materialise_unique() -> d_splice_alias(). Thanks for the hint!
>
> > Maybe it's worth basing your git tree on top of Al's rather than a random
> > -rc, since it's now a filesystem?
>
> Sure, sounds good.
No, I'll keep it as is, we can handle the merge issues later when it
hits Linus's tree, this makes it easier for me and others to test it
out properly.
thanks,
greg k-h
^ permalink raw reply
* Re: kdbus: add node and filesystem implementation
From: David Herrmann @ 2014-11-21 16:53 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Greg Kroah-Hartman, Arnd Bergmann, Eric W. Biederman,
One Thousand Gnomes, Tom Gundersen, Jiri Kosina, Linux API,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Daniel Mack,
Djalal Harouni
In-Reply-To: <CALCETrW-RkhKa4n7X1HoPgmSuLV4V8YQ=FaSYVJ1YsHS=pJCSQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi
On Fri, Nov 21, 2014 at 5:35 PM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
> On Thu, Nov 20, 2014 at 9:02 PM, Greg Kroah-Hartman
> <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
>> From: Daniel Mack <daniel-cYrQPVfZoowdnm+yROfE0A@public.gmane.org>
>>
>> kdbusfs is a filesystem that will expose a fresh kdbus domain context
>> each time it is mounted. Per mount point, there will be a 'control'
>> node, which can be used to create buses. fs.c contains the
>> implementation of that pseudo-fs. Exported inodes of 'file' type have
>> their i_fop set to either kdbus_handle_control_ops or
>> kdbus_handle_ep_ops, depending on their type. The actual dispatching
>> of file operations is done from handle.c
>>
>> node.c is an implementation of a kdbus object that has an id and
>> children, organized in an R/B tree. The tree is used by the filesystem
>> code for lookup and iterator functions, and to deactivate children
>> once the parent is deactivated. Every inode exported by kdbusfs is
>> backed by a kdbus_node, hence it is embedded in struct kdbus_ep,
>> struct kdbus_bus and struct kdbus_domain.
>>
>> Signed-off-by: Daniel Mack <daniel-cYrQPVfZoowdnm+yROfE0A@public.gmane.org>
>> Signed-off-by: David Herrmann <dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Signed-off-by: Djalal Harouni <tixxdz-Umm1ozX2/EEdnm+yROfE0A@public.gmane.org>
>> Signed-off-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
>> ---
>
>
>> +
>> +static struct file_system_type fs_type = {
>> + .name = KBUILD_MODNAME "fs",
>> + .owner = THIS_MODULE,
>> + .mount = fs_super_mount,
>> + .kill_sb = fs_super_kill,
>> +};
>
> Does this want something like:
>
> .fs_flags = FS_USERNS_MOUNT
Yes, we should add that. Nice catch!
> This design may have the annoying property that, if a namespace-based
> sandbox wants to use kdbus itself, it will need to proxy anything from
> the parent that it wants to use.
>
> Is there a good reason why individual *busses* don't show up in the
> filesystem? If they did, maybe they could be bind-mounted or
> otherwise arranged to cross namespace boundaries.
Buses show up as directories in kdbusfs. You can bind-mount them
anywhere you want and you will get access to the endpoints in there.
Thanks
David
^ permalink raw reply
* Re: kdbus: add node and filesystem implementation
From: Andy Lutomirski @ 2014-11-21 16:41 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Arnd Bergmann, Eric W. Biederman, One Thousand Gnomes,
Tom Gundersen, Jiri Kosina, Linux API,
linux-kernel@vger.kernel.org, Daniel Mack, David Herrmann,
Djalal Harouni
In-Reply-To: <CALCETrW-RkhKa4n7X1HoPgmSuLV4V8YQ=FaSYVJ1YsHS=pJCSQ@mail.gmail.com>
On Fri, Nov 21, 2014 at 8:35 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Thu, Nov 20, 2014 at 9:02 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>> From: Daniel Mack <daniel@zonque.org>
>>
>> kdbusfs is a filesystem that will expose a fresh kdbus domain context
>> each time it is mounted. Per mount point, there will be a 'control'
>> node, which can be used to create buses. fs.c contains the
>> implementation of that pseudo-fs. Exported inodes of 'file' type have
>> their i_fop set to either kdbus_handle_control_ops or
>> kdbus_handle_ep_ops, depending on their type. The actual dispatching
>> of file operations is done from handle.c
>>
>> node.c is an implementation of a kdbus object that has an id and
>> children, organized in an R/B tree. The tree is used by the filesystem
>> code for lookup and iterator functions, and to deactivate children
>> once the parent is deactivated. Every inode exported by kdbusfs is
>> backed by a kdbus_node, hence it is embedded in struct kdbus_ep,
>> struct kdbus_bus and struct kdbus_domain.
>>
>> Signed-off-by: Daniel Mack <daniel@zonque.org>
>> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
>> Signed-off-by: Djalal Harouni <tixxdz@opendz.org>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> ---
>
>
>> +
>> +static struct file_system_type fs_type = {
>> + .name = KBUILD_MODNAME "fs",
>> + .owner = THIS_MODULE,
>> + .mount = fs_super_mount,
>> + .kill_sb = fs_super_kill,
>> +};
>
> Does this want something like:
>
> .fs_flags = FS_USERNS_MOUNT
>
> This design may have the annoying property that, if a namespace-based
> sandbox wants to use kdbus itself, it will need to proxy anything from
> the parent that it wants to use.
>
> Is there a good reason why individual *busses* don't show up in the
> filesystem? If they did, maybe they could be bind-mounted or
> otherwise arranged to cross namespace boundaries.
>
Whoops. Brainfart there -- busses do show up in the filesystem. Does
bind-mounting them work?
--Andy
^ permalink raw reply
* Re: kdbus: add node and filesystem implementation
From: Andy Lutomirski @ 2014-11-21 16:35 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Arnd Bergmann, Eric W. Biederman, One Thousand Gnomes,
Tom Gundersen, Jiri Kosina, Linux API,
linux-kernel@vger.kernel.org, Daniel Mack, David Herrmann,
Djalal Harouni
In-Reply-To: <1416546149-24799-7-git-send-email-gregkh@linuxfoundation.org>
On Thu, Nov 20, 2014 at 9:02 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> From: Daniel Mack <daniel@zonque.org>
>
> kdbusfs is a filesystem that will expose a fresh kdbus domain context
> each time it is mounted. Per mount point, there will be a 'control'
> node, which can be used to create buses. fs.c contains the
> implementation of that pseudo-fs. Exported inodes of 'file' type have
> their i_fop set to either kdbus_handle_control_ops or
> kdbus_handle_ep_ops, depending on their type. The actual dispatching
> of file operations is done from handle.c
>
> node.c is an implementation of a kdbus object that has an id and
> children, organized in an R/B tree. The tree is used by the filesystem
> code for lookup and iterator functions, and to deactivate children
> once the parent is deactivated. Every inode exported by kdbusfs is
> backed by a kdbus_node, hence it is embedded in struct kdbus_ep,
> struct kdbus_bus and struct kdbus_domain.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
> Signed-off-by: Djalal Harouni <tixxdz@opendz.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> +
> +static struct file_system_type fs_type = {
> + .name = KBUILD_MODNAME "fs",
> + .owner = THIS_MODULE,
> + .mount = fs_super_mount,
> + .kill_sb = fs_super_kill,
> +};
Does this want something like:
.fs_flags = FS_USERNS_MOUNT
This design may have the annoying property that, if a namespace-based
sandbox wants to use kdbus itself, it will need to proxy anything from
the parent that it wants to use.
Is there a good reason why individual *busses* don't show up in the
filesystem? If they did, maybe they could be bind-mounted or
otherwise arranged to cross namespace boundaries.
--Andy
^ permalink raw reply
* Re: kdbus: add node and filesystem implementation
From: David Herrmann @ 2014-11-21 16:13 UTC (permalink / raw)
To: Sasha Levin
Cc: Greg Kroah-Hartman, Arnd Bergmann,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, One Thousand Gnomes,
Tom Gundersen, Jiri Kosina, Andy Lutomirski, Linux API,
linux-kernel, Daniel Mack, Djalal Harouni
In-Reply-To: <546F606D.40407-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Hi
On Fri, Nov 21, 2014 at 4:55 PM, Sasha Levin <sasha.levin-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
> On 11/21/2014 12:02 AM, Greg Kroah-Hartman wrote:
>> +static struct dentry *fs_dir_iop_lookup(struct inode *dir,
>> + struct dentry *dentry,
>> + unsigned int flags)
>> +{
>> + struct dentry *dnew = NULL;
>> + struct kdbus_node *parent;
>> + struct kdbus_node *node;
>> + struct inode *inode;
>> +
>> + parent = kdbus_node_from_dentry(dentry->d_parent);
>> + if (!kdbus_node_acquire(parent))
>> + return NULL;
>> +
>> + /* returns reference to _acquired_ child node */
>> + node = kdbus_node_find_child(parent, dentry->d_name.name);
>> + if (node) {
>> + dentry->d_fsdata = node;
>> + inode = fs_inode_get(dir->i_sb, node);
>> + if (IS_ERR(inode))
>> + dnew = ERR_CAST(inode);
>> + else
>> + dnew = d_materialise_unique(dentry, inode);
>
> d_materialise_unique() is gone in Al's fs tree:
>
> [mandatory]
> d_materialise_unique() is gone; d_splice_alias() does everything you
> need now. Remember that they have opposite orders of arguments ;-/
That was actually pushed after we prepared v2, so I haven't seen it
yet. I now rebased on top of vfs.git#for-next, with
d_materialise_unique() -> d_splice_alias(). Thanks for the hint!
> Maybe it's worth basing your git tree on top of Al's rather than a random
> -rc, since it's now a filesystem?
Sure, sounds good.
Thanks
David
^ permalink raw reply
* Re: kdbus: add node and filesystem implementation
From: Sasha Levin @ 2014-11-21 15:55 UTC (permalink / raw)
To: Greg Kroah-Hartman, arnd-r2nGTMty4D4,
ebiederm-aS9lmoZGLiVWk0Htik3J/w,
gnomes-qBU/x9rampVanCEyBjwyrvXRex20P6io, teg-B22kvLQNl6c,
jkosina-AlSwsSmVLrQ, luto-kltTT9wpgjJwATOyAt5JVQ,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: daniel-cYrQPVfZoowdnm+yROfE0A, dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w,
tixxdz-Umm1ozX2/EEdnm+yROfE0A
In-Reply-To: <1416546149-24799-7-git-send-email-gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
On 11/21/2014 12:02 AM, Greg Kroah-Hartman wrote:
> +static struct dentry *fs_dir_iop_lookup(struct inode *dir,
> + struct dentry *dentry,
> + unsigned int flags)
> +{
> + struct dentry *dnew = NULL;
> + struct kdbus_node *parent;
> + struct kdbus_node *node;
> + struct inode *inode;
> +
> + parent = kdbus_node_from_dentry(dentry->d_parent);
> + if (!kdbus_node_acquire(parent))
> + return NULL;
> +
> + /* returns reference to _acquired_ child node */
> + node = kdbus_node_find_child(parent, dentry->d_name.name);
> + if (node) {
> + dentry->d_fsdata = node;
> + inode = fs_inode_get(dir->i_sb, node);
> + if (IS_ERR(inode))
> + dnew = ERR_CAST(inode);
> + else
> + dnew = d_materialise_unique(dentry, inode);
d_materialise_unique() is gone in Al's fs tree:
[mandatory]
d_materialise_unique() is gone; d_splice_alias() does everything you
need now. Remember that they have opposite orders of arguments ;-/
Maybe it's worth basing your git tree on top of Al's rather than a random
-rc, since it's now a filesystem?
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCHv2 2/3] selftests: Add test of O_BENEATH & openat(2)
From: David Drysdale @ 2014-11-21 14:19 UTC (permalink / raw)
To: Dave Chinner
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Alexander Viro, Kees Cook, Eric W. Biederman, Greg Kroah-Hartman,
Meredydd Luff, Will Drewry, Jorge Lucangeli Obes, Ricky Zhou,
Lee Campbell, Julien Tinnes, Mike Depinet, James Morris,
Andy Lutomirski, Paolo Bonzini, Paul Moore, Christoph Hellwig,
Linux API, LSM List, fstests-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20141111053641.GR23575@dastard>
On Tue, Nov 11, 2014 at 5:36 AM, Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org> wrote:
> [cc fstests-u79uwXL29TY76Z2rM5mHXA@public.gmane.org]
>
> On Tue, Nov 04, 2014 at 09:54:43AM +0000, David Drysdale wrote:
>> Add simple tests of openat(2) variations, including examples that
>> check the new O_BENEATH flag.
>>
>> Signed-off-by: David Drysdale <drysdale-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
>
> Wouldn't this be better added to fstests? That's the regression
> test suite used by filesystem developers and most distro QA
> organisations and where the fs developers aggregate all their new
> regression tests.
>
> IMO, the fewer places we aggregate VFS/filesystem tests the better.
> I really don't think the kernel tree is the best place for adding
> VFS behavioural tests because it has none of the infrastructure
> around it to test arbitrary filesystems and configurations and hence
> is not particularly useful to the people whoa re likely to notice
> and care about fs regression tests suddenly breaking.
>
> As an example, the recent renameat() syscall additions (e.g.
> RENAME_EXCHANGE, RENAME_NOREPLACE) have unit tests in fstests, so
> these new O_BENEATH tests should really follow the same model...
>
> Cheers,
>
> Dave.
Fair enough, that makes sense -- I've now got a version of the selftest
running within xfstests (git://oss.sgi.com/xfs/cmds/xfstests.git is the
master repo, right?).
Given that xfstests is independent of the kernel, what's the expected
way to deal with flags (or syscalls) that are only in specific kernel
versions? At the moment I've just got a primitive override at
compile time (#ifndef O_BENEATH #define O_BENEATH ...), and
then the test will fail at run-time against an older kernel -- is there a
need for anything more sophisticated? (And if so, are there any
examples I can crib from?)
Also, is there an archive of the fstests@ mailing list somewhere?
Thanks,
David
^ permalink raw reply
* RFC: renameat(): Add a RENAME_REMOVE flag to unlink hardlinks
From: Pádraig Brady @ 2014-11-21 14:17 UTC (permalink / raw)
To: Linux API
[-- Attachment #1: Type: text/plain, Size: 438 bytes --]
If 'a' and 'b' are hardlinks, then the command `mv a b & mv b a`
can result in both being removed as mv needs to emulate the
move with an unlink of the source file. This can only be done
without races in the kernel and so mv was recently changed
to not allow this operation at all. mv could safely reintroduce
this feature by leveraging a new flag for renameat() for which
an illustrative/untested patch is attached.
thanks,
Pádraig.
[-- Attachment #2: renameat_REMOVE.patch --]
[-- Type: text/x-patch, Size: 2618 bytes --]
>From 26d552617b00b3ffcd3b4646467cab5cb02f33ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= <P@draigBrady.com>
Date: Fri, 21 Nov 2014 14:09:54 +0000
Subject: [PATCH] renameat: Add RENAME_REMOVE flag to unlink source if hardlink
to dest
This operation can't be done in userspace with unlink without races,
as overlapping rename operations could remove both hardlinks.
---
Documentation/filesystems/vfs.txt | 1 +
fs/namei.c | 11 +++++++----
include/uapi/linux/fs.h | 1 +
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index 20bf204..2daa41a 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -430,6 +430,7 @@ otherwise noted.
(2) RENAME_EXCHANGE: exchange source and target. Both must
exist; this is checked by the VFS. Unlike plain rename,
source and target may be of different type.
+ (4) RENAME_REMOVE: unlink source even if a hardlink to dest.
readlink: called by the readlink(2) system call. Only required if
you want to support reading symbolic links
diff --git a/fs/namei.c b/fs/namei.c
index db5fe86..caed596 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -4074,8 +4074,10 @@ int vfs_rename(struct inode *old_dir, struct dentry *old_dentry,
bool new_is_dir = false;
unsigned max_links = new_dir->i_sb->s_max_links;
- if (source == target)
- return 0;
+ if (source == target) {
+ if (old_dentry == new_dentry || !(flags & RENAME_REMOVE))
+ return 0;
+ }
error = may_delete(old_dir, old_dentry, is_dir);
if (error)
@@ -4210,10 +4212,11 @@ SYSCALL_DEFINE5(renameat2, int, olddfd, const char __user *, oldname,
bool should_retry = false;
int error;
- if (flags & ~(RENAME_NOREPLACE | RENAME_EXCHANGE | RENAME_WHITEOUT))
+ if (flags & ~(RENAME_NOREPLACE | RENAME_EXCHANGE |
+ RENAME_WHITEOUT | RENAME_REMOVE))
return -EINVAL;
- if ((flags & (RENAME_NOREPLACE | RENAME_WHITEOUT)) &&
+ if ((flags & (RENAME_NOREPLACE | RENAME_WHITEOUT | RENAME_REMOVE)) &&
(flags & RENAME_EXCHANGE))
return -EINVAL;
diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index 3735fa0..601d901 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -38,6 +38,7 @@
#define RENAME_NOREPLACE (1 << 0) /* Don't overwrite target */
#define RENAME_EXCHANGE (1 << 1) /* Exchange source and dest */
#define RENAME_WHITEOUT (1 << 2) /* Whiteout source */
+#define RENAME_REMOVE (1 << 3) /* Remove source hardlink */
struct fstrim_range {
__u64 start;
--
2.1.0
^ permalink raw reply related
* Re: [musl] Re: [RFC] Possible new execveat(2) Linux syscall
From: Rich Felker @ 2014-11-21 14:15 UTC (permalink / raw)
To: David Drysdale
Cc: Christoph Hellwig, libc-alpha, Andrew Morton, Linux API,
Andy Lutomirski, musl-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8
In-Reply-To: <CAHse=S9RATqvXSrFXxDOcWx7Ub94Yhyr_-=USib-PPMx+_CC-w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Nov 21, 2014 at 01:49:35PM +0000, David Drysdale wrote:
> On Fri, Nov 21, 2014 at 10:13 AM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> > On Sun, Nov 16, 2014 at 02:52:46PM -0500, Rich Felker wrote:
> >> I've been following the discussions so far and everything looks mostly
> >> okay. There are still issues to be resolved with the different
> >> semantics between Linux O_PATH and what POSIX requires for O_EXEC (and
> >> O_SEARCH) but as long as the intent is that, once O_EXEC is defined to
> >> save the permissions at the time of open and cause them to be used in
> >> place of the current file permissions at the time of execveat
> >
> > As far as I can tell we only need the little patch below to make Linux
> > O_PATH a valid O_SEARCH implementation. Rich, you said you wanted to
> > look over it?
> >
> > For O_EXEC my interpretation is that we basically just need this new
> > execveat syscall + a patch to add FMODE_EXEC and enforce it. So we
> > wouldn't even need the O_PATH|3 hack. But unless someone more familar
> > with the arcane details of the Posix language verifies it I'm tempted to
> > give up trying to help to implent these flags :(
>
> I'm not particularly familiar with POSIX details either, but I thought the
> O_PATH|3 hack would be needed for the interaction with O_ACCMODE -- just
> using FMODE_EXEC as O_EXEC would confuse existing code that examines
> (flags & O_ACCMODE).
To conform to POSIX, O_ACCMODE needs to contain all the bits of
O_RDONLY|O_WRONLY|O_RDWR|O_SEARCH|O_EXEC. Certainly it's possible that
code compiled with an old definition of O_ACCMODE as 3 could inherit
(or otherwise obtain) a file descriptor in O_SEARCH/O_EXEC mode, so
it's preferable to have the low 2 bits be distinct from the existing
access modes, but O_ACCMODE's definition (at least in userspace)
really does need to be updated to equal O_PATH|3.
> >From [1]:
> "Applications shall specify exactly one of the ...five ... file access
> modes ... O_EXEC / O_RDONLY / O_RDWR / O_SEARCH / O_WRONLY"
> (and O_EXEC and O_SEARCH are allowed to be the same value,
> as one only applies to files and the other only applies to directories).
>
> As O_ACCMODE is 3, there are only 4 possible access modes that work
> with any existing code that checks (flags & O_ACCMODE), and 3 of the
> values are taken (0=O_RDONLY, 1=O_WRONLY, 2=O_RDWR). So I
> guess that's where the idea for the |3 hack comes from.
3 is also "taken" too, but it's a mostly-undocumented hack.
Rich
^ permalink raw reply
* Re: [musl] Re: [RFC] Possible new execveat(2) Linux syscall
From: Rich Felker @ 2014-11-21 14:11 UTC (permalink / raw)
To: Christoph Hellwig
Cc: David Drysdale, libc-alpha-9JcytcrH/bA+uJoB2kUjGw, Andrew Morton,
Linux API, Andy Lutomirski, musl-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8
In-Reply-To: <20141121101318.GG8866-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
On Fri, Nov 21, 2014 at 02:13:18AM -0800, Christoph Hellwig wrote:
> On Sun, Nov 16, 2014 at 02:52:46PM -0500, Rich Felker wrote:
> > I've been following the discussions so far and everything looks mostly
> > okay. There are still issues to be resolved with the different
> > semantics between Linux O_PATH and what POSIX requires for O_EXEC (and
> > O_SEARCH) but as long as the intent is that, once O_EXEC is defined to
> > save the permissions at the time of open and cause them to be used in
> > place of the current file permissions at the time of execveat
>
> As far as I can tell we only need the little patch below to make Linux
> O_PATH a valid O_SEARCH implementation. Rich, you said you wanted to
> look over it?
I think the below looks correct, but it's not complete. The *at
functions also need to use FMODE_EXEC rather than rechecking +x
permissions at the time of the operation.
> For O_EXEC my interpretation is that we basically just need this new
> execveat syscall + a patch to add FMODE_EXEC and enforce it. So we
> wouldn't even need the O_PATH|3 hack. But unless someone more familar
> with the arcane details of the Posix language verifies it I'm tempted to
> give up trying to help to implent these flags :(
O_EXEC/O_SEARCH cannot be equal to O_PATH, because of differing
semantics on open. With O_NOFOLLOW, O_PATH yields a file descriptor
referring to the symlink itself. With O_EXEC or O_SEARCH, O_NOFOLLOW
is required to make open fail if the target is a symlink. It would be
a serious regression to eliminate the ability of O_PATH to open
symlinks like this.
Note that enforcing O_NOFOLLOW failure on symlinks can be implemented
in userspace instead of (or in addition to, for better behavior with
old kernels) kernelspace, but it still requires a different value from
O_PATH or userspace would be eliminating access to an important O_PATH
feature.
Further, O_PATH|3 was the best value I could find to yield nearly
reasonable fallback behavior on most old kernels. Simply using 3 fails
to open directories and files to which the caller does not have write
permission (mode 3 is a nearly-undocumented hack for opening devices
for ioctl-only read-write access, it seems). On pre-O_PATH kernels,
using O_PATH|3 would fallback to this failing case, yielding spurious
failure-to-open for all O_SEARCH and some O_EXEC operations, but those
kernels are old enough to be irrelevant to most users anyway. On
kernels that do have O_PATH, using O_PATH|3 ignores the 3 and yields
the current O_PATH semantics, which are nearly correct.
Of course O_PATH|1 or O_PATH|2 would also work in principle, as would
adding a completely new bit in addition to O_PATH, but these all seem
less desirable.
Rich
^ permalink raw reply
* Re: [RFC] Possible new execveat(2) Linux syscall
From: David Drysdale @ 2014-11-21 13:49 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Rich Felker, libc-alpha, Andrew Morton, Linux API,
Andy Lutomirski, musl-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8
In-Reply-To: <20141121101318.GG8866-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
On Fri, Nov 21, 2014 at 10:13 AM, Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> On Sun, Nov 16, 2014 at 02:52:46PM -0500, Rich Felker wrote:
>> I've been following the discussions so far and everything looks mostly
>> okay. There are still issues to be resolved with the different
>> semantics between Linux O_PATH and what POSIX requires for O_EXEC (and
>> O_SEARCH) but as long as the intent is that, once O_EXEC is defined to
>> save the permissions at the time of open and cause them to be used in
>> place of the current file permissions at the time of execveat
>
> As far as I can tell we only need the little patch below to make Linux
> O_PATH a valid O_SEARCH implementation. Rich, you said you wanted to
> look over it?
>
> For O_EXEC my interpretation is that we basically just need this new
> execveat syscall + a patch to add FMODE_EXEC and enforce it. So we
> wouldn't even need the O_PATH|3 hack. But unless someone more familar
> with the arcane details of the Posix language verifies it I'm tempted to
> give up trying to help to implent these flags :(
I'm not particularly familiar with POSIX details either, but I thought the
O_PATH|3 hack would be needed for the interaction with O_ACCMODE -- just
using FMODE_EXEC as O_EXEC would confuse existing code that examines
(flags & O_ACCMODE).
>From [1]:
"Applications shall specify exactly one of the ...five ... file access
modes ... O_EXEC / O_RDONLY / O_RDWR / O_SEARCH / O_WRONLY"
(and O_EXEC and O_SEARCH are allowed to be the same value,
as one only applies to files and the other only applies to directories).
As O_ACCMODE is 3, there are only 4 possible access modes that work
with any existing code that checks (flags & O_ACCMODE), and 3 of the
values are taken (0=O_RDONLY, 1=O_WRONLY, 2=O_RDWR). So I
guess that's where the idea for the |3 hack comes from.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html
^ permalink raw reply
* Re: [RFC] Possible new execveat(2) Linux syscall
From: Christoph Hellwig @ 2014-11-21 10:13 UTC (permalink / raw)
To: Rich Felker
Cc: David Drysdale, libc-alpha, Andrew Morton, Christoph Hellwig,
Linux API, Andy Lutomirski, musl
In-Reply-To: <20141116195246.GX22465@brightrain.aerifal.cx>
On Sun, Nov 16, 2014 at 02:52:46PM -0500, Rich Felker wrote:
> I've been following the discussions so far and everything looks mostly
> okay. There are still issues to be resolved with the different
> semantics between Linux O_PATH and what POSIX requires for O_EXEC (and
> O_SEARCH) but as long as the intent is that, once O_EXEC is defined to
> save the permissions at the time of open and cause them to be used in
> place of the current file permissions at the time of execveat
As far as I can tell we only need the little patch below to make Linux
O_PATH a valid O_SEARCH implementation. Rich, you said you wanted to
look over it?
For O_EXEC my interpretation is that we basically just need this new
execveat syscall + a patch to add FMODE_EXEC and enforce it. So we
wouldn't even need the O_PATH|3 hack. But unless someone more familar
with the arcane details of the Posix language verifies it I'm tempted to
give up trying to help to implent these flags :(
diff --git a/fs/open.c b/fs/open.c
index d6fd3ac..ee24720 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -512,7 +512,7 @@ out_unlock:
SYSCALL_DEFINE2(fchmod, unsigned int, fd, umode_t, mode)
{
- struct fd f = fdget(fd);
+ struct fd f = fdget_raw(fd);
int err = -EBADF;
if (f.file) {
@@ -633,7 +633,7 @@ SYSCALL_DEFINE3(lchown, const char __user *, filename, uid_t, user, gid_t, group
SYSCALL_DEFINE3(fchown, unsigned int, fd, uid_t, user, gid_t, group)
{
- struct fd f = fdget(fd);
+ struct fd f = fdget_raw(fd);
int error = -EBADF;
if (!f.file)
^ permalink raw reply related
* Re: [musl] Re: [RFC] Possible new execveat(2) Linux syscall
From: Christoph Hellwig @ 2014-11-21 10:10 UTC (permalink / raw)
To: Rich Felker
Cc: David Drysdale, Andy Lutomirski, libc-alpha, musl, Andrew Morton,
Linux API, Christoph Hellwig
In-Reply-To: <20141117183010.GE22465@brightrain.aerifal.cx>
On Mon, Nov 17, 2014 at 01:30:10PM -0500, Rich Felker wrote:
> On Mon, Nov 17, 2014 at 03:42:15PM +0000, David Drysdale wrote:
> > I'm not familiar with O_EXEC either, I'm afraid, so to be clear -- does
> > O_EXEC mean the permission check is explicitly skipped later, at execute
> > time? In other words, if you open(O_EXEC) an executable then remove the
> > execute bit from the file, does a subsequent fexecve() still work?
>
> Yes. It's just like how read and write permissions work. If you open a
> file for read then remove read permissions, or open it for write then
> remove write permissions, the existing permissions to the open file
> are not lost. Of course open with O_EXEC/O_SEARCH needs to fail if the
> caller does not have +x access to the file/directory at the time of
> open.
Adding a FMODE_EXEC similar to FMODE_READ/WRITE would be trivial.
^ permalink raw reply
* Re: kdbus: add code for buses, domains and endpoints
From: Harald Hoyer @ 2014-11-21 8:14 UTC (permalink / raw)
To: Greg Kroah-Hartman, arnd-r2nGTMty4D4,
ebiederm-aS9lmoZGLiVWk0Htik3J/w,
gnomes-qBU/x9rampVanCEyBjwyrvXRex20P6io, teg-B22kvLQNl6c,
jkosina-AlSwsSmVLrQ, luto-kltTT9wpgjJwATOyAt5JVQ,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: daniel-cYrQPVfZoowdnm+yROfE0A, dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w,
tixxdz-Umm1ozX2/EEdnm+yROfE0A
In-Reply-To: <1416546149-24799-10-git-send-email-gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
On 21.11.2014 06:02, Greg Kroah-Hartman wrote:
> From: Daniel Mack <daniel-cYrQPVfZoowdnm+yROfE0A@public.gmane.org>
>
> Add the logic to handle the following entities:
>
> Domain:
> A domain is an unamed object containing a number of buses. A
> domain is automatically created when an instance of kdbusfs
> is mounted, and destroyed when it is unmounted.
> Every domain offers its own "control" device node to create
> buses. Domains have no connection to each other and cannot
> see nor talk to each other.
>
> Bus:
> A bus is a named object inside a domain. Clients exchange messages
> over a bus. Multiple buses themselves have no connection to each
> other; messages can only be exchanged on the same bus. The default
> entry point to a bus, where clients establish the connection to, is
> the "bus" device node /dev/kdbus/<bus name>/bus. Common operating
> system setups create one "system bus" per system, and one "user
> bus" for every logged-in user. Applications or services may create
> their own private named buses.
might need a resync with the documentation.
Bus:
A bus is a named object inside a domain. Clients exchange messages
over a bus. Multiple buses themselves have no connection to each other;
messages can only be exchanged on the same bus. The default entry point to
a bus, where clients establish the connection to, is the "bus" file
/sys/fs/kdbus/<bus name>/bus.
Common operating system setups create one "system bus" per system, and one
"user bus" for every logged-in user. Applications or services may create
their own private named buses. See section 5 for more details.
^ permalink raw reply
* Re: [PATCH v2 00/13] Add kdbus implementation
From: Greg Kroah-Hartman @ 2014-11-21 6:02 UTC (permalink / raw)
To: arnd-r2nGTMty4D4, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
gnomes-qBU/x9rampVanCEyBjwyrvXRex20P6io, teg-B22kvLQNl6c,
jkosina-AlSwsSmVLrQ, luto-kltTT9wpgjJwATOyAt5JVQ,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: daniel-cYrQPVfZoowdnm+yROfE0A, dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w,
tixxdz-Umm1ozX2/EEdnm+yROfE0A
In-Reply-To: <1416546149-24799-1-git-send-email-gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
On Thu, Nov 20, 2014 at 09:02:16PM -0800, Greg Kroah-Hartman wrote:
> kdbus is a kernel-level IPC implementation that aims for resemblance to
> the the protocol layer with the existing userspace D-Bus daemon while
> enabling some features that couldn't be implemented before in userspace.
>
> The documentation in the first patch in this series explains the
> protocol and the API details.
Ugh, and I can't seem to remember to put the patch numbers on the
series, sorry about that, my git format-patch default options are set up
for applying patches and responding to them, not generating numbered
series :(
If someone wants the numbers, I can resend them, otherwise, just stick
with the git tree...
thanks,
greg k-h
^ permalink raw reply
* [PATCH v3 7/7] crypto: AF_ALG: document the user space interface
From: Stephan Mueller @ 2014-11-21 5:34 UTC (permalink / raw)
To: Herbert Xu
Cc: Daniel Borkmann, 'Quentin Gouchet',
lkml - Kernel Mailing List, linux-crypto, linux-api
In-Reply-To: <4088013.2O8zCP0xXa@tachyon.chronox.de>
The extension of the user space interface documentation covers all
aspects of the patchset, including:
* AEAD cipher interface
* RNG cipher interface
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
Documentation/crypto/crypto-API-userspace.txt | 70 ++++++++++++++++++++++++++-
1 file changed, 68 insertions(+), 2 deletions(-)
diff --git a/Documentation/crypto/crypto-API-userspace.txt b/Documentation/crypto/crypto-API-userspace.txt
index ac619cd..0646034 100644
--- a/Documentation/crypto/crypto-API-userspace.txt
+++ b/Documentation/crypto/crypto-API-userspace.txt
@@ -30,8 +30,9 @@ ciphers are accessible:
* Symmetric ciphers
-Note, AEAD ciphers are currently not supported via the symmetric cipher
-interface.
+ * AEAD ciphers
+
+ * Random number generators
The interface is provided via Netlink using the type AF_ALG. In addition, the
setsockopt option type is SOL_ALG. In case the user space header files do not
@@ -85,6 +86,7 @@ If a consumer on the other hand wants to maintain the plaintext and the
ciphertext in different memory locations, all a consumer needs to do is to
provide different memory pointers for the encryption and decryption operation.
+
Message digest API
==================
@@ -169,6 +171,69 @@ as large as to hold all blocks of the encrypted or decrypted data. If the output
data size is smaller, only as many blocks are returned that fit into that
output buffer size.
+
+AEAD cipher API
+===============
+
+The operation is identical to the symmetric cipher API. However, an AEAD
+cipher requires additional information, such as the authentication tag and
+the associated data. This data is to be supplied in addition to the normal
+symmetric cipher data like key and IV discussed for the symmetric ciphers.
+
+During initialization, the struct sockaddr data structure must be filled as
+follows:
+
+struct sockaddr_alg sa = {
+ .salg_family = AF_ALG,
+ .salg_type = "aead", /* this selects the AEAD cipher */
+ .salg_name = "gcm(aes)" /* this is the cipher name */
+};
+
+The discussion about the sendmsg given for the symmetric cipher applies for
+the AEAD interface as well. In addition to the plaintext / ciphertext data and
+the IV, the following data must be supplied with the cmsghdr data structure:
+
+ * The AEAD authentication tag size is set with the flag
+ ALG_SET_AEAD_AUTHSIZE. The integer value of the authentication tag
+ size must be provided in the data field of the cmsghdr structure.
+
+ * The AEAD associated data is set with the flag ALG_SET_AEAD_ASSOC.
+ The data is set the same way as for the IV by supplying the associated
+ data in the data field of the cmsghdr structure.
+
+The authentication tag itself, however, is handled in a different way to comply
+with the specifics of the kernel crypto API and to avoid copying the
+authentication tag around in memory. The authentication tag is added to the
+memory that immediately follows the ciphertext.
+
+ * When performing an encryption operation, the resulting ciphertext
+ buffer will hold the tag as follows: ciphertext || tag. The consumer
+ must ensure that the ciphertext buffer is large enough to hold the
+ ciphertext together with the tag of the size set by the consumer using
+ the ALG_SET_AEAD_AUTHSIZE cmsghdr flag as discussed above.
+
+ * When performing a decryption operation, the initial ciphertext buffer
+ must hold the tag as follows: ciphertext || tag. The resulting
+ plaintext has the same size as the ciphertext.
+
+Note: Authentication errors during decryption are marked with a failing
+read/recv system call whose errno is set to EBADMSG.
+
+
+Random number generator API
+===========================
+
+Compared to the symmetric ciphers, the random number generator API is simple:
+it only supports the system calls of read/recv.
+
+The consumer must observe the returned size of the read/recv system calls and
+potentially make subsequent calls if the returned length of random numbers is
+smaller than the expected length.
+
+When initializing a random number generator instance, the AF_ALG interface
+handler ensures that it is appropriately seeded.
+
+
Setsockopt interface
====================
@@ -190,6 +255,7 @@ optname:
- the hash cipher type (keyed message digests)
+
User space API example
======================
--
2.1.0
^ permalink raw reply related
* [PATCH v3 6/7] crypto: AF_ALG: enable RNG interface compilation
From: Stephan Mueller @ 2014-11-21 5:33 UTC (permalink / raw)
To: Herbert Xu
Cc: Daniel Borkmann, 'Quentin Gouchet',
lkml - Kernel Mailing List, linux-crypto, linux-api
In-Reply-To: <4088013.2O8zCP0xXa@tachyon.chronox.de>
Enable compilation of the RNG AF_ALG support and provide a Kconfig
option to compile the RNG AF_ALG support.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
crypto/Kconfig | 9 +++++++++
crypto/Makefile | 1 +
2 files changed, 10 insertions(+)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 87bbc9c..e127323 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1505,6 +1505,15 @@ config CRYPTO_USER_API_SKCIPHER
This option enables the user-spaces interface for symmetric
key cipher algorithms.
+config CRYPTO_USER_API_RNG
+ tristate "User-space interface for random number generator algorithms"
+ depends on NET
+ select CRYPTO_RNG
+ select CRYPTO_USER_API
+ help
+ This option enables the user-spaces interface for random
+ number generator algorithms.
+
config CRYPTO_HASH_INFO
bool
diff --git a/crypto/Makefile b/crypto/Makefile
index 1445b91..ba19465 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -99,6 +99,7 @@ obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o
obj-$(CONFIG_CRYPTO_USER_API) += af_alg.o
obj-$(CONFIG_CRYPTO_USER_API_HASH) += algif_hash.o
obj-$(CONFIG_CRYPTO_USER_API_SKCIPHER) += algif_skcipher.o
+obj-$(CONFIG_CRYPTO_USER_API_RNG) += algif_rng.o
#
# generic algorithms and the async_tx api
--
2.1.0
^ permalink raw reply related
* [PATCH v3 5/7] crypto: AF_ALG: add random number generator support
From: Stephan Mueller @ 2014-11-21 5:32 UTC (permalink / raw)
To: Herbert Xu
Cc: Daniel Borkmann, 'Quentin Gouchet',
lkml - Kernel Mailing List, linux-crypto, linux-api
In-Reply-To: <4088013.2O8zCP0xXa@tachyon.chronox.de>
This patch adds the random number generator support for AF_ALG.
A random number generator's purpose is to generate data without
requiring the caller to provide any data. Therefore, the AF_ALG
interface handler for RNGs only implements a callback handler for
recvmsg.
The following parameters provided with a recvmsg are processed by the
RNG callback handler:
* sock - to resolve the RNG context data structure accessing the
RNG instance private to the socket
* len - this parameter allows userspace callers to specify how
many random bytes the RNG shall produce and return. As the
kernel context for the RNG allocates a buffer of 128 bytes to
store random numbers before copying them to userspace, the len
parameter is checked that it is not larger than 128. If a
caller wants more random numbers, a new request for recvmsg
shall be made.
The size of 128 bytes is chose because of the following considerations:
* to increase the memory footprint of the kernel too much (note,
that would be 128 bytes per open socket)
* 128 is divisible by any typical cryptographic block size an
RNG may have
* A request for random numbers typically only shall supply small
amount of data like for keys or IVs that should only require
one invocation of the recvmsg function.
Note, during instantiation of the RNG, the code checks whether the RNG
implementation requires seeding. If so, the RNG is seeded with output
from get_random_bytes.
A fully working example using all aspects of the RNG interface is
provided at http://www.chronox.de/libkcapi.html
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
crypto/algif_rng.c | 186 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 186 insertions(+)
create mode 100644 crypto/algif_rng.c
diff --git a/crypto/algif_rng.c b/crypto/algif_rng.c
new file mode 100644
index 0000000..fc25869
--- /dev/null
+++ b/crypto/algif_rng.c
@@ -0,0 +1,186 @@
+/*
+ * algif_rng: User-space interface for random number generators
+ *
+ * This file provides the user-space API for random number generators.
+ *
+ * Copyright (C) 2014, Stephan Mueller <smueller@chronox.de>
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, and the entire permission notice in its entirety,
+ * including the disclaimer of warranties.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote
+ * products derived from this software without specific prior
+ * written permission.
+ *
+ * ALTERNATIVELY, this product may be distributed under the terms of
+ * the GNU General Public License, in which case the provisions of the GPL2
+ * are required INSTEAD OF the above restrictions. (This clause is
+ * necessary due to a potential bad interaction between the GPL and
+ * the restrictions contained in a BSD-style copyright.)
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ALL OF
+ * WHICH ARE HEREBY DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
+ * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
+ * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ * USE OF THIS SOFTWARE, EVEN IF NOT ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ */
+
+#include <linux/module.h>
+#include <crypto/rng.h>
+#include <linux/random.h>
+#include <crypto/if_alg.h>
+#include <linux/net.h>
+#include <net/sock.h>
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Stephan Mueller <smueller@chronox.de>");
+MODULE_DESCRIPTION("User-space interface for random number generators");
+
+struct rng_ctx {
+#define MAXSIZE 128
+ u8 result[MAXSIZE];
+ unsigned int len;
+ struct crypto_rng *drng;
+};
+
+static int rng_recvmsg(struct kiocb *unused, struct socket *sock,
+ struct msghdr *msg, size_t len, int flags)
+{
+ struct sock *sk = sock->sk;
+ struct alg_sock *ask = alg_sk(sk);
+ struct rng_ctx *ctx = ask->private;
+ int err = -EFAULT;
+
+ if (len == 0)
+ return 0;
+ if (len > MAXSIZE)
+ len = MAXSIZE;
+
+ lock_sock(sk);
+ len = crypto_rng_get_bytes(ctx->drng, ctx->result, len);
+ if (len < 0)
+ goto unlock;
+
+ err = memcpy_toiovec(msg->msg_iov, ctx->result, len);
+ memzero_explicit(ctx->result, len);
+
+unlock:
+ release_sock(sk);
+
+ return err ? err : len;
+}
+
+static struct proto_ops algif_rng_ops = {
+ .family = PF_ALG,
+
+ .connect = sock_no_connect,
+ .socketpair = sock_no_socketpair,
+ .getname = sock_no_getname,
+ .ioctl = sock_no_ioctl,
+ .listen = sock_no_listen,
+ .shutdown = sock_no_shutdown,
+ .getsockopt = sock_no_getsockopt,
+ .mmap = sock_no_mmap,
+ .bind = sock_no_bind,
+ .accept = sock_no_accept,
+ .setsockopt = sock_no_setsockopt,
+ .poll = sock_no_poll,
+ .sendmsg = sock_no_sendmsg,
+ .sendpage = sock_no_sendpage,
+
+ .release = af_alg_release,
+ .recvmsg = rng_recvmsg,
+};
+
+static void *rng_bind(const char *name, u32 type, u32 mask)
+{
+ return crypto_alloc_rng(name, type, mask);
+}
+
+static void rng_release(void *private)
+{
+ crypto_free_rng(private);
+}
+
+static void rng_sock_destruct(struct sock *sk)
+{
+ struct alg_sock *ask = alg_sk(sk);
+ struct rng_ctx *ctx = ask->private;
+
+ memzero_explicit(ctx->result, sizeof(ctx->result));
+ sock_kfree_s(sk, ctx, ctx->len);
+ af_alg_release_parent(sk);
+}
+
+static int rng_accept_parent(void *private, struct sock *sk)
+{
+ struct rng_ctx *ctx;
+ struct alg_sock *ask = alg_sk(sk);
+ unsigned int len = sizeof(*ctx);
+ int seedsize = crypto_rng_seedsize(private);
+ int ret = -ENOMEM;
+
+ ctx = sock_kmalloc(sk, len, GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
+ memset(ctx->result, 0, sizeof(ctx->result));
+
+ ctx->len = len;
+
+ if (seedsize) {
+ u8 *buf = kmalloc(seedsize, GFP_KERNEL);
+ if (!buf)
+ goto err;
+ get_random_bytes(buf, seedsize);
+ ret = crypto_rng_reset(private, buf, len);
+ kzfree(buf);
+ if (ret)
+ goto err;
+ }
+
+ ctx->drng = private;
+ ask->private = ctx;
+ sk->sk_destruct = rng_sock_destruct;
+
+ return 0;
+
+err:
+ sock_kfree_s(sk, ctx, len);
+ return ret;
+}
+
+static const struct af_alg_type algif_type_rng = {
+ .bind = rng_bind,
+ .release = rng_release,
+ .accept = rng_accept_parent,
+ .ops = &algif_rng_ops,
+ .name = "rng",
+ .owner = THIS_MODULE
+};
+
+static int __init rng_init(void)
+{
+ return af_alg_register_type(&algif_type_rng);
+}
+
+void __exit rng_exit(void)
+{
+ int err = af_alg_unregister_type(&algif_type_rng);
+ BUG_ON(err);
+}
+
+module_init(rng_init);
+module_exit(rng_exit);
--
2.1.0
^ permalink raw reply related
* [PATCH v3 4/7] crypto: AF_ALG: add AEAD support
From: Stephan Mueller @ 2014-11-21 5:32 UTC (permalink / raw)
To: Herbert Xu
Cc: Daniel Borkmann, 'Quentin Gouchet',
lkml - Kernel Mailing List, linux-crypto, linux-api
In-Reply-To: <4088013.2O8zCP0xXa@tachyon.chronox.de>
This patch adds the AEAD support for AF_ALG.
The AEAD implementation uses the entire memory handling and
infrastructure of the existing skcipher implementation.
To use AEAD, the user space consumer has to use the salg_type named
"aead". The AEAD extension only uses the bind callback as the key
differentiator. The previously added functions that select whether to
use AEAD or ablkcipher crypto API functions depend on the TFM type
allocated during the bind() call.
The addition of AEAD brings a bit of overhead to calculate the size of
the ciphertext, because the AEAD implementation of the kernel crypto API
makes implied assumption on the location of the authentication tag. When
performing an encryption, the tag will be added to the created
ciphertext (note, the tag is placed adjacent to the ciphertext). For
decryption, the caller must hand in the ciphertext with the tag appended
to the ciphertext. Therefore, the selection of the used memory
needs to add/subtract the tag size from the source/destination buffers
depending on the encryption type. The code is provided with comments
explainint when and how that operation is performed.
Note: The AF_ALG interface does not support zero length input data.
Such zero length input data may be used if one wants to access the hash
implementation of an AEAD directly (e.g. the GHASH of GCM or CMAC for
CCM). However, this is a use case that is not of interest. GHASH or
CMAC is directly available via the hash AF_ALG interface and we
therefore do not need to take precautions for this use case.
A fully working example using all aspects of AEAD is provided at
http://www.chronox.de/libkcapi.html
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
crypto/algif_skcipher.c | 158 +++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 148 insertions(+), 10 deletions(-)
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index 9637365..26367f4 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -384,6 +384,9 @@ static int skcipher_sendmsg(struct kiocb *unused, struct socket *sock,
if (con.iv && con.iv->ivlen != ivsize)
return -EINVAL;
+
+ if (ctx->aead && !con.aead_authsize && !con.aead_assoclen)
+ return -EINVAL;
}
err = -EINVAL;
@@ -396,6 +399,16 @@ static int skcipher_sendmsg(struct kiocb *unused, struct socket *sock,
ctx->enc = enc;
if (con.iv)
memcpy(ctx->iv, con.iv->iv, ivsize);
+ /* AEAD authentication data handling */
+ if (ctx->aead) {
+ if (con.aead_authsize)
+ err = crypto_aead_setauthsize(
+ crypto_aead_reqtfm(&ctx->u.aead_req),
+ con.aead_authsize);
+ if (err)
+ goto unlock;
+ ctx->aead_assoclen = con.aead_assoclen;
+ }
}
while (size) {
@@ -539,15 +552,58 @@ static int skcipher_recvmsg(struct kiocb *unused, struct socket *sock,
unsigned bs = skcipher_crypto_blocksize(ctx);
struct skcipher_sg_list *sgl;
struct scatterlist *sg;
+ struct scatterlist assoc;
unsigned long iovlen;
struct iovec *iov;
int err = -EAGAIN;
int used;
long copied = 0;
+ unsigned int aead_authsize_enc = 0;
+ unsigned int aead_authsize_dec = 0;
lock_sock(sk);
+ /*
+ * AEAD memory structure: For encryption, the tag is appended to the
+ * ciphertext which implies that the memory allocated for the ciphertext
+ * must be increased by the tag length. For decryption, the tag
+ * is expected to be concatenated to the ciphertext. The plaintext
+ * therefore has a memory size of the ciphertext minus the tag length.
+ *
+ * Note: this memory calculation only works because we require the
+ * user space caller to:
+ * * perform encryption by invoking the recv function with a buffer
+ * length of ciphertext + tag size -- the send function can be
+ * invoked normally with just the plaintext.
+ * * perform a decryption by invoking the the write function with
+ * a buffer holding the ciphertext + tag (and setting the
+ * buffer size accordingly) -- the recv function can be invoked
+ * normally with just the space needed for the ciphertext.
+ * Though, the caller should check for EBADMSG to catch integiry
+ * violations.
+ *
+ * The memory structure for cipher operation has the following
+ * structure:
+ * Symmetric encryption input: plaintext
+ * Symmetric encryption output: ciphertext
+ * AEAD encryption input: assoc data || plaintext
+ * AEAD encryption output: cipherntext || auth tag
+ * Symmetric decryption input: ciphertext
+ * Symmetric decryption output: plaintext
+ * AEAD decryption input: assoc data || ciphertext || auth tag
+ * AEAD decryption output: plaintext
+ */
+ if (ctx->aead) {
+ if (ctx->enc)
+ aead_authsize_enc = crypto_aead_authsize(
+ crypto_aead_reqtfm(&ctx->u.aead_req));
+ else
+ aead_authsize_dec = crypto_aead_authsize(
+ crypto_aead_reqtfm(&ctx->u.aead_req));
+ }
+
for (iov = msg->msg_iov, iovlen = msg->msg_iovlen; iovlen > 0;
iovlen--, iov++) {
+ /* size of the output data memory */
unsigned long seglen = iov->iov_len;
char __user *from = iov->iov_base;
@@ -559,14 +615,43 @@ static int skcipher_recvmsg(struct kiocb *unused, struct socket *sock,
while (!sg->length)
sg++;
+ /* size of the input data memory */
used = ctx->used;
- if (!used) {
+ if (used <= ctx->aead_assoclen) {
err = skcipher_wait_for_data(sk, flags);
if (err)
goto unlock;
}
- used = min_t(unsigned long, used, seglen);
+ /*
+ * The cipher operation input data is reduced by
+ * the associated data length as the data pointers will
+ * be moved forward by the associated data length later
+ * on.
+ */
+ used -= ctx->aead_assoclen;
+ used = min_t(unsigned long,
+ /*
+ * In case of encryption, add
+ * the memory needed for the tag
+ * to the input data length to
+ * give the cipher the necessary
+ * space to add the tag.
+ */
+ used + aead_authsize_enc,
+ /*
+ * In case of decryption, add the
+ * memory needed for the tag
+ * calculations to the output
+ * buffer.
+ */
+ seglen + aead_authsize_dec);
+
+ if (used < aead_authsize_enc ||
+ seglen < aead_authsize_dec) {
+ err = -ENOMEM;
+ goto unlock;
+ }
used = af_alg_make_sg(&ctx->rsgl, from, used, 1);
err = used;
@@ -580,9 +665,29 @@ static int skcipher_recvmsg(struct kiocb *unused, struct socket *sock,
if (!used)
goto free;
- ablkcipher_request_set_crypt(&ctx->req, sg,
- ctx->rsgl.sg, used,
- ctx->iv);
+ if (ctx->aead) {
+ /* first chunk of input is AD */
+ sg_init_table(&assoc, 2);
+ sg_set_page(&assoc, sg_page(sg),
+ ctx->aead_assoclen, 0);
+ aead_request_set_assoc(&ctx->u.aead_req, &assoc,
+ ctx->aead_assoclen);
+ /* point sg to cipher/plaintext */
+ sg_set_page(sg, sg_page(sg),
+ sg->length - ctx->aead_assoclen,
+ ctx->aead_assoclen);
+ }
+
+ /*
+ * See API specification of the AEAD API: for
+ * encryption, we need to tell the encrypt function
+ * what the size of the plaintext is. But we have
+ * ensured that we have sufficient memory allocated for
+ * the operation.
+ */
+ skcipher_crypto_set_crypt(ctx, sg, ctx->rsgl.sg,
+ used - aead_authsize_enc,
+ ctx->iv);
err = af_alg_wait_for_completion(
ctx->enc ?
@@ -596,10 +701,22 @@ free:
if (err)
goto unlock;
- copied += used;
- from += used;
- seglen -= used;
- skcipher_pull_sgl(sk, used);
+ /*
+ * Adjust the output buffer counters by only the size
+ * needed for the plaintext in case of a decryption
+ */
+ copied += (used - aead_authsize_dec);
+ from += (used - aead_authsize_dec);
+ seglen -= (used - aead_authsize_dec);
+ /*
+ * Adjust the input buffer by how much we have encrypted
+ * or decrypted. In case of encryption, we only credit
+ * the memory of the plaintext. The associated data
+ * is also released as a new cipher operation must
+ * provide new associated data.
+ */
+ skcipher_pull_sgl(sk, used - aead_authsize_enc +
+ ctx->aead_assoclen);
}
}
@@ -732,15 +849,36 @@ static const struct af_alg_type algif_type_skcipher = {
.owner = THIS_MODULE
};
+static void *aead_bind(const char *name, u32 type, u32 mask)
+{
+ return crypto_alloc_aead(name, type, mask);
+}
+
+static const struct af_alg_type algif_type_aead = {
+ .bind = aead_bind,
+ .release = skcipher_release,
+ .setkey = skcipher_setkey,
+ .accept = skcipher_accept_parent,
+ .ops = &algif_skcipher_ops,
+ .name = "aead",
+ .owner = THIS_MODULE
+};
+
static int __init algif_skcipher_init(void)
{
- return af_alg_register_type(&algif_type_skcipher);
+ int ret = af_alg_register_type(&algif_type_skcipher);
+
+ if (ret)
+ return ret;
+ return af_alg_register_type(&algif_type_aead);
}
static void __exit algif_skcipher_exit(void)
{
int err = af_alg_unregister_type(&algif_type_skcipher);
BUG_ON(err);
+ err = af_alg_unregister_type(&algif_type_aead);
+ BUG_ON(err);
}
module_init(algif_skcipher_init);
--
2.1.0
^ permalink raw reply related
* [PATCH v3 2/7] crypto: AF_ALG: extend data structuers for AEAD
From: Stephan Mueller @ 2014-11-21 5:31 UTC (permalink / raw)
To: Herbert Xu
Cc: Daniel Borkmann, 'Quentin Gouchet',
lkml - Kernel Mailing List, linux-crypto, linux-api
In-Reply-To: <4088013.2O8zCP0xXa@tachyon.chronox.de>
The data structure holding the state of an ongoing symmetric cipher
operation is extended by the data variables needed for AEAD.
The request data structures are encapsulated by a union as the symmetric
cipher implementation is either exclusively used for "normal" symmetric
ciphers or for AEAD ciphers.
In addition, the size of the associated data expected to be present in
the input data must be retained.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
crypto/algif_skcipher.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index 85e3bdb..49d5b08 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -46,7 +46,12 @@ struct skcipher_ctx {
bool merge;
bool enc;
- struct ablkcipher_request req;
+ bool aead;
+ size_t aead_assoclen;
+ union {
+ struct ablkcipher_request ablkcipher_req;
+ struct aead_request aead_req;
+ } u;
};
#define MAX_SGL_ENTS ((4096 - sizeof(struct skcipher_sg_list)) / \
--
2.1.0
^ permalink raw reply related
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