Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 21 3月, 2018 2 次提交
  3. 23 2月, 2018 9 次提交
  5. 27 1月, 2018 1 次提交
  7. 23 1月, 2018 2 次提交
  9. 17 1月, 2018 1 次提交
  11. 12 1月, 2018 3 次提交
  13. 10 1月, 2018 3 次提交
  15. 09 1月, 2018 2 次提交
  17. 08 1月, 2018 3 次提交
  19. 03 1月, 2018 1 次提交
  21. 21 12月, 2017 1 次提交
  23. 19 12月, 2017 1 次提交
    • U
      siox: new driver framework for eckelmann SIOX · bbecb07f
      由 Uwe Kleine-König 提交于 
      SIOX is a bus system invented at Eckelmann AG to control their building
management and refrigeration systems. Traditionally the bus was
implemented on custom microcontrollers, today Linux based machines are
in use, too.

The topology on a SIOX bus looks as follows:

      ,------->--DCLK-->---------------+----------------------.
      ^                                v                      v
 ,--------.                ,----------------------.       ,------
 |        |                |   ,--------------.   |       |
 |        |--->--DOUT-->---|->-|shift register|->-|--->---|
 |        |                |   `--------------'   |       |
 | master |                |        device        |       |  device
 |        |                |   ,--------------.   |       |
 |        |---<--DIN---<---|-<-|shift register|-<-|---<---|
 |        |                |   `--------------'   |       |
 `--------'                `----------------------'       `------
      v                                ^                      ^
      `----------DLD-------------------+----------------------'

There are two control lines (DCLK and DLD) driven from the bus master to
all devices in parallel and two daisy chained data lines, one for input
and one for output. DCLK is the clock to shift both chains by a single
bit. On an edge of DLD the devices latch both their input and output
shift registers.

This patch adds a framework for this bus type.
Acked-by: NGavin Schenk <g.schenk@eckelmann.de>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bbecb07f
  25. 18 12月, 2017 1 次提交
    • M
      ima: support new "hash" and "dont_hash" policy actions · da1b0029
      由 Mimi Zohar 提交于 
      The builtin ima_appraise_tcb policy, which is specified on the boot
command line, can be replaced with a custom policy, normally early in
the boot process.  Custom policies can be more restrictive in some ways,
like requiring file signatures, but can be less restrictive in other
ways, like not appraising mutable files.  With a less restrictive policy
in place, files in the builtin policy might not be hashed and labeled
with a security.ima hash.  On reboot, files which should be labeled in
the ima_appraise_tcb are not labeled, possibly preventing the system
from booting properly.

To resolve this problem, this patch extends the existing IMA policy
actions "measure", "dont_measure", "appraise", "dont_appraise", and
"audit" with "hash" and "dont_hash".  The new "hash" action will write
the file hash as security.ima, but without requiring the file to be
appraised as well.

For example, the builtin ima_appraise_tcb policy includes the rule,
"appraise fowner=0".  Adding the "hash fowner=0" rule to a custom
policy, will cause the needed file hashes to be calculated and written
as security.ima xattrs.
Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
      da1b0029
  27. 12 12月, 2017 1 次提交
    • M
      EVM: Allow userland to permit modification of EVM-protected metadata · ae1ba167
      由 Matthew Garrett 提交于 
      When EVM is enabled it forbids modification of metadata protected by
EVM unless there is already a valid EVM signature. If any modification
is made, the kernel will then generate a new EVM HMAC. However, this
does not map well on use cases which use only asymmetric EVM signatures,
as in this scenario the kernel is unable to generate new signatures.

This patch extends the /sys/kernel/security/evm interface to allow
userland to request that modification of these xattrs be permitted. This
is only permitted if no keys have already been loaded. In this
configuration, modifying the metadata will invalidate the EVM appraisal
on the file in question. This allows packaging systems to write out new
files, set the relevant extended attributes and then move them into
place.

There's also some refactoring of the use of evm_initialized in order to
avoid heading down codepaths that assume there's a key available.
Signed-off-by: NMatthew Garrett <mjg59@google.com>
Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      ae1ba167
  29. 09 12月, 2017 1 次提交
    • L
      usb: xhci: Add DbC support in xHCI driver · dfba2174
      由 Lu Baolu 提交于 
      xHCI compatible USB host controllers(i.e. super-speed USB3 controllers)
can be implemented with the Debug Capability(DbC). It presents a debug
device which is fully compliant with the USB framework and provides the
equivalent of a very high performance full-duplex serial link. The debug
capability operation model and registers interface are defined in 7.6.8
of the xHCI specification, revision 1.1.

The DbC debug device shares a root port with the xHCI host. By default,
the debug capability is disabled and the root port is assigned to xHCI.
When the DbC is enabled, the root port will be assigned to the DbC debug
device, and the xHCI sees nothing on this port. This implementation uses
a sysfs node named <dbc> under the xHCI device to manage the enabling
and disabling of the debug capability.

When the debug capability is enabled, it will present a debug device
through the debug port. This debug device is fully compliant with the
USB3 framework, and it can be enumerated by a debug host on the other
end of the USB link. As soon as the debug device is configured, a TTY
serial device named /dev/ttyDBC0 will be created.
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dfba2174
  31. 07 12月, 2017 1 次提交
    • M
      livepatch: force transition to finish · c99a2be7
      由 Miroslav Benes 提交于 
      If a task sleeps in a set of patched functions uninterruptedly, it could
block the whole transition indefinitely.  Thus it may be useful to clear
its TIF_PATCH_PENDING to allow the process to finish.

Admin can do that now by writing to force sysfs attribute in livepatch
sysfs directory. TIF_PATCH_PENDING is then cleared for all tasks and the
transition can finish successfully.

Important note! Administrator should not use this feature without a
clearance from a patch distributor. It must be checked that by doing so
the consistency model guarantees are not violated. Removal (rmmod) of
patch modules is permanently disabled when the feature is used. It
cannot be guaranteed there is no task sleeping in such module.
Signed-off-by: NMiroslav Benes <mbenes@suse.cz>
Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com>
Reviewed-by: NPetr Mladek <pmladek@suse.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      c99a2be7
  33. 05 12月, 2017 1 次提交
    • M
      livepatch: send a fake signal to all blocking tasks · 43347d56
      由 Miroslav Benes 提交于 
      Live patching consistency model is of LEAVE_PATCHED_SET and
SWITCH_THREAD. This means that all tasks in the system have to be marked
one by one as safe to call a new patched function. Safe means when a
task is not (sleeping) in a set of patched functions. That is, no
patched function is on the task's stack. Another clearly safe place is
the boundary between kernel and userspace. The patching waits for all
tasks to get outside of the patched set or to cross the boundary. The
transition is completed afterwards.

The problem is that a task can block the transition for quite a long
time, if not forever. It could sleep in a set of patched functions, for
example.  Luckily we can force the task to leave the set by sending it a
fake signal, that is a signal with no data in signal pending structures
(no handler, no sign of proper signal delivered). Suspend/freezer use
this to freeze the tasks as well. The task gets TIF_SIGPENDING set and
is woken up (if it has been sleeping in the kernel before) or kicked by
rescheduling IPI (if it was running on other CPU). This causes the task
to go to kernel/userspace boundary where the signal would be handled and
the task would be marked as safe in terms of live patching.

There are tasks which are not affected by this technique though. The
fake signal is not sent to kthreads. They should be handled differently.
They can be woken up so they leave the patched set and their
TIF_PATCH_PENDING can be cleared thanks to stack checking.

For the sake of completeness, if the task is in TASK_RUNNING state but
not currently running on some CPU it doesn't get the IPI, but it would
eventually handle the signal anyway. Second, if the task runs in the
kernel (in TASK_RUNNING state) it gets the IPI, but the signal is not
handled on return from the interrupt. It would be handled on return to
the userspace in the future when the fake signal is sent again. Stack
checking deals with these cases in a better way.

If the task was sleeping in a syscall it would be woken by our fake
signal, it would check if TIF_SIGPENDING is set (by calling
signal_pending() predicate) and return ERESTART* or EINTR. Syscalls with
ERESTART* return values are restarted in case of the fake signal (see
do_signal()). EINTR is propagated back to the userspace program. This
could disturb the program, but...

* each process dealing with signals should react accordingly to EINTR
  return values.
* syscalls returning EINTR happen to be quite common situation in the
  system even if no fake signal is sent.
* freezer sends the fake signal and does not deal with EINTR anyhow.
  Thus EINTR values are returned when the system is resumed.

The very safe marking is done in architectures' "entry" on syscall and
interrupt/exception exit paths, and in a stack checking functions of
livepatch.  TIF_PATCH_PENDING is cleared and the next
recalc_sigpending() drops TIF_SIGPENDING. In connection with this, also
call klp_update_patch_state() before do_signal(), so that
recalc_sigpending() in dequeue_signal() can clear TIF_PATCH_PENDING
immediately and thus prevent a double call of do_signal().

Note that the fake signal is not sent to stopped/traced tasks. Such task
prevents the patching to finish till it continues again (is not traced
anymore).

Last, sending the fake signal is not automatic. It is done only when
admin requests it by writing 1 to signal sysfs attribute in livepatch
sysfs directory.
Signed-off-by: NMiroslav Benes <mbenes@suse.cz>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: x86@kernel.org
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      43347d56
  35. 02 12月, 2017 1 次提交
  37. 09 11月, 2017 1 次提交
    • M
      EVM: Allow userspace to signal an RSA key has been loaded · f00d7975
      由 Matthew Garrett 提交于 
      EVM will only perform validation once a key has been loaded. This key
may either be a symmetric trusted key (for HMAC validation and creation)
or the public half of an asymmetric key (for digital signature
validation). The /sys/kernel/security/evm interface allows userland to
signal that a symmetric key has been loaded, but does not allow userland
to signal that an asymmetric public key has been loaded.

This patch extends the interface to permit userspace to pass a bitmask
of loaded key types. It also allows userspace to block loading of a
symmetric key in order to avoid a compromised system from being able to
load an additional key type later.
Signed-off-by: NMatthew Garrett <mjg59@google.com>
Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      f00d7975
  39. 08 11月, 2017 1 次提交
  41. 06 11月, 2017 3 次提交