1. 04 2月, 2021 3 次提交
    • J
      KVM: x86/xen: intercept xen hypercalls if enabled · 23200b7a
      Joao Martins 提交于
      Add a new exit reason for emulator to handle Xen hypercalls.
      
      Since this means KVM owns the ABI, dispense with the facility for the
      VMM to provide its own copy of the hypercall pages; just fill them in
      directly using VMCALL/VMMCALL as we do for the Hyper-V hypercall page.
      
      This behaviour is enabled by a new INTERCEPT_HCALL flag in the
      KVM_XEN_HVM_CONFIG ioctl structure, and advertised by the same flag
      being returned from the KVM_CAP_XEN_HVM check.
      
      Rename xen_hvm_config() to kvm_xen_write_hypercall_page() and move it
      to the nascent xen.c while we're at it, and add a test case.
      Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>
      Signed-off-by: NDavid Woodhouse <dwmw@amazon.co.uk>
      23200b7a
    • C
      KVM: VMX: Enable bus lock VM exit · fe6b6bc8
      Chenyi Qiang 提交于
      Virtual Machine can exploit bus locks to degrade the performance of
      system. Bus lock can be caused by split locked access to writeback(WB)
      memory or by using locks on uncacheable(UC) memory. The bus lock is
      typically >1000 cycles slower than an atomic operation within a cache
      line. It also disrupts performance on other cores (which must wait for
      the bus lock to be released before their memory operations can
      complete).
      
      To address the threat, bus lock VM exit is introduced to notify the VMM
      when a bus lock was acquired, allowing it to enforce throttling or other
      policy based mitigations.
      
      A VMM can enable VM exit due to bus locks by setting a new "Bus Lock
      Detection" VM-execution control(bit 30 of Secondary Processor-based VM
      execution controls). If delivery of this VM exit was preempted by a
      higher priority VM exit (e.g. EPT misconfiguration, EPT violation, APIC
      access VM exit, APIC write VM exit, exception bitmap exiting), bit 26 of
      exit reason in vmcs field is set to 1.
      
      In current implementation, the KVM exposes this capability through
      KVM_CAP_X86_BUS_LOCK_EXIT. The user can get the supported mode bitmap
      (i.e. off and exit) and enable it explicitly (disabled by default). If
      bus locks in guest are detected by KVM, exit to user space even when
      current exit reason is handled by KVM internally. Set a new field
      KVM_RUN_BUS_LOCK in vcpu->run->flags to inform the user space that there
      is a bus lock detected in guest.
      
      Document for Bus Lock VM exit is now available at the latest "Intel
      Architecture Instruction Set Extensions Programming Reference".
      
      Document Link:
      https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.htmlCo-developed-by: NXiaoyao Li <xiaoyao.li@intel.com>
      Signed-off-by: NXiaoyao Li <xiaoyao.li@intel.com>
      Signed-off-by: NChenyi Qiang <chenyi.qiang@intel.com>
      Message-Id: <20201106090315.18606-4-chenyi.qiang@intel.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      fe6b6bc8
    • B
      KVM/SVM: add support for SEV attestation command · 2c07ded0
      Brijesh Singh 提交于
      The SEV FW version >= 0.23 added a new command that can be used to query
      the attestation report containing the SHA-256 digest of the guest memory
      encrypted through the KVM_SEV_LAUNCH_UPDATE_{DATA, VMSA} commands and
      sign the report with the Platform Endorsement Key (PEK).
      
      See the SEV FW API spec section 6.8 for more details.
      
      Note there already exist a command (KVM_SEV_LAUNCH_MEASURE) that can be
      used to get the SHA-256 digest. The main difference between the
      KVM_SEV_LAUNCH_MEASURE and KVM_SEV_ATTESTATION_REPORT is that the latter
      can be called while the guest is running and the measurement value is
      signed with PEK.
      
      Cc: James Bottomley <jejb@linux.ibm.com>
      Cc: Tom Lendacky <Thomas.Lendacky@amd.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Sean Christopherson <seanjc@google.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: John Allen <john.allen@amd.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: linux-crypto@vger.kernel.org
      Reviewed-by: NTom Lendacky <thomas.lendacky@amd.com>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Tested-by: NJames Bottomley <jejb@linux.ibm.com>
      Signed-off-by: NBrijesh Singh <brijesh.singh@amd.com>
      Message-Id: <20210104151749.30248-1-brijesh.singh@amd.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      2c07ded0
  2. 10 1月, 2021 1 次提交
    • C
      bcache: introduce BCH_FEATURE_INCOMPAT_LOG_LARGE_BUCKET_SIZE for large bucket · b16671e8
      Coly Li 提交于
      When large bucket feature was added, BCH_FEATURE_INCOMPAT_LARGE_BUCKET
      was introduced into the incompat feature set. It used bucket_size_hi
      (which was added at the tail of struct cache_sb_disk) to extend current
      16bit bucket size to 32bit with existing bucket_size in struct
      cache_sb_disk.
      
      This is not a good idea, there are two obvious problems,
      - Bucket size is always value power of 2, if store log2(bucket size) in
        existing bucket_size of struct cache_sb_disk, it is unnecessary to add
        bucket_size_hi.
      - Macro csum_set() assumes d[SB_JOURNAL_BUCKETS] is the last member in
        struct cache_sb_disk, bucket_size_hi was added after d[] which makes
        csum_set calculate an unexpected super block checksum.
      
      To fix the above problems, this patch introduces a new incompat feature
      bit BCH_FEATURE_INCOMPAT_LOG_LARGE_BUCKET_SIZE, when this bit is set, it
      means bucket_size in struct cache_sb_disk stores the order of power-of-2
      bucket size value. When user specifies a bucket size larger than 32768
      sectors, BCH_FEATURE_INCOMPAT_LOG_LARGE_BUCKET_SIZE will be set to
      incompat feature set, and bucket_size stores log2(bucket size) more
      than store the real bucket size value.
      
      The obsoleted BCH_FEATURE_INCOMPAT_LARGE_BUCKET won't be used anymore,
      it is renamed to BCH_FEATURE_INCOMPAT_OBSO_LARGE_BUCKET and still only
      recognized by kernel driver for legacy compatible purpose. The previous
      bucket_size_hi is renmaed to obso_bucket_size_hi in struct cache_sb_disk
      and not used in bcache-tools anymore.
      
      For cache device created with BCH_FEATURE_INCOMPAT_LARGE_BUCKET feature,
      bcache-tools and kernel driver still recognize the feature string and
      display it as "obso_large_bucket".
      
      With this change, the unnecessary extra space extend of bcache on-disk
      super block can be avoided, and csum_set() may generate expected check
      sum as well.
      
      Fixes: ffa47032 ("bcache: add bucket_size_hi into struct cache_sb_disk for large bucket")
      Signed-off-by: NColy Li <colyli@suse.de>
      Cc: stable@vger.kernel.org # 5.9+
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      b16671e8
  3. 08 1月, 2021 1 次提交
    • T
      KVM: SVM: Add support for booting APs in an SEV-ES guest · 647daca2
      Tom Lendacky 提交于
      Typically under KVM, an AP is booted using the INIT-SIPI-SIPI sequence,
      where the guest vCPU register state is updated and then the vCPU is VMRUN
      to begin execution of the AP. For an SEV-ES guest, this won't work because
      the guest register state is encrypted.
      
      Following the GHCB specification, the hypervisor must not alter the guest
      register state, so KVM must track an AP/vCPU boot. Should the guest want
      to park the AP, it must use the AP Reset Hold exit event in place of, for
      example, a HLT loop.
      
      First AP boot (first INIT-SIPI-SIPI sequence):
        Execute the AP (vCPU) as it was initialized and measured by the SEV-ES
        support. It is up to the guest to transfer control of the AP to the
        proper location.
      
      Subsequent AP boot:
        KVM will expect to receive an AP Reset Hold exit event indicating that
        the vCPU is being parked and will require an INIT-SIPI-SIPI sequence to
        awaken it. When the AP Reset Hold exit event is received, KVM will place
        the vCPU into a simulated HLT mode. Upon receiving the INIT-SIPI-SIPI
        sequence, KVM will make the vCPU runnable. It is again up to the guest
        to then transfer control of the AP to the proper location.
      
        To differentiate between an actual HLT and an AP Reset Hold, a new MP
        state is introduced, KVM_MP_STATE_AP_RESET_HOLD, which the vCPU is
        placed in upon receiving the AP Reset Hold exit event. Additionally, to
        communicate the AP Reset Hold exit event up to userspace (if needed), a
        new exit reason is introduced, KVM_EXIT_AP_RESET_HOLD.
      
      A new x86 ops function is introduced, vcpu_deliver_sipi_vector, in order
      to accomplish AP booting. For VMX, vcpu_deliver_sipi_vector is set to the
      original SIPI delivery function, kvm_vcpu_deliver_sipi_vector(). SVM adds
      a new function that, for non SEV-ES guests, invokes the original SIPI
      delivery function, kvm_vcpu_deliver_sipi_vector(), but for SEV-ES guests,
      implements the logic above.
      Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
      Message-Id: <e8fbebe8eb161ceaabdad7c01a5859a78b424d5e.1609791600.git.thomas.lendacky@amd.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      647daca2
  4. 06 1月, 2021 1 次提交
  5. 28 12月, 2020 3 次提交
  6. 22 12月, 2020 1 次提交
  7. 20 12月, 2020 1 次提交
  8. 19 12月, 2020 2 次提交
  9. 17 12月, 2020 1 次提交
  10. 16 12月, 2020 2 次提交
    • L
      userfaultfd: add UFFD_USER_MODE_ONLY · 37cd0575
      Lokesh Gidra 提交于
      Patch series "Control over userfaultfd kernel-fault handling", v6.
      
      This patch series is split from [1].  The other series enables SELinux
      support for userfaultfd file descriptors so that its creation and movement
      can be controlled.
      
      It has been demonstrated on various occasions that suspending kernel code
      execution for an arbitrary amount of time at any access to userspace
      memory (copy_from_user()/copy_to_user()/...) can be exploited to change
      the intended behavior of the kernel.  For instance, handling page faults
      in kernel-mode using userfaultfd has been exploited in [2, 3].  Likewise,
      FUSE, which is similar to userfaultfd in this respect, has been exploited
      in [4, 5] for similar outcome.
      
      This small patch series adds a new flag to userfaultfd(2) that allows
      callers to give up the ability to handle kernel-mode faults with the
      resulting UFFD file object.  It then adds a 'user-mode only' option to the
      unprivileged_userfaultfd sysctl knob to require unprivileged callers to
      use this new flag.
      
      The purpose of this new interface is to decrease the chance of an
      unprivileged userfaultfd user taking advantage of userfaultfd to enhance
      security vulnerabilities by lengthening the race window in kernel code.
      
      [1] https://lore.kernel.org/lkml/20200211225547.235083-1-dancol@google.com/
      [2] https://duasynt.com/blog/linux-kernel-heap-spray
      [3] https://duasynt.com/blog/cve-2016-6187-heap-off-by-one-exploit
      [4] https://googleprojectzero.blogspot.com/2016/06/exploiting-recursion-in-linux-kernel_20.html
      [5] https://bugs.chromium.org/p/project-zero/issues/detail?id=808
      
      This patch (of 2):
      
      userfaultfd handles page faults from both user and kernel code.  Add a new
      UFFD_USER_MODE_ONLY flag for userfaultfd(2) that makes the resulting
      userfaultfd object refuse to handle faults from kernel mode, treating
      these faults as if SIGBUS were always raised, causing the kernel code to
      fail with EFAULT.
      
      A future patch adds a knob allowing administrators to give some processes
      the ability to create userfaultfd file objects only if they pass
      UFFD_USER_MODE_ONLY, reducing the likelihood that these processes will
      exploit userfaultfd's ability to delay kernel page faults to open timing
      windows for future exploits.
      
      Link: https://lkml.kernel.org/r/20201120030411.2690816-1-lokeshgidra@google.com
      Link: https://lkml.kernel.org/r/20201120030411.2690816-2-lokeshgidra@google.comSigned-off-by: NDaniel Colascione <dancol@google.com>
      Signed-off-by: NLokesh Gidra <lokeshgidra@google.com>
      Reviewed-by: NAndrea Arcangeli <aarcange@redhat.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: <calin@google.com>
      Cc: Daniel Colascione <dancol@dancol.org>
      Cc: Eric Biggers <ebiggers@kernel.org>
      Cc: Iurii Zaikin <yzaikin@google.com>
      Cc: Jeff Vander Stoep <jeffv@google.com>
      Cc: Jerome Glisse <jglisse@redhat.com>
      Cc: "Joel Fernandes (Google)" <joel@joelfernandes.org>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Kalesh Singh <kaleshsingh@google.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Luis Chamberlain <mcgrof@kernel.org>
      Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
      Cc: Nitin Gupta <nigupta@nvidia.com>
      Cc: Peter Xu <peterx@redhat.com>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Shaohua Li <shli@fb.com>
      Cc: Stephen Smalley <stephen.smalley.work@gmail.com>
      Cc: Suren Baghdasaryan <surenb@google.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      37cd0575
    • P
      uapi: move constants from <linux/kernel.h> to <linux/const.h> · a85cbe61
      Petr Vorel 提交于
      and include <linux/const.h> in UAPI headers instead of <linux/kernel.h>.
      
      The reason is to avoid indirect <linux/sysinfo.h> include when using
      some network headers: <linux/netlink.h> or others -> <linux/kernel.h>
      -> <linux/sysinfo.h>.
      
      This indirect include causes on MUSL redefinition of struct sysinfo when
      included both <sys/sysinfo.h> and some of UAPI headers:
      
          In file included from x86_64-buildroot-linux-musl/sysroot/usr/include/linux/kernel.h:5,
                           from x86_64-buildroot-linux-musl/sysroot/usr/include/linux/netlink.h:5,
                           from ../include/tst_netlink.h:14,
                           from tst_crypto.c:13:
          x86_64-buildroot-linux-musl/sysroot/usr/include/linux/sysinfo.h:8:8: error: redefinition of `struct sysinfo'
           struct sysinfo {
                  ^~~~~~~
          In file included from ../include/tst_safe_macros.h:15,
                           from ../include/tst_test.h:93,
                           from tst_crypto.c:11:
          x86_64-buildroot-linux-musl/sysroot/usr/include/sys/sysinfo.h:10:8: note: originally defined here
      
      Link: https://lkml.kernel.org/r/20201015190013.8901-1-petr.vorel@gmail.comSigned-off-by: NPetr Vorel <petr.vorel@gmail.com>
      Suggested-by: NRich Felker <dalias@aerifal.cx>
      Acked-by: NRich Felker <dalias@libc.org>
      Cc: Peter Korsgaard <peter@korsgaard.com>
      Cc: Baruch Siach <baruch@tkos.co.il>
      Cc: Florian Weimer <fweimer@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a85cbe61
  11. 15 12月, 2020 2 次提交
    • A
      vm_sockets: Add VMADDR_FLAG_TO_HOST vsock flag · caaf95e0
      Andra Paraschiv 提交于
      Add VMADDR_FLAG_TO_HOST vsock flag that is used to setup a vsock
      connection where all the packets are forwarded to the host.
      
      Then, using this type of vsock channel, vsock communication between
      sibling VMs can be built on top of it.
      
      Changelog
      
      v3 -> v4
      
      * Update the "VMADDR_FLAG_TO_HOST" value, as the size of the field has
        been updated to 1 byte.
      
      v2 -> v3
      
      * Update comments to mention when the flag is set in the connect and
        listen paths.
      
      v1 -> v2
      
      * New patch in v2, it was split from the first patch in the series.
      * Remove the default value for the vsock flags field.
      * Update the naming for the vsock flag to "VMADDR_FLAG_TO_HOST".
      Signed-off-by: NAndra Paraschiv <andraprs@amazon.com>
      Reviewed-by: NStefano Garzarella <sgarzare@redhat.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      caaf95e0
    • A
      vm_sockets: Add flags field in the vsock address data structure · dc8eeef7
      Andra Paraschiv 提交于
      vsock enables communication between virtual machines and the host they
      are running on. With the multi transport support (guest->host and
      host->guest), nested VMs can also use vsock channels for communication.
      
      In addition to this, by default, all the vsock packets are forwarded to
      the host, if no host->guest transport is loaded. This behavior can be
      implicitly used for enabling vsock communication between sibling VMs.
      
      Add a flags field in the vsock address data structure that can be used
      to explicitly mark the vsock connection as being targeted for a certain
      type of communication. This way, can distinguish between different use
      cases such as nested VMs and sibling VMs.
      
      This field can be set when initializing the vsock address variable used
      for the connect() call.
      
      Changelog
      
      v3 -> v4
      
      * Update the size of "svm_flags" field to be 1 byte instead of 2 bytes.
      
      v2 -> v3
      
      * Add "svm_flags" as a new field, not reusing "svm_reserved1".
      
      v1 -> v2
      
      * Update the field name to "svm_flags".
      * Split the current patch in 2 patches.
      Signed-off-by: NAndra Paraschiv <andraprs@amazon.com>
      Reviewed-by: NStefano Garzarella <sgarzare@redhat.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      dc8eeef7
  12. 14 12月, 2020 3 次提交
  13. 13 12月, 2020 1 次提交
    • P
      netfilter: nftables: netlink support for several set element expressions · 48b0ae04
      Pablo Neira Ayuso 提交于
      This patch adds three new netlink attributes to encapsulate a list of
      expressions per set elements:
      
      - NFTA_SET_EXPRESSIONS: this attribute provides the set definition in
        terms of expressions. New set elements get attached the list of
        expressions that is specified by this new netlink attribute.
      - NFTA_SET_ELEM_EXPRESSIONS: this attribute allows users to restore (or
        initialize) the stateful information of set elements when adding an
        element to the set.
      - NFTA_DYNSET_EXPRESSIONS: this attribute specifies the list of
        expressions that the set element gets when it is inserted from the
        packet path.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      48b0ae04
  14. 12 12月, 2020 2 次提交
  15. 11 12月, 2020 6 次提交
    • D
      dmaengine: idxd: add IAX configuration support in the IDXD driver · f25b4638
      Dave Jiang 提交于
      Add support to allow configuration of Intel Analytics Accelerator (IAX) in
      addition to the Intel Data Streaming Accelerator (DSA). The IAX hardware
      has the same configuration interface as DSA. The main difference
      is the type of operations it performs. We can support the DSA and
      IAX devices on the same driver with some tweaks.
      
      IAX has a 64B completion record that needs to be 64B aligned, as opposed to
      a 32B completion record that is 32B aligned for DSA. IAX also does not
      support token management.
      Signed-off-by: NDave Jiang <dave.jiang@intel.com>
      Link: https://lore.kernel.org/r/160564555488.1834439.4261958859935360473.stgit@djiang5-desk3.ch.intel.comSigned-off-by: NVinod Koul <vkoul@kernel.org>
      f25b4638
    • C
      nl80211: add common API to configure SAR power limitations · 6bdb68ce
      Carl Huang 提交于
      NL80211_CMD_SET_SAR_SPECS is added to configure SAR from
      user space. NL80211_ATTR_SAR_SPEC is used to pass the SAR
      power specification when used with NL80211_CMD_SET_SAR_SPECS.
      
      Wireless driver needs to register SAR type, supported frequency
      ranges to wiphy, so user space can query it. The index in
      frequency range is used to specify which sub band the power
      limitation applies to. The SAR type is for compatibility, so later
      other SAR mechanism can be implemented without breaking the user
      space SAR applications.
      
      Normal process is user space queries the SAR capability, and
      gets the index of supported frequency ranges and associates the
      power limitation with this index and sends to kernel.
      
      Here is an example of message send to kernel:
      8c 00 00 00 08 00 01 00 00 00 00 00 38 00 2b 81
      08 00 01 00 00 00 00 00 2c 00 02 80 14 00 00 80
      08 00 02 00 00 00 00 00 08 00 01 00 38 00 00 00
      14 00 01 80 08 00 02 00 01 00 00 00 08 00 01 00
      48 00 00 00
      
      NL80211_CMD_SET_SAR_SPECS:  0x8c
      NL80211_ATTR_WIPHY:     0x01(phy idx is 0)
      NL80211_ATTR_SAR_SPEC:  0x812b (NLA_NESTED)
      NL80211_SAR_ATTR_TYPE:  0x00 (NL80211_SAR_TYPE_POWER)
      NL80211_SAR_ATTR_SPECS: 0x8002 (NLA_NESTED)
      freq range 0 power: 0x38 in 0.25dbm unit (14dbm)
      freq range 1 power: 0x48 in 0.25dbm unit (18dbm)
      Signed-off-by: NCarl Huang <cjhuang@codeaurora.org>
      Reviewed-by: NBrian Norris <briannorris@chromium.org>
      Reviewed-by: NAbhishek Kumar <kuabhs@chromium.org>
      Link: https://lore.kernel.org/r/20201203103728.3034-2-cjhuang@codeaurora.org
      [minor edits, NLA parse cleanups]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6bdb68ce
    • J
      cfg80211: support immediate reconnect request hint · 3bb02143
      Johannes Berg 提交于
      There are cases where it's necessary to disconnect, but an
      immediate reconnection is desired. Support a hint to userspace
      that this is the case, by including a new attribute in the
      deauth or disassoc event.
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Link: https://lore.kernel.org/r/iwlwifi.20201206145305.58d33941fb9d.I0e7168c205c7949529c8e3b86f3c9b12c01a7017@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      3bb02143
    • J
      cfg80211: include block-tx flag in channel switch started event · 669b8413
      Johannes Berg 提交于
      In the NL80211_CMD_CH_SWITCH_STARTED_NOTIFY event, include the
      NL80211_ATTR_CH_SWITCH_BLOCK_TX flag attribute if block-tx was
      requested by the AP.
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Link: https://lore.kernel.org/r/iwlwifi.20201129172929.8953ef22cc64.Ifee9cab337a4369938545920ba5590559e91327a@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      669b8413
    • E
      rfkill: add a reason to the HW rfkill state · 14486c82
      Emmanuel Grumbach 提交于
      The WLAN device may exist yet not be usable. This can happen
      when the WLAN device is controllable by both the host and
      some platform internal component.
      We need some arbritration that is vendor specific, but when
      the device is not available for the host, we need to reflect
      this state towards the user space.
      
      Add a reason field to the rfkill object (and event) so that
      userspace can know why the device is in rfkill: because some
      other platform component currently owns the device, or
      because the actual hw rfkill signal is asserted.
      
      Capable userspace can now determine the reason for the rfkill
      and possibly do some negotiation on a side band channel using
      a proprietary protocol to gain ownership on the device in case
      the device is owned by some other component. When the host
      gains ownership on the device, the kernel can remove the
      RFKILL_HARD_BLOCK_NOT_OWNER reason and the hw rfkill state
      will be off. Then, the userspace can bring the device up and
      start normal operation.
      
      The rfkill_event structure is enlarged to include the additional
      byte, it is now 9 bytes long. Old user space will ask to read
      only 8 bytes so that the kernel can know not to feed them with
      more data. When the user space writes 8 bytes, new kernels will
      just read what is present in the file descriptor. This new byte
      is read only from the userspace standpoint anyway.
      
      If a new user space uses an old kernel, it'll ask to read 9 bytes
      but will get only 8, and it'll know that it didn't get the new
      state. When it'll write 9 bytes, the kernel will again ignore
      this new byte which is read only from the userspace standpoint.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Link: https://lore.kernel.org/r/20201104134641.28816-1-emmanuel.grumbach@intel.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      14486c82
    • T
      ppp: add PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN ioctls · 4cf476ce
      Tom Parkin 提交于
      This new ioctl pair allows two ppp channels to be bridged together:
      frames arriving in one channel are transmitted in the other channel
      and vice versa.
      
      The practical use for this is primarily to support the L2TP Access
      Concentrator use-case.  The end-user session is presented as a ppp
      channel (typically PPPoE, although it could be e.g. PPPoA, or even PPP
      over a serial link) and is switched into a PPPoL2TP session for
      transmission to the LNS.  At the LNS the PPP session is terminated in
      the ISP's network.
      
      When a PPP channel is bridged to another it takes a reference on the
      other's struct ppp_file.  This reference is dropped when the channels
      are unbridged, which can occur either explicitly on userspace calling
      the PPPIOCUNBRIDGECHAN ioctl, or implicitly when either channel in the
      bridge is unregistered.
      
      In order to implement the channel bridge, struct channel is extended
      with a new field, 'bridge', which points to the other struct channel
      making up the bridge.
      
      This pointer is RCU protected to avoid adding another lock to the data
      path.
      
      To guard against concurrent writes to the pointer, the existing struct
      channel lock 'upl' coverage is extended rather than adding a new lock.
      
      The 'upl' lock is used to protect the existing unit pointer.  Since the
      bridge effectively replaces the unit (they're mutually exclusive for a
      channel) it makes coding easier to use the same lock to cover them
      both.
      Signed-off-by: NTom Parkin <tparkin@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4cf476ce
  16. 10 12月, 2020 7 次提交
  17. 09 12月, 2020 1 次提交
  18. 08 12月, 2020 2 次提交