1. 04 2月, 2019 3 次提交
  2. 04 1月, 2019 1 次提交
    • L
      Remove 'type' argument from access_ok() function · 96d4f267
      Linus Torvalds 提交于
      Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument
      of the user address range verification function since we got rid of the
      old racy i386-only code to walk page tables by hand.
      
      It existed because the original 80386 would not honor the write protect
      bit when in kernel mode, so you had to do COW by hand before doing any
      user access.  But we haven't supported that in a long time, and these
      days the 'type' argument is a purely historical artifact.
      
      A discussion about extending 'user_access_begin()' to do the range
      checking resulted this patch, because there is no way we're going to
      move the old VERIFY_xyz interface to that model.  And it's best done at
      the end of the merge window when I've done most of my merges, so let's
      just get this done once and for all.
      
      This patch was mostly done with a sed-script, with manual fix-ups for
      the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.
      
      There were a couple of notable cases:
      
       - csky still had the old "verify_area()" name as an alias.
      
       - the iter_iov code had magical hardcoded knowledge of the actual
         values of VERIFY_{READ,WRITE} (not that they mattered, since nothing
         really used it)
      
       - microblaze used the type argument for a debug printout
      
      but other than those oddities this should be a total no-op patch.
      
      I tried to fix up all architectures, did fairly extensive grepping for
      access_ok() uses, and the changes are trivial, but I may have missed
      something.  Any missed conversion should be trivially fixable, though.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      96d4f267
  3. 02 1月, 2019 1 次提交
    • D
      sock: Make sock->sk_stamp thread-safe · 3a0ed3e9
      Deepa Dinamani 提交于
      Al Viro mentioned (Message-ID
      <20170626041334.GZ10672@ZenIV.linux.org.uk>)
      that there is probably a race condition
      lurking in accesses of sk_stamp on 32-bit machines.
      
      sock->sk_stamp is of type ktime_t which is always an s64.
      On a 32 bit architecture, we might run into situations of
      unsafe access as the access to the field becomes non atomic.
      
      Use seqlocks for synchronization.
      This allows us to avoid using spinlocks for readers as
      readers do not need mutual exclusion.
      
      Another approach to solve this is to require sk_lock for all
      modifications of the timestamps. The current approach allows
      for timestamps to have their own lock: sk_stamp_lock.
      This allows for the patch to not compete with already
      existing critical sections, and side effects are limited
      to the paths in the patch.
      
      The addition of the new field maintains the data locality
      optimizations from
      commit 9115e8cd ("net: reorganize struct sock for better data
      locality")
      
      Note that all the instances of the sk_stamp accesses
      are either through the ioctl or the syscall recvmsg.
      Signed-off-by: NDeepa Dinamani <deepa.kernel@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3a0ed3e9
  4. 18 12月, 2018 1 次提交
    • A
      y2038: socket: Add compat_sys_recvmmsg_time64 · e11d4284
      Arnd Bergmann 提交于
      recvmmsg() takes two arguments to pointers of structures that differ
      between 32-bit and 64-bit architectures: mmsghdr and timespec.
      
      For y2038 compatbility, we are changing the native system call from
      timespec to __kernel_timespec with a 64-bit time_t (in another patch),
      and use the existing compat system call on both 32-bit and 64-bit
      architectures for compatibility with traditional 32-bit user space.
      
      As we now have two variants of recvmmsg() for 32-bit tasks that are both
      different from the variant that we use on 64-bit tasks, this means we
      also require two compat system calls!
      
      The solution I picked is to flip things around: The existing
      compat_sys_recvmmsg() call gets moved from net/compat.c into net/socket.c
      and now handles the case for old user space on all architectures that
      have set CONFIG_COMPAT_32BIT_TIME.  A new compat_sys_recvmmsg_time64()
      call gets added in the old place for 64-bit architectures only, this
      one handles the case of a compat mmsghdr structure combined with
      __kernel_timespec.
      
      In the indirect sys_socketcall(), we now need to call either
      do_sys_recvmmsg() or __compat_sys_recvmmsg(), depending on what kind of
      architecture we are on. For compat_sys_socketcall(), no such change is
      needed, we always call __compat_sys_recvmmsg().
      
      I decided to not add a new SYS_RECVMMSG_TIME64 socketcall: Any libc
      implementation for 64-bit time_t will need significant changes including
      an updated asm/unistd.h, and it seems better to consistently use the
      separate syscalls that configuration, leaving the socketcall only for
      backward compatibility with 32-bit time_t based libc.
      
      The naming is asymmetric for the moment, so both existing syscalls
      entry points keep their names, while the new ones are recvmmsg_time32
      and compat_recvmmsg_time64 respectively. I expect that we will rename
      the compat syscalls later as we start using generated syscall tables
      everywhere and add these entry points.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      e11d4284
  5. 29 8月, 2018 1 次提交
    • A
      y2038: socket: Change recvmmsg to use __kernel_timespec · c2e6c856
      Arnd Bergmann 提交于
      This converts the recvmmsg() system call in all its variations to use
      'timespec64' internally for its timeout, and have a __kernel_timespec64
      argument in the native entry point. This lets us change the type to use
      64-bit time_t at a later point while using the 32-bit compat system call
      emulation for existing user space.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      c2e6c856
  6. 27 8月, 2018 1 次提交
    • A
      y2038: globally rename compat_time to old_time32 · 9afc5eee
      Arnd Bergmann 提交于
      Christoph Hellwig suggested a slightly different path for handling
      backwards compatibility with the 32-bit time_t based system calls:
      
      Rather than simply reusing the compat_sys_* entry points on 32-bit
      architectures unchanged, we get rid of those entry points and the
      compat_time types by renaming them to something that makes more sense
      on 32-bit architectures (which don't have a compat mode otherwise),
      and then share the entry points under the new name with the 64-bit
      architectures that use them for implementing the compatibility.
      
      The following types and interfaces are renamed here, and moved
      from linux/compat_time.h to linux/time32.h:
      
      old				new
      ---				---
      compat_time_t			old_time32_t
      struct compat_timeval		struct old_timeval32
      struct compat_timespec		struct old_timespec32
      struct compat_itimerspec	struct old_itimerspec32
      ns_to_compat_timeval()		ns_to_old_timeval32()
      get_compat_itimerspec64()	get_old_itimerspec32()
      put_compat_itimerspec64()	put_old_itimerspec32()
      compat_get_timespec64()		get_old_timespec32()
      compat_put_timespec64()		put_old_timespec32()
      
      As we already have aliases in place, this patch addresses only the
      instances that are relevant to the system call interface in particular,
      not those that occur in device drivers and other modules. Those
      will get handled separately, while providing the 64-bit version
      of the respective interfaces.
      
      I'm not renaming the timex, rusage and itimerval structures, as we are
      still debating what the new interface will look like, and whether we
      will need a replacement at all.
      
      This also doesn't change the names of the syscall entry points, which can
      be done more easily when we actually switch over the 32-bit architectures
      to use them, at that point we need to change COMPAT_SYSCALL_DEFINEx to
      SYSCALL_DEFINEx with a new name, e.g. with a _time32 suffix.
      Suggested-by: NChristoph Hellwig <hch@infradead.org>
      Link: https://lore.kernel.org/lkml/20180705222110.GA5698@infradead.org/Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      9afc5eee
  7. 07 8月, 2018 1 次提交
  8. 28 4月, 2018 1 次提交
    • L
      net: support compat 64-bit time in {s,g}etsockopt · 988bf724
      Lance Richardson 提交于
      For the x32 ABI, struct timeval has two 64-bit fields. However
      the kernel currently interprets the user-space values used for
      the SO_RCVTIMEO and SO_SNDTIMEO socket options as having a pair
      of 32-bit fields.
      
      When the seconds portion of the requested timeout is less than 2**32,
      the seconds portion of the effective timeout is correct but the
      microseconds portion is zero.  When the seconds portion of the
      requested timeout is zero and the microseconds portion is non-zero,
      the kernel interprets the timeout as zero (never timeout).
      
      Fix by using 64-bit time for SO_RCVTIMEO/SO_SNDTIMEO as required
      for the ABI.
      
      The code included below demonstrates the problem.
      
      Results before patch:
          $ gcc -m64 -Wall -O2 -o socktmo socktmo.c && ./socktmo
          recv time: 2.008181 seconds
          send time: 2.015985 seconds
      
          $ gcc -m32 -Wall -O2 -o socktmo socktmo.c && ./socktmo
          recv time: 2.016763 seconds
          send time: 2.016062 seconds
      
          $ gcc -mx32 -Wall -O2 -o socktmo socktmo.c && ./socktmo
          recv time: 1.007239 seconds
          send time: 1.023890 seconds
      
      Results after patch:
          $ gcc -m64 -O2 -Wall -o socktmo socktmo.c && ./socktmo
          recv time: 2.010062 seconds
          send time: 2.015836 seconds
      
          $ gcc -m32 -O2 -Wall -o socktmo socktmo.c && ./socktmo
          recv time: 2.013974 seconds
          send time: 2.015981 seconds
      
          $ gcc -mx32 -O2 -Wall -o socktmo socktmo.c && ./socktmo
          recv time: 2.030257 seconds
          send time: 2.013383 seconds
      
       #include <stdio.h>
       #include <stdlib.h>
       #include <sys/socket.h>
       #include <sys/types.h>
       #include <sys/time.h>
      
       void checkrc(char *str, int rc)
       {
               if (rc >= 0)
                       return;
      
               perror(str);
               exit(1);
       }
      
       static char buf[1024];
       int main(int argc, char **argv)
       {
               int rc;
               int socks[2];
               struct timeval tv;
               struct timeval start, end, delta;
      
               rc = socketpair(AF_UNIX, SOCK_STREAM, 0, socks);
               checkrc("socketpair", rc);
      
               /* set timeout to 1.999999 seconds */
               tv.tv_sec = 1;
               tv.tv_usec = 999999;
               rc = setsockopt(socks[0], SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof tv);
               rc = setsockopt(socks[0], SOL_SOCKET, SO_SNDTIMEO, &tv, sizeof tv);
               checkrc("setsockopt", rc);
      
               /* measure actual receive timeout */
               gettimeofday(&start, NULL);
               rc = recv(socks[0], buf, sizeof buf, 0);
               gettimeofday(&end, NULL);
               timersub(&end, &start, &delta);
      
               printf("recv time: %ld.%06ld seconds\n",
                      (long)delta.tv_sec, (long)delta.tv_usec);
      
               /* fill send buffer */
               do {
                       rc = send(socks[0], buf, sizeof buf, 0);
               } while (rc > 0);
      
               /* measure actual send timeout */
               gettimeofday(&start, NULL);
               rc = send(socks[0], buf, sizeof buf, 0);
               gettimeofday(&end, NULL);
               timersub(&end, &start, &delta);
      
               printf("send time: %ld.%06ld seconds\n",
                      (long)delta.tv_sec, (long)delta.tv_usec);
               exit(0);
       }
      
      Fixes: 515c7af8 ("x32: Use compat shims for {g,s}etsockopt")
      Reported-by: NGopal RajagopalSai <gopalsr83@gmail.com>
      Signed-off-by: NLance Richardson <lance.richardson.net@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      988bf724
  9. 03 4月, 2018 19 次提交
  10. 21 9月, 2017 1 次提交
    • M
      net: compat: assert the size of cmsg copied in is as expected · c2a64bb9
      Meng Xu 提交于
      The actual length of cmsg fetched in during the second loop
      (i.e., kcmsg - kcmsg_base) could be different from what we
      get from the first loop (i.e., kcmlen).
      
      The main reason is that the two get_user() calls in the two
      loops (i.e., get_user(ucmlen, &ucmsg->cmsg_len) and
      __get_user(ucmlen, &ucmsg->cmsg_len)) could cause ucmlen
      to have different values even they fetch from the same userspace
      address, as user can race to change the memory content in
      &ucmsg->cmsg_len across fetches.
      
      Although in the second loop, the sanity check
      if ((char *)kcmsg_base + kcmlen - (char *)kcmsg < CMSG_ALIGN(tmp))
      is inplace, it only ensures that the cmsg fetched in during the
      second loop does not exceed the length of kcmlen, but not
      necessarily equal to kcmlen. But indicated by the assignment
      kmsg->msg_controllen = kcmlen, we should enforce that.
      
      This patch adds this additional sanity check and ensures that
      what is recorded in kmsg->msg_controllen is the actual cmsg length.
      Signed-off-by: NMeng Xu <mengxu.gatech@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c2a64bb9
  11. 05 7月, 2017 2 次提交
  12. 19 1月, 2017 1 次提交
  13. 05 1月, 2017 2 次提交
  14. 25 12月, 2016 1 次提交
  15. 10 6月, 2016 1 次提交
  16. 07 6月, 2016 1 次提交
  17. 09 4月, 2015 1 次提交
  18. 24 3月, 2015 1 次提交