[PATCH v7 0/8] Intel SGX Driver

[Jarkko Sakkinen]

Intel(R) SGX is a set of CPU instructions that can be used by applications to
set aside private regions of code and data. The code outside the enclave is
disallowed to access the memory inside the enclave by the CPU access control.
In a way you can think that SGX provides inverted sandbox. It protects the
application from a malicious host.

There is a new hardware unit in the processor called Memory Encryption Engine
(MEE) starting from the Skylake microacrhitecture. BIOS can define one or many
MEE regions that can hold enclave data by configuring them with PRMRR
registers.

The MEE automatically encrypts the data leaving the processor package to the
MEE regions. The data is encrypted using a random key whose life-time is
exactly one power cycle.

You can tell if your CPU supports SGX by looking into /proc/cpuinfo:

cat /proc/cpuinfo  | grep sgx

The GIT repositoy for SGX driver resides in

https://github.com/jsakkine-intel/linux-sgx.git

'le' branch contains the upstream candidate patches.

'master' branch contains the same patches with the following differences:

* top-level patch modifies the ioctl API to be SDK compatible
* does not use flexible launch control but instead relies on SDK provided
  Intel launch enclave.

v7:
* Fixed offset calculation in sgx_edbgr/wr(). Address was masked with PAGE_MASK
  when it should have been masked with ~PAGE_MASK.
* Fixed a memory leak in sgx_ioc_enclave_create().
* Simplified swapping code by using a pointer array for a cluster
  instead of a linked list.
* Squeezed struct sgx_encl_page to 32 bytes.
* Fixed deferencing of an RSA key on??OpenSSL 1.1.0.
* Modified TC's CMAC to use kernel AES-NI. Restructured the code
  a bit in order to better align with kernel conventions.

v6
* Fixed semaphore underrun when accessing /dev/sgx from the launch enclave.
* In sgx_encl_create() s/IS_ERR(secs)/IS_ERR(encl)/.
* Removed virtualization chapter from the documentation.
* Changed the default filename for the signing key as signing_key.pem.
* Reworked EPC management in a way that instead of a linked list of
  struct sgx_epc_page instances there is an array of integers that
  encodes address and bank of an EPC page (the same data as 'pa' field
  earlier). The locking has been moved to the EPC bank level instead
  of a global lock.
* Relaxed locking requirements for EPC management. EPC pages can be
  released back to the EPC bank concurrently.
* Cleaned up ptrace() code.
* Refined commit messages for new architectural constants.
* Sorted includes in every source file.
* Sorted local variable declarations according to the line length in
  every function.
* Style fixes based on Darren's comments to sgx_le.c.

v5:
* Described IPC between the Launch Enclave and kernel in the commit messages.
* Fixed all relevant checkpatch.pl issues that I have forgot fix in earlier
  versions except those that exist in the imported TinyCrypt code.
* Fixed spelling mistakes in the documentation.
* Forgot to check the return value of sgx_drv_subsys_init().
* Encapsulated properly page cache init and teardown.
* Collect epc pages to a temp list in sgx_add_epc_bank
* Removed SGX_ENCLAVE_INIT_ARCH constant.

v4:
* Tied life-cycle of the sgx_le_proxy process to /dev/sgx.
* Removed __exit annotation from sgx_drv_subsys_exit().
* Fixed a leak of a backing page in sgx_process_add_page_req() in the
  case when vm_insert_pfn() fails.
* Removed unused symbol exports for sgx_page_cache.c.
* Updated sgx_alloc_page() to require encl parameter and documented the
  behavior (Sean Christopherson).
* Refactored a more lean API for sgx_encl_find() and documented the behavior.
* Moved #PF handler to sgx_fault.c.
* Replaced subsys_system_register() with plain bus_register().
* Retry EINIT 2nd time only if MSRs are not locked.

v3:
* Check that FEATURE_CONTROL_LOCKED and FEATURE_CONTROL_SGX_ENABLE are set.
* Return -ERESTARTSYS in __sgx_encl_add_page() when sgx_alloc_page() fails.
* Use unused bits in epc_page->pa to store the bank number.
* Removed #ifdef for WQ_NONREENTRANT.
* If mmu_notifier_register() fails with -EINTR, return -ERESTARTSYS.
* Added --remove-section=.got.plt to objcopy flags in order to prevent a
  dummy .got.plt, which will cause an inconsistent size for the LE.
* Documented sgx_encl_* functions.
* Added remark about AES implementation used inside the LE.
* Removed redundant sgx_sys_exit() from le/main.c.
* Fixed struct sgx_secinfo alignment from 128 to 64 bytes.
* Validate miscselect in sgx_encl_create().
* Fixed SSA frame size calculation to take the misc region into account.
* Implemented consistent exception handling to __encls() and __encls_ret().
* Implemented a proper device model in order to allow sysfs attributes
  and in-kernel API.
* Cleaned up various "find enclave" implementations to the unified
  sgx_encl_find().
* Validate that vm_pgoff is zero.
* Discard backing pages with shmem_truncate_range() after EADD.
* Added missing EEXTEND operations to LE signing and launch.

Re: [PATCH v2] doc: convert printk-formats.txt to rst

[Markus Heiser]

> Am 07.12.2017 um 06:49 schrieb Tobin C. Harding :
> 
> Documentation/printk-formats.txt is a candidate for conversion to
> ReStructuredText format. Some effort has already been made to do this
> conversion even thought the suffix is currently .txt
> 
[...]
> 
> Signed-off-by: Tobin C. Harding 
> ---
> 
> v2:
> - Revert to use ASCII table.
> - Implement (or revert) changes as suggested by Randy Dunlap.
> - Change file location to core-api/ (inc required index changes) 
> - Remove some of the double back ticks.
> 
> Last two suggested by Jonathan Corbet.
> 

Hm, can't apply v2 on Jon's docs-next .. is the v2 patch on top of your v1?

If so, please take a look at our fabulously ;) documentation ..

 https://www.kernel.org/doc/html/latest/process/submitting-patches.html

"""
When you submit or resubmit a patch or patch series, include the complete patch 
description and justification for it. Don’t just say that this is version N of 
the patch (series). Don’t expect the subsystem maintainer to refer back to 
earlier patch versions or referenced URLs to find the patch description and put 
that into the patch. I.e., the patch (series) and its description should be 
self-contained. This benefits both the maintainers and reviewers. Some 
reviewers probably didn’t even receive earlier versions of the patch.

"""

-- Markus --

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 6/8] intel_sgx: driver documentation

[Jarkko Sakkinen]

Signed-off-by: Jarkko Sakkinen 
---
 Documentation/index.rst |   1 +
 Documentation/x86/intel_sgx.rst | 101 
 2 files changed, 102 insertions(+)
 create mode 100644 Documentation/x86/intel_sgx.rst

diff --git a/Documentation/index.rst b/Documentation/index.rst
index cb7f1ba5b3b1..ccfebc260e04 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -86,6 +86,7 @@ implementation.
:maxdepth: 2
 
sh/index
+   x86/index
 
 Korean translations
 ---
diff --git a/Documentation/x86/intel_sgx.rst b/Documentation/x86/intel_sgx.rst
new file mode 100644
index ..59049a35512f
--- /dev/null
+++ b/Documentation/x86/intel_sgx.rst
@@ -0,0 +1,101 @@
+===
+Intel(R) SGX driver
+===
+
+Introduction
+
+
+Intel(R) SGX is a set of CPU instructions that can be used by applications to
+set aside private regions of code and data. The code outside the enclave is
+disallowed to access the memory inside the enclave by the CPU access control.
+In a way you can think that SGX provides inverted sandbox. It protects the
+application from a malicious host.
+
+There is a new hardware unit in the processor called Memory Encryption Engine
+(MEE) starting from the Skylake microarchitecture. BIOS can define one or many
+MEE regions that can hold enclave data by configuring them with PRMRR 
registers.
+
+The MEE automatically encrypts the data leaving the processor package to the 
MEE
+regions. The data is encrypted using a random key whose life-time is exactly 
one
+power cycle.
+
+You can tell if your CPU supports SGX by looking into ``/proc/cpuinfo``:
+
+   ``cat /proc/cpuinfo  | grep sgx``
+
+Enclave data types
+==
+
+SGX defines new data types to maintain information about the enclaves and their
+security properties.
+
+The following data structures exist in MEE regions:
+
+* **Enclave Page Cache (EPC):** memory pages for protected code and data
+* **Enclave Page Cache Map (EPCM):** meta-data for each EPC page
+
+The Enclave Page Cache holds following types of pages:
+
+* **SGX Enclave Control Structure (SECS)**: meta-data defining the global
+  properties of an enclave such as range of addresses it can access.
+* **Regular (REG):** containing code and data for the enclave.
+* **Thread Control Structure (TCS):** defines an entry point for a hardware
+  thread to enter into the enclave. The enclave can only be entered through
+  these entry points.
+* **Version Array (VA)**: an EPC page receives a unique 8 byte version number
+  when it is swapped, which is then stored into a VA page. A VA page can hold 
up
+  to 512 version numbers.
+
+Launch control
+==
+
+For launching an enclave, two structures must be provided for ENCLS(EINIT):
+
+1. **SIGSTRUCT:** a signed measurement of the enclave binary.
+2. **EINITTOKEN:** the measurement, the public key of the signer and various
+   enclave attributes. This structure contains a MAC of its contents using
+   hardware derived symmetric key called *launch key*.
+
+The hardware platform contains a root key pair for signing the SIGTRUCT
+for a *launch enclave* that is able to acquire the *launch key* for
+creating EINITTOKEN's for other enclaves.  For the launch enclave
+EINITTOKEN is not needed because it is signed with the private root key.
+
+There are two feature control bits associate with launch control:
+
+* **IA32_FEATURE_CONTROL[0]**: locks down the feature control register
+* **IA32_FEATURE_CONTROL[17]**: allow runtime reconfiguration of
+  IA32_SGXLEPUBKEYHASHn MSRs that define MRSIGNER hash for the launch
+  enclave. Essentially they define a signing key that does not require
+  EINITTOKEN to be let run.
+
+The BIOS can configure IA32_SGXLEPUBKEYHASHn MSRs before feature control
+register is locked.
+
+It could be tempting to implement launch control by writing the MSRs
+every time when an enclave is launched. This does not scale because for
+generic case because BIOS might lock down the MSRs before handover to
+the OS.
+
+Debug enclaves
+--
+
+Enclave can be set as a *debug enclave* of which memory can be read or written
+by using the ENCLS(EDBGRD) and ENCLS(EDBGWR) opcodes. The Intel provided launch
+enclave provides them always a valid EINITTOKEN and therefore they are a low
+hanging fruit way to try out SGX.
+
+SGX uapi
+
+
+.. kernel-doc:: drivers/platform/x86/intel_sgx_ioctl.c
+   :functions: sgx_ioc_enclave_create
+   sgx_ioc_enclave_add_page
+   sgx_ioc_enclave_init
+
+.. kernel-doc:: arch/x86/include/uapi/asm/sgx.h
+
+References
+==
+
+* System Programming Manual: 39.1.4 Intel?? SGX Launch Control Configuration
-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

[gengdongjiu]

Hi James,

On 2017/12/7 3:04, James Morse wrote:
> Hi gengdongjiu,
> 
> On 06/12/17 10:26, gengdongjiu wrote:
>> On 2017/11/15 0:00, James Morse wrote:
 +   * error has not been propagated
 +   */
 +  run->exit_reason = KVM_EXIT_EXCEPTION;
 +  run->ex.exception = ESR_ELx_EC_SERROR;
 +  run->ex.error_code = KVM_SEI_SEV_RECOVERABLE;
 +  return 0;
>>> We should not pass RAS notifications to user space. The kernel either 
>>> handles
>>> them, or it panics(). User space shouldn't even know if the kernel supports 
>>> RAS
>>> until it gets an MCEERR signal.
>>>
>>> You're making your firmware-first notification an EL3->EL0 signal, 
>>> bypassing the OS.
>>>
>>> If we get a RAS SError and there are no CPER records or values in the ERR 
>>> nodes,
>>> we should panic as it looks like the CPU/firmware is broken. (spurious RAS 
>>> errors)
> 
>> do you think whether we need to set the guest ESR by user space?  if need, I 
>> need to
>> notify user space that there is a SError happen and need to set ESR for 
>> guest in some place of
>> KVM.
> 
> I think you are still coming from a world where user-space gets raw RAS
> notifications via KVM. This should not happen because the notification method 
> is
> private to firmware and the kernel. KVM is just in the way when a guest is 
> running.
> 
> Notifications reaching KVM should be plumbed into the APEI-firmware-first-code
> or eventually, a kernel-first mechanism if APEI doesn't 'claim' them.
> 
> The kernel RAS code may signal user-space with the symptoms of the error, and
> user-space may decided to generate a new RAS notification for the guest.
> 
> This should function in exactly the same way, regardless of which notification
> method is in use between the kernel and firmware. (its the only way to make 
> this
> future-proof).
> 
> Which notification user-space chooses to use entirely depends on what (if
> anything) it advertised to the guest in the HEST. User-space has to be in
> control of triggering any SError, not just overriding the ESR when KVM has
> decided it wants to kill the guest.

thanks, I will explain more.

> 
> 
>> so here I return a error code to user space. you mean we should not pass RAS 
>> notifications
>> to user space, so could you give some suggestion how to notify user space to 
>> set guest ESR.
> 
> KVM shouldn't give the guest an SError when it takes a RAS notification, it
> should pass the notification to the kernel RAS code. It only needs to 'fall
> through' to some default cause if both APEI and kernel-first 
> deny-all-knowledge
> of this notification.
> 
> 
> The end-to-end flow is then (assuming no-VHE):
> (1)An error occurs, taking the CPU to EL3.
> EL3: triage the error, generate CPER, notify the OS
> EL2: KVM takes the notification, exits the guest, returns to host EL1.
> EL1: KVM handle_exit() calls APEI to handle the error.
> This is the end of KVMs involvement in RAS - its just plumbing.
> 
> (2)APEI processes the CPER records and signals affected processes.
> If KVM's user-space is affected, KVM will spot the pending signal when it goes
> to re-enter the guest, and exit to user-space instead.
> Qemu takes the SIGBUS_MCEERR_A{O,R}.
> 
> (3) Qemu decides it wants to hand the guest a RAS error, it populates the CPER
> records (in memory only Qemu knows about), then drives the KVM API to make the
> appropriate notification appear.
> 
> 
> (1) only happens if the guest was running when the error arrived. GHES has ~4
> flavours of IRQ which may be used to describe corruption in guest memory. 
> Steps
> (2) and (3) are exactly the same in this case.
> 
> Qemu may decide to trigger RAS errors all by itself, (probably for testing and
> debugging), in which case (1) and (2) don't happen, but (3), is exactly the 
> same.
> 
> 
> This way platform-firmware/host-kernel can use kernel-first or firmware-first
> with any of the notifications, independently from Qemu/guest-kernel making a
> different kernel-first or firmware-first with different notifications.
> 
> Passing information out of KVM breaks this, forcing Qemu to know about the
> mechanism platform-firmware is using.
> 
> 
> We need to tackle (1) and (3) separately. For (3) we need some API that lets
> Qemu _trigger_ an SError in the guest, with a specified ESR. But, we don't 
> have
> a way of migrating pending SError yet... which is where I got stuck last time 
> I
> was looking at this.

I understand you most idea.

But In the Qemu one signal type can only correspond to one behavior, can not 
correspond to two behaviors,
otherwise Qemu will do not know how to do.

For the Qemu, if it receives the SIGBUS_MCEERR_AR signal, it will populate the 
CPER
records and inject a SEA to guest through KVM IOCTL "KVM_SET_ONE_REG"; if 
receives the SIGBUS_MCEERR_AO
signal, it will record the CPER and trigger a IRQ to notify guest, as shown 
below:

SIGBUS_MCEERR_AR trigger Synchronous External Abort.
SIGBUS_MCEERR_AO 

Re: [PATCH] doc: convert printk-formats.txt to rst

[Tobin C. Harding]

On Wed, Dec 06, 2017 at 04:39:58PM -0800, Randy Dunlap wrote:
> On 12/06/2017 01:16 PM, Tobin C. Harding wrote:
> > On Wed, Dec 06, 2017 at 10:18:49AM -0800, Randy Dunlap wrote:
> > 
> > Thanks for your comments Randy.
> > 
> 
> >>>  Documentation/index.rst|  10 +
> >>>  .../{printk-formats.txt => printk-formats.rst} | 295 
> >>> -
> >>>  lib/vsprintf.c | 160 +--
> >>>  3 files changed, 235 insertions(+), 230 deletions(-)
> >>>  rename Documentation/{printk-formats.txt => printk-formats.rst} (61%)
> >>
> >>> diff --git a/Documentation/printk-formats.txt 
> >>> b/Documentation/printk-formats.rst
> >>> similarity index 61%
> >>> rename from Documentation/printk-formats.txt
> >>> rename to Documentation/printk-formats.rst
> >>> index aa0a776c817a..51449d213748 100644
> >>> --- a/Documentation/printk-formats.txt
> >>> +++ b/Documentation/printk-formats.rst
> 
> >>> @@ -194,8 +233,8 @@ printing SSIDs.
> >>>  
> >>>  If field width is omitted the 1 byte only will be escaped.
> >>
> >>  then
> >> I think...
> > 
> > Ha ha, I was borderline with this change when doing this patch. It may
> > not appear so but I did try to do the minimal amount of changes while
> > improving correctness. I appreciate your comments since hopefully I can
> > better make these judgment calls next time.
> 
> I wasn't so sure about that attempt (at minimal changes).  :)

ROFL

> > Will change as suggested.
> 
> >>>  Where no additional specifiers are used the default big endian
> >>> -order with lower case hex characters will be printed.
> >>> +order with lower case hex digits will be printed.
> >>
> >> digits could imply base 10. but no big deal.
> > 
> > Are you sure about this? I was under the impression that when
> > representing a number the character set used are refereed to as 'digits'
> > irrespective of base.
> > 
> > hexadecimal digit
> > octal digit
> > digit (assumed base 10)
> > 
> > Open to correction though.
> 
> Like I said, I don't care strongly about this. (I'm easy.)
> but hex notation (like you said later) sounds good.

Got it.

thanks,
Tobin.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] usb: core: Add "quirks" parameter for usbcore

[Kai Heng Feng]

> On 6 Dec 2017, at 10:10 PM, Greg KH  wrote:
> 
> On Wed, Dec 06, 2017 at 06:26:21PM +0800, Kai-Heng Feng wrote:
>> Trying quirks in usbcore needs to rebuild the driver or the entire
>> kernel if it's builtin. It can save a lot of time if usbcore has similar
>> ability like "usbhid.quirks=" and "usb-storage.quirks=".
>> 
>> Rename the original quirk detection function to "static" as we introduce
>> this new "dynamic" function.
>> 
>> Now users can use "usbcore.quirks=" as short term workaround before the
>> next kernel release.
>> 
>> This is inspired by usbhid and usb-storage.
>> 
>> Signed-off-by: Kai-Heng Feng 
>> ---
>> v2: use in-kernel tolower() function.
>> 
>> Documentation/admin-guide/kernel-parameters.txt |  55 +
>> drivers/usb/core/quirks.c   | 100 
>> ++--
>> include/linux/usb/quirks.h  |   2 +
>> 3 files changed, 151 insertions(+), 6 deletions(-)
>> 
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
>> b/Documentation/admin-guide/kernel-parameters.txt
>> index 6571fbfdb2a1..d42fb278320b 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -4302,6 +4302,61 @@
>> 
>>  usbcore.nousb   [USB] Disable the USB subsystem
>> 
>> +usbcore.quirks=
>> +[USB] A list of quirks entries to supplement or
>> +override the built-in usb core quirk list.  List
>> +entries are separated by commas.  Each entry has
>> +the form VID:PID:Flags where VID and PID are Vendor
>> +and Product ID values (4-digit hex numbers) and
>> +Flags is a set of characters, each corresponding
>> +to a common usb core quirk flag as follows:
>> +a = USB_QUIRK_STRING_FETCH_255 (string
>> +descriptors must not be fetched using
>> +a 255-byte read);
>> +b = USB_QUIRK_RESET_RESUME (device can't resume
>> +correctly so reset it instead);
>> +c = USB_QUIRK_NO_SET_INTF (device can't handle
>> +Set-Interface requests);
>> +d = USB_QUIRK_CONFIG_INTF_STRINGS (device can't
>> +handle its Configuration or Interface
>> +strings);
>> +e = USB_QUIRK_RESET (device can't be reset
>> +(e.g morph devices), don't use reset);
>> +f = USB_QUIRK_HONOR_BNUMINTERFACES (device has
>> +more interface descriptions than the
>> +bNumInterfaces count, and can't handle
>> +talking to these interfaces);
>> +g = USB_QUIRK_DELAY_INIT (device needs a pause
>> +during initialization, after we read
>> +the device descriptor);
>> +h = USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL (For
>> +high speed and super speed interrupt
>> +endpoints, the USB 2.0 and USB 3.0 spec
>> +require the interval in microframes (1
>> +microframe = 125 microseconds) to be
>> +calculated as interval = 2 ^
>> +(bInterval-1).
>> +Devices with this quirk report their
>> +bInterval as the result of this
>> +calculation instead of the exponent
>> +variable used in the calculation);
>> +i = USB_QUIRK_DEVICE_QUALIFIER (device can't
>> +handle device_qualifier descriptor
>> +requests);
>> +j = USB_QUIRK_IGNORE_REMOTE_WAKEUP (device
>> +generates spurious wakeup, ignore
>> +remote wakeup capability);
>> +k = USB_QUIRK_NO_LPM (device can't handle Link
>> +Power Management);
>> +l = USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL
>> +(Device reports its bInterval as linear
>> +frames instead of the USB 2.0
>> +calculation);
>> +m = 

Re: [PATCH] docs: add documentation on printing kernel addresses

[Tobin C. Harding]

On Wed, Dec 06, 2017 at 04:43:40PM -0800, Kees Cook wrote:
> On Wed, Dec 6, 2017 at 4:26 PM, Tobin C. Harding  wrote:
> > Hashing addresses printed with printk specifier %p was implemented
> > recently. During development a number of issues were raised regarding
> > leaking kernel addresses to userspace. We should update the
> > documentation appropriately.
> >
> > Add documentation regarding printing kernel addresses.
> >
> > Signed-off-by: Tobin C. Harding 
> 
> Acked-by: Kees Cook 
> 
> > ---
> >
> > Is there a proffered method for subscripts in sphinx kernel docs? Here
> > we use '[*]'
> 
> Great question... I can't find an answer to this. :P
> 
> >
> > thanks,
> > Tobin.
> >
> >  Documentation/security/self-protection.rst | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/Documentation/security/self-protection.rst 
> > b/Documentation/security/self-protection.rst
> > index 60c8bd8b77bf..e711280cfdd7 100644
> > --- a/Documentation/security/self-protection.rst
> > +++ b/Documentation/security/self-protection.rst
> > @@ -270,6 +270,20 @@ attacks, it is important to defend against exposure of 
> > both kernel memory
> >  addresses and kernel memory contents (since they may contain kernel
> >  addresses or other sensitive things like canary values).
> >
> > +Kernel addresses
> > +
> > +
> > +Printing kernel addresses to userspace leaks sensitive information about
> > +the kernel memory layout. Care should be exercised when using any printk
> > +specifier that prints the raw address, currently %px, %p[ad], (and %p[sSb]
> > +in certain circumstances [*]).  Any file written to using one of these
> > +specifiers should be readable only by privileged processes.
> > +
> > +Kernels 4.14 and older printed the raw address using %p. As of 4.15-rc1
> > +addresses printed with the specifier %p are hashed before printing.
> > +
> > +[*] If symbol lookup fails, the raw address is currently printed.
> 
> Is there a plan to adjust this case?

RFC is in flight at the moment

[RFC 0/3] kallsyms: don't leak address when printing symbol

You commented already that you liked it. Had no response from Steve, I
was intending to give him two weeks and then put in the patch for
real.

Or I could put it in without the ftrace stuff and just break tracing -
just kidding, I wouldn't do that :)

thanks,
Tobin.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] doc: convert printk-formats.txt to rst

[Randy Dunlap]

On 12/05/2017 05:45 PM, Tobin C. Harding wrote:
> Documentation/printk-formats.txt is a candidate for conversion to
> ReStructuredText format. Some effort has already been made to do this
> conversion even thought the suffix is currently .txt
> 
> Changes required to complete conversion
> 
> - Add double backticks where needed.
> - Add entry to Documentation/index.rst
> - Use flat-table instead of ASCII table.
> - Fix minor grammatical errors.
> - Capitalize headers and correctly order heading adornments.

That's a style choice and an unneeded change (referring to Capitalize headers).

> - Use 'Passed by reference' uniformly.
> - Update pointer documentation around %px specifier.
> - Fix erroneous double backticks (to commas).
> - Simplify documentation for kobject.
> - Convert lib/vsnprintf.c function docs to use kernel-docs and
>   include in Documentation/printk-formats.rst

good idea.

> 
> Signed-off-by: Tobin C. Harding 
> ---
> 
> The last two need special reviewing please. In particular the conversion
> of kernel-docs in vsnprintf.c attempt was made to reduce documentation
> duplication with comments in the source code being simplified in order
> to be suitable for inclusion in Documentation/printk-formats.rst
> 
> I used -M when formatting the patch. If you don't like the diff with
> this flag just holla.
> 
> thanks,
> Tobin.
> 
>  Documentation/index.rst|  10 +
>  .../{printk-formats.txt => printk-formats.rst} | 295 
> -
>  lib/vsprintf.c | 160 +--
>  3 files changed, 235 insertions(+), 230 deletions(-)
>  rename Documentation/{printk-formats.txt => printk-formats.rst} (61%)

> diff --git a/Documentation/printk-formats.txt 
> b/Documentation/printk-formats.rst
> similarity index 61%
> rename from Documentation/printk-formats.txt
> rename to Documentation/printk-formats.rst
> index aa0a776c817a..51449d213748 100644
> --- a/Documentation/printk-formats.txt
> +++ b/Documentation/printk-formats.rst
> @@ -1,6 +1,6 @@
> -=
> -How to get printk format specifiers right
> -=
> +=
> +How to Get ``printk`` Format Specifiers Right
> +=
>  
>  :Author: Randy Dunlap 
>  :Author: Andrew Murray 
> @@ -8,56 +8,91 @@ How to get printk format specifiers right
>  Integer types
>  =
>  
> -::
> +For printing integer types, we have the following format specifiers:
> + 
> +   .. flat-table:: 
> +  :widths: 2 2
> +
> +  * - **Type**
> + - **Specifier**
> +
> +  * - ``int``
> +- ``%d`` or ``%x``
> +
> +  * - ``unsigned int``
> + - ``%u`` or ``%x``
> +
> +  * - ``long``
> + - ``%ld`` or ``%lx``
> +
> +  * - ``unsigned long``
> + - ``%lu`` or ``%lx``
> +
> +  * - ``long long``
> + - ``%lld`` or ``%llx``
>  
> - If variable is of Type, use printk format specifier:
> - 
> - int %d or %x
> - unsigned int%u or %x
> - long%ld or %lx
> - unsigned long   %lu or %lx
> - long long   %lld or %llx
> - unsigned long long  %llu or %llx
> - size_t  %zu or %zx
> - ssize_t %zd or %zx
> - s32 %d or %x
> - u32 %u or %x
> - s64 %lld or %llx
> - u64 %llu or %llx
> -
> -If  is dependent on a config option for its size (e.g., ``sector_t``,
> +  * - ``unsigned long long``
> + - ``%llu`` or ``%llx``
> +
> +  * - ``size_t``
> + - ``%zu`` or ``%zx``
> +
> +  * - ``ssize_t``
> + - ``%zd`` or ``%zx``
> +
> +  * - ``s32``
> + - ``%d`` or ``%x``
> +
> +  * - ``u32``
> + - ``%u`` or ``%x``
> +
> +  * - ``s64``
> + - ``%lld`` or ``%llx``
> +
> +  * - ``u64``
> + - ``%llu`` or ``%llx``
> +
> +
> +If  is dependent on a config option for its size (e.g., 
> ``sector_t``,
>  ``blkcnt_t``) or is architecture-dependent for its size (e.g., ``tcflag_t``),
>  use a format specifier of its largest possible type and explicitly cast to 
> it.
>  
>  Example::
>  
> - printk("test: sector number/total blocks: %llu/%llu\n",
> - (unsigned long long)sector, (unsigned long long)blockcount);
> + printk("test: total blocks: %llu\n", (unsigned long long)blockcount);
>  
> -Reminder: ``sizeof()`` result is of type ``size_t``.
> +Reminder: ``sizeof()`` returns type ``size_t``.
>  
> -The kernel's printf does not support ``%n``. For obvious reasons, floating
> +The kernel's printf does not support 

Re: [PATCH v2] MIPS: Add nonxstack=on|off kernel parameter

[Paul Burton]

Hi Maciej, Aleksandar,

On Wed, Dec 06, 2017 at 05:50:52PM +, Maciej W. Rozycki wrote:
>  What problem are you trying to solve anyway?  Is it not something that 
> can be handled with the `execstack' utility?

The commit message states that for Android "non-exec stack is required".
Is Android checking that then Aleksandar? If so, how? I presume what you
actually want here is for the kernel to lie & indicate to whatever part
of Android that performs this check that the stack is non-executable
even when it is really executable?

Is this aimed at the Android emulator? If so would it be possible to
instead implement RIXI support & make the non-exec stack actually work?

>  NB as someone has observed with programs that do not request a 
> non-executable stack we actually propagate the execute permission to all 
> data pages.  Is it not something we would want to handle differently?

It would of course be ideal to mark data/heap memory non-executable -
the question is how should we know that it's safe to do so. The approach
I took in 1a770b85c1f1 ("MIPS: non-exec stack & heap when non-exec
PT_GNU_STACK is present") was to require the PT_GNU_STACK header in
order to mark both stack & heap non-executable, for reasons outlined in
its commit message:

  - I was told at the time that no MIPS tools were yet emitting
PT_GNU_STACK, so we wouldn't be changing the behaviour of any
existing binaries & thus wouldn't break any.

  - It matches the behaviour of both ARM & x86.

Marking the heap non-executable by default would have advantages in that
we wouldn't need to worry about icache coherency for it in
set_pte_at()/__update_cache(), so one idea I had was that we could
possibly initially mark pages non-executable in the TLB & later enable
execution only if we take a TLBXI exception, with the assumption being
that in most cases we'll never try executing from the heap. That's not
an idea I've yet found the time to implement or measure the impact of
though.

Thanks,
Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] doc: convert printk-formats.txt to rst

[Jonathan Corbet]

On Wed,  6 Dec 2017 12:45:29 +1100
"Tobin C. Harding"  wrote:

> Documentation/printk-formats.txt is a candidate for conversion to
> ReStructuredText format. Some effort has already been made to do this
> conversion even thought the suffix is currently .txt
> 
> Changes required to complete conversion
> 
> - Add double backticks where needed.
> - Add entry to Documentation/index.rst
> - Use flat-table instead of ASCII table.
> - Fix minor grammatical errors.
> - Capitalize headers and correctly order heading adornments.
> - Use 'Passed by reference' uniformly.
> - Update pointer documentation around %px specifier.
> - Fix erroneous double backticks (to commas).
> - Simplify documentation for kobject.
> - Convert lib/vsnprintf.c function docs to use kernel-docs and
>   include in Documentation/printk-formats.rst
> 
> Signed-off-by: Tobin C. Harding 

Some comments from a quick review:

 - I would just put this into the core-api manual; we don't need to create
   a separate section for printk formats.

 - I agree with Markus and others about the table.  I think I would go a
   little further and encourage observance of the "use minimal markup"
   rule.  Lots of ``double backticks`` make for slightly nicer HTML/PDF
   output, but they come at the expense of plain-text readability, which
   is something we really don't want to sacrifice.

 - The vsprintf.c part is probably not for me to take, so it should be
   split out into a separate patch.

Thanks for working on this,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

[James Morse]

Hi gengdongjiu,

On 06/12/17 10:26, gengdongjiu wrote:
> On 2017/11/15 0:00, James Morse wrote:
>>> +* error has not been propagated
>>> +*/
>>> +   run->exit_reason = KVM_EXIT_EXCEPTION;
>>> +   run->ex.exception = ESR_ELx_EC_SERROR;
>>> +   run->ex.error_code = KVM_SEI_SEV_RECOVERABLE;
>>> +   return 0;
>> We should not pass RAS notifications to user space. The kernel either handles
>> them, or it panics(). User space shouldn't even know if the kernel supports 
>> RAS
>> until it gets an MCEERR signal.
>>
>> You're making your firmware-first notification an EL3->EL0 signal, bypassing 
>> the OS.
>>
>> If we get a RAS SError and there are no CPER records or values in the ERR 
>> nodes,
>> we should panic as it looks like the CPU/firmware is broken. (spurious RAS 
>> errors)

> do you think whether we need to set the guest ESR by user space?  if need, I 
> need to
> notify user space that there is a SError happen and need to set ESR for guest 
> in some place of
> KVM.

I think you are still coming from a world where user-space gets raw RAS
notifications via KVM. This should not happen because the notification method is
private to firmware and the kernel. KVM is just in the way when a guest is 
running.

Notifications reaching KVM should be plumbed into the APEI-firmware-first-code
or eventually, a kernel-first mechanism if APEI doesn't 'claim' them.

The kernel RAS code may signal user-space with the symptoms of the error, and
user-space may decided to generate a new RAS notification for the guest.

This should function in exactly the same way, regardless of which notification
method is in use between the kernel and firmware. (its the only way to make this
future-proof).

Which notification user-space chooses to use entirely depends on what (if
anything) it advertised to the guest in the HEST. User-space has to be in
control of triggering any SError, not just overriding the ESR when KVM has
decided it wants to kill the guest.


> so here I return a error code to user space. you mean we should not pass RAS 
> notifications
> to user space, so could you give some suggestion how to notify user space to 
> set guest ESR.

KVM shouldn't give the guest an SError when it takes a RAS notification, it
should pass the notification to the kernel RAS code. It only needs to 'fall
through' to some default cause if both APEI and kernel-first deny-all-knowledge
of this notification.


The end-to-end flow is then (assuming no-VHE):
(1)An error occurs, taking the CPU to EL3.
EL3: triage the error, generate CPER, notify the OS
EL2: KVM takes the notification, exits the guest, returns to host EL1.
EL1: KVM handle_exit() calls APEI to handle the error.
This is the end of KVMs involvement in RAS - its just plumbing.

(2)APEI processes the CPER records and signals affected processes.
If KVM's user-space is affected, KVM will spot the pending signal when it goes
to re-enter the guest, and exit to user-space instead.
Qemu takes the SIGBUS_MCEERR_A{O,R}.

(3) Qemu decides it wants to hand the guest a RAS error, it populates the CPER
records (in memory only Qemu knows about), then drives the KVM API to make the
appropriate notification appear.


(1) only happens if the guest was running when the error arrived. GHES has ~4
flavours of IRQ which may be used to describe corruption in guest memory. Steps
(2) and (3) are exactly the same in this case.

Qemu may decide to trigger RAS errors all by itself, (probably for testing and
debugging), in which case (1) and (2) don't happen, but (3), is exactly the 
same.


This way platform-firmware/host-kernel can use kernel-first or firmware-first
with any of the notifications, independently from Qemu/guest-kernel making a
different kernel-first or firmware-first with different notifications.

Passing information out of KVM breaks this, forcing Qemu to know about the
mechanism platform-firmware is using.


We need to tackle (1) and (3) separately. For (3) we need some API that lets
Qemu _trigger_ an SError in the guest, with a specified ESR. But, we don't have
a way of migrating pending SError yet... which is where I got stuck last time I
was looking at this.



James
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: core: Add "quirks" parameter for usbcore

[Greg KH]

On Wed, Dec 06, 2017 at 05:09:32PM +0800, Kai-Heng Feng wrote:
> +/* Works only for digits and letters, but small and fast */
> +#define TOLOWER(x) ((x) | 0x20)

What is wrong with the in-kernel version of tolower()?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: core: Add "quirks" parameter for usbcore

[Kai Heng Feng]

> On 6 Dec 2017, at 5:13 PM, Greg KH  wrote:
> 
> On Wed, Dec 06, 2017 at 05:09:32PM +0800, Kai-Heng Feng wrote:
>> +/* Works only for digits and letters, but small and fast */
>> +#define TOLOWER(x) ((x) | 0x20)
> 
> What is wrong with the in-kernel version of tolower()?

Nothing’s wrong with the in-kernel version. I’ll use that in v2.

Other than that, is there anythings I can make to improve the code?

Kai-Heng

> 
> thanks,
> 
> greg k-h

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: core: Add "quirks" parameter for usbcore

[Kai-Heng Feng]

Trying quirks in usbcore needs to rebuild the driver or the entire
kernel if it's builtin. It can save a lot of time if usbcore has similar
ability like "usbhid.quirks=" and "usb-storage.quirks=".

Rename the original quirk detection function to "static" as we introduce
this new "dynamic" function.

Now users can use "usbcore.quirks=" as short term workaround before the
next kernel release.

This is inspired by usbhid and usb-storage.

Signed-off-by: Kai-Heng Feng 
---
 Documentation/admin-guide/kernel-parameters.txt |  55 +
 drivers/usb/core/quirks.c   | 103 ++--
 include/linux/usb/quirks.h  |   2 +
 3 files changed, 154 insertions(+), 6 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 6571fbfdb2a1..f1cb31aa25e3 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4302,6 +4302,61 @@
 
usbcore.nousb   [USB] Disable the USB subsystem
 
+   usbcore.quirks=
+   [USB] A list of quirks entries to supplement or
+   override the built-in usb core quirk list.  List
+   entries are separated by commas.  Each entry has
+   the form VID:PID:Flags where VID and PID are Vendor
+   and Product ID values (4-digit hex numbers) and
+   Flags is a set of characters, each corresponding
+   to a common usb core quirk flag as follows:
+   a = USB_QUIRK_STRING_FETCH_255 (string
+   descriptors must not be fetched using
+   a 255-byte read);
+   b = USB_QUIRK_RESET_RESUME (device can't resume
+   correctly so reset it instead);
+   c = USB_QUIRK_NO_SET_INTF (device can't handle
+   Set-Interface requests);
+   d = USB_QUIRK_CONFIG_INTF_STRINGS (device can't
+   handle its Configuration or Interface
+   strings);
+   e = USB_QUIRK_RESET (device can't be reset
+   (e.g morph devices), don't use reset);
+   f = USB_QUIRK_HONOR_BNUMINTERFACES (device has
+   more interface descriptions than the
+   bNumInterfaces count, and can't handle
+   talking to these interfaces);
+   g = USB_QUIRK_DELAY_INIT (device needs a pause
+   during initialization, after we read
+   the device descriptor);
+   h = USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL (For
+   high speed and super speed interrupt
+   endpoints, the USB 2.0 and USB 3.0 spec
+   require the interval in microframes (1
+   microframe = 125 microseconds) to be
+   calculated as interval = 2 ^
+   (bInterval-1).
+   Devices with this quirk report their
+   bInterval as the result of this
+   calculation instead of the exponent
+   variable used in the calculation);
+   i = USB_QUIRK_DEVICE_QUALIFIER (device can't
+   handle device_qualifier descriptor
+   requests);
+   j = USB_QUIRK_IGNORE_REMOTE_WAKEUP (device
+   generates spurious wakeup, ignore
+   remote wakeup capability);
+   k = USB_QUIRK_NO_LPM (device can't handle Link
+   Power Management);
+   l = USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL
+   (Device reports its bInterval as linear
+   frames instead of the USB 2.0
+   calculation);
+   m = USB_QUIRK_DISCONNECT_SUSPEND (Device needs
+   to be disconnected before suspend to
+   prevent spurious wakeup)
+   Example: quirks=0781:5580:bk,0a5c:5834:gij
+
usbhid.mousepoll=
 

RE: [PATCH v2] MIPS: Add nonxstack=on|off kernel parameter

[Maciej W. Rozycki]

Hi Miodrag,

> When kernel is detecting the type of mapping it should apply :
> 
> fs/binfmt_elf.c:
> ...
>   if (elf_read_implies_exec(loc->elf_ex, executable_stack))
>   current->personality |= READ_IMPLIES_EXEC;
> ...
> 
> this effectively calls mips_elf_read_implies_exec() which performs a check:
> ...
>   if (!cpu_has_rixi) {
>   /* The CPU doesn't support non-executable memory */
>   return 1;
>   }
> 
>   return 0;
> }
> 
> This will in turn make stack & heap executable on processors without 
> RIXI, which are practically all processors with MIPS ISA R < 6.
> 
> We would like to have an option to override this and force 
> non-executable mappings for such systems.

 Of course you can't force a non-executable mapping with a system where 
all valid pages are executable, as David has already noted.  Did you mean 
the other condition, that is:

if (exstack != EXSTACK_DISABLE_X) {
/* The binary doesn't request a non-executable stack */
return 1;
}

?  In which case you do want to respect the lack of the RIXI feature, 
i.e.:

int mips_elf_read_implies_exec(void *elf_ex, int exstack)
{
if (!cpu_has_rixi) {
/* The CPU doesn't support non-executable memory */
return 1;
}

switch (nonxstack) {
case EXSTACK_DISABLE_X:
return 0;
case EXSTACK_ENABLE_X:
return 1;
default:
break;
}

if (exstack != EXSTACK_DISABLE_X) {
/* The binary doesn't request a non-executable stack */
return 1;
}

return 0;
}

(I'd replace `break' with `return exstack != EXSTACK_DISABLE_X' and 
discard the code that follows, but that can be a separate optimisation).

 What problem are you trying to solve anyway?  Is it not something that 
can be handled with the `execstack' utility?

 NB as someone has observed with programs that do not request a 
non-executable stack we actually propagate the execute permission to all 
data pages.  Is it not something we would want to handle differently?

  Maciej
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] doc: convert printk-formats.txt to rst

[Randy Dunlap]

On 12/05/2017 11:35 PM, Joe Perches wrote:
> On Wed, 2017-12-06 at 08:11 +0100, Markus Heiser wrote:
>>> Am 06.12.2017 um 02:45 schrieb Tobin C. Harding :
>>> Documentation/printk-formats.txt is a candidate for conversion to
>>> ReStructuredText format. Some effort has already been made to do this
>>> conversion even thought the suffix is currently .txt
> []
>> just a question .. might it be better we stay with ASCII table
>> in cases like this. I guess this table won't changed often.
>> The flat-table directive is good for big and therefore frequently 
>> changed tables where a small precise diff reduce the patch.
>> But flat-table is also hard to read in plain text. Its a balancing
>> and thats my opinion, lets hear what other say ...
> 
> I think the proposed conversion is unreadable
> and the original table quite clear.

Agree.


-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] doc: convert printk-formats.txt to rst

[Tobin C. Harding]

On Wed, Dec 06, 2017 at 10:18:49AM -0800, Randy Dunlap wrote:

Thanks for your comments Randy.

> On 12/05/2017 05:45 PM, Tobin C. Harding wrote:
> > Documentation/printk-formats.txt is a candidate for conversion to
> > ReStructuredText format. Some effort has already been made to do this
> > conversion even thought the suffix is currently .txt
> > 
> > Changes required to complete conversion
> > 
> > - Add double backticks where needed.
> > - Add entry to Documentation/index.rst
> > - Use flat-table instead of ASCII table.
> > - Fix minor grammatical errors.
> > - Capitalize headers and correctly order heading adornments.
> 
> That's a style choice and an unneeded change (referring to Capitalize 
> headers).

No worries, will revert.

> > - Use 'Passed by reference' uniformly.
> > - Update pointer documentation around %px specifier.
> > - Fix erroneous double backticks (to commas).
> > - Simplify documentation for kobject.
> > - Convert lib/vsnprintf.c function docs to use kernel-docs and
> >   include in Documentation/printk-formats.rst
> 
> good idea.
>
> > 
> > Signed-off-by: Tobin C. Harding 
> > ---
> > 
> > The last two need special reviewing please. In particular the conversion
> > of kernel-docs in vsnprintf.c attempt was made to reduce documentation
> > duplication with comments in the source code being simplified in order
> > to be suitable for inclusion in Documentation/printk-formats.rst
> > 
> > I used -M when formatting the patch. If you don't like the diff with
> > this flag just holla.
> > 
> > thanks,
> > Tobin.
> > 
> >  Documentation/index.rst|  10 +
> >  .../{printk-formats.txt => printk-formats.rst} | 295 
> > -
> >  lib/vsprintf.c | 160 +--
> >  3 files changed, 235 insertions(+), 230 deletions(-)
> >  rename Documentation/{printk-formats.txt => printk-formats.rst} (61%)
> 
> > diff --git a/Documentation/printk-formats.txt 
> > b/Documentation/printk-formats.rst
> > similarity index 61%
> > rename from Documentation/printk-formats.txt
> > rename to Documentation/printk-formats.rst
> > index aa0a776c817a..51449d213748 100644
> > --- a/Documentation/printk-formats.txt
> > +++ b/Documentation/printk-formats.rst
> > @@ -1,6 +1,6 @@
> > -=
> > -How to get printk format specifiers right
> > -=
> > +=
> > +How to Get ``printk`` Format Specifiers Right
> > +=
> >  
> >  :Author: Randy Dunlap 
> >  :Author: Andrew Murray 
> > @@ -8,56 +8,91 @@ How to get printk format specifiers right
> >  Integer types
> >  =
> >  
> > -::
> > +For printing integer types, we have the following format specifiers:
> > +   
> > +   .. flat-table:: 
> > +  :widths: 2 2
> > +
> > +  * - **Type**
> > +   - **Specifier**
> > +
> > +  * - ``int``
> > +- ``%d`` or ``%x``
> > +
> > +  * - ``unsigned int``
> > +   - ``%u`` or ``%x``
> > +
> > +  * - ``long``
> > +   - ``%ld`` or ``%lx``
> > +
> > +  * - ``unsigned long``
> > +   - ``%lu`` or ``%lx``
> > +
> > +  * - ``long long``
> > +   - ``%lld`` or ``%llx``
> >  
> > -   If variable is of Type, use printk format specifier:
> > -   
> > -   int %d or %x
> > -   unsigned int%u or %x
> > -   long%ld or %lx
> > -   unsigned long   %lu or %lx
> > -   long long   %lld or %llx
> > -   unsigned long long  %llu or %llx
> > -   size_t  %zu or %zx
> > -   ssize_t %zd or %zx
> > -   s32 %d or %x
> > -   u32 %u or %x
> > -   s64 %lld or %llx
> > -   u64 %llu or %llx
> > -
> > -If  is dependent on a config option for its size (e.g., ``sector_t``,
> > +  * - ``unsigned long long``
> > +   - ``%llu`` or ``%llx``
> > +
> > +  * - ``size_t``
> > +   - ``%zu`` or ``%zx``
> > +
> > +  * - ``ssize_t``
> > +   - ``%zd`` or ``%zx``
> > +
> > +  * - ``s32``
> > +   - ``%d`` or ``%x``
> > +
> > +  * - ``u32``
> > +   - ``%u`` or ``%x``
> > +
> > +  * - ``s64``
> > +   - ``%lld`` or ``%llx``
> > +
> > +  * - ``u64``
> > +   - ``%llu`` or ``%llx``
> > +
> > +
> > +If  is dependent on a config option for its size (e.g., 
> > ``sector_t``,
> >  ``blkcnt_t``) or is architecture-dependent for its size (e.g., 
> > ``tcflag_t``),
> >  use a format specifier of its largest possible type and explicitly cast to 
> > it.
> >  
> >  Example::
> >  
> > -   printk("test: sector number/total blocks: %llu/%llu\n",
> > -   (unsigned long 

Re: [PATCH] doc: convert printk-formats.txt to rst

[Tobin C. Harding]

On Wed, Dec 06, 2017 at 11:23:25AM -0700, Jonathan Corbet wrote:
> On Wed,  6 Dec 2017 12:45:29 +1100
> "Tobin C. Harding"  wrote:
> 
> > Documentation/printk-formats.txt is a candidate for conversion to
> > ReStructuredText format. Some effort has already been made to do this
> > conversion even thought the suffix is currently .txt
> > 
> > Changes required to complete conversion
> > 
> > - Add double backticks where needed.
> > - Add entry to Documentation/index.rst
> > - Use flat-table instead of ASCII table.
> > - Fix minor grammatical errors.
> > - Capitalize headers and correctly order heading adornments.
> > - Use 'Passed by reference' uniformly.
> > - Update pointer documentation around %px specifier.
> > - Fix erroneous double backticks (to commas).
> > - Simplify documentation for kobject.
> > - Convert lib/vsnprintf.c function docs to use kernel-docs and
> >   include in Documentation/printk-formats.rst
> > 
> > Signed-off-by: Tobin C. Harding 
> 
> Some comments from a quick review:
> 
>  - I would just put this into the core-api manual; we don't need to create
>a separate section for printk formats.

Cool, I was hoping you'd give some direction on this. thanks.

>  - I agree with Markus and others about the table.  I think I would go a
>little further and encourage observance of the "use minimal markup"
>rule.  Lots of ``double backticks`` make for slightly nicer HTML/PDF
>output, but they come at the expense of plain-text readability, which
>is something we really don't want to sacrifice.

Great. I personally don't read docs in HTML/PDF so I like this ruling.

>  - The vsprintf.c part is probably not for me to take, so it should be
>split out into a separate patch.

I'm much less experienced than you Jon so please say if I am wrong but
since the rst file depends on the changes to vsprintf.c wouldn't it be
better if the changes went into the mainline together. I can split it
into a two patch set if that is cleaner but putting the two patches
through different trees seems like a bad idea because of the
dependency. For what it's worth, I don't believe lib/vsprintf.c has a
maintainer. Linus took changes to that file from my tree just
recently. I don't know how this stuff works though in regards to merge
conflicts. (Please take everything I say here with a pinch of salt since
I have only maintained a tree for a few weeks now.)

thanks,
Tobin.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: core: Add "quirks" parameter for usbcore

[Oliver Neukum]

Am Mittwoch, den 06.12.2017, 17:09 +0800 schrieb Kai-Heng Feng:
> Now users can use "usbcore.quirks=" as short term workaround before the
> next kernel release.
> 
> This is inspired by usbhid and usb-storage.

Hi,

if you include this for debugging purposes, it would be interesting
to be able to not only switch on a quirk from the command line, but
to also switch it off. So it might be better to detect the dynamic
quirks after the static quirks and use XOR.

Regards
Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

[gengdongjiu]

On 2017/11/15 0:00, James Morse wrote:
>> + * error has not been propagated
>> + */
>> +run->exit_reason = KVM_EXIT_EXCEPTION;
>> +run->ex.exception = ESR_ELx_EC_SERROR;
>> +run->ex.error_code = KVM_SEI_SEV_RECOVERABLE;
>> +return 0;
> We should not pass RAS notifications to user space. The kernel either handles
> them, or it panics(). User space shouldn't even know if the kernel supports 
> RAS
> until it gets an MCEERR signal.
> 
> You're making your firmware-first notification an EL3->EL0 signal, bypassing 
> the OS.
> 
> If we get a RAS SError and there are no CPER records or values in the ERR 
> nodes,
> we should panic as it looks like the CPU/firmware is broken. (spurious RAS 
> errors)

Hi james,
  sorry to disturb you!

  do you think whether we need to set the guest ESR by user space?  if need, I 
need to
notify user space that there is a SError happen and need to set ESR for guest 
in some place of
KVM. so here I return a error code to user space. you mean we should not pass 
RAS notifications
to user space, so could you give some suggestion how to notify user space to 
set guest ESR.

Thanks a lot in advance.


> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] usb: core: Add "quirks" parameter for usbcore

[Kai-Heng Feng]

Trying quirks in usbcore needs to rebuild the driver or the entire
kernel if it's builtin. It can save a lot of time if usbcore has similar
ability like "usbhid.quirks=" and "usb-storage.quirks=".

Rename the original quirk detection function to "static" as we introduce
this new "dynamic" function.

Now users can use "usbcore.quirks=" as short term workaround before the
next kernel release.

This is inspired by usbhid and usb-storage.

Signed-off-by: Kai-Heng Feng 
---
v2: use in-kernel tolower() function.

 Documentation/admin-guide/kernel-parameters.txt |  55 +
 drivers/usb/core/quirks.c   | 100 ++--
 include/linux/usb/quirks.h  |   2 +
 3 files changed, 151 insertions(+), 6 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 6571fbfdb2a1..d42fb278320b 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4302,6 +4302,61 @@
 
usbcore.nousb   [USB] Disable the USB subsystem
 
+   usbcore.quirks=
+   [USB] A list of quirks entries to supplement or
+   override the built-in usb core quirk list.  List
+   entries are separated by commas.  Each entry has
+   the form VID:PID:Flags where VID and PID are Vendor
+   and Product ID values (4-digit hex numbers) and
+   Flags is a set of characters, each corresponding
+   to a common usb core quirk flag as follows:
+   a = USB_QUIRK_STRING_FETCH_255 (string
+   descriptors must not be fetched using
+   a 255-byte read);
+   b = USB_QUIRK_RESET_RESUME (device can't resume
+   correctly so reset it instead);
+   c = USB_QUIRK_NO_SET_INTF (device can't handle
+   Set-Interface requests);
+   d = USB_QUIRK_CONFIG_INTF_STRINGS (device can't
+   handle its Configuration or Interface
+   strings);
+   e = USB_QUIRK_RESET (device can't be reset
+   (e.g morph devices), don't use reset);
+   f = USB_QUIRK_HONOR_BNUMINTERFACES (device has
+   more interface descriptions than the
+   bNumInterfaces count, and can't handle
+   talking to these interfaces);
+   g = USB_QUIRK_DELAY_INIT (device needs a pause
+   during initialization, after we read
+   the device descriptor);
+   h = USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL (For
+   high speed and super speed interrupt
+   endpoints, the USB 2.0 and USB 3.0 spec
+   require the interval in microframes (1
+   microframe = 125 microseconds) to be
+   calculated as interval = 2 ^
+   (bInterval-1).
+   Devices with this quirk report their
+   bInterval as the result of this
+   calculation instead of the exponent
+   variable used in the calculation);
+   i = USB_QUIRK_DEVICE_QUALIFIER (device can't
+   handle device_qualifier descriptor
+   requests);
+   j = USB_QUIRK_IGNORE_REMOTE_WAKEUP (device
+   generates spurious wakeup, ignore
+   remote wakeup capability);
+   k = USB_QUIRK_NO_LPM (device can't handle Link
+   Power Management);
+   l = USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL
+   (Device reports its bInterval as linear
+   frames instead of the USB 2.0
+   calculation);
+   m = USB_QUIRK_DISCONNECT_SUSPEND (Device needs
+   to be disconnected before suspend to
+   prevent spurious wakeup)
+   Example: 

Re: [PATCH] doc: convert printk-formats.txt to rst

[Tobin C. Harding]

On Wed, Dec 06, 2017 at 10:18:49AM -0800, Randy Dunlap wrote:
> On 12/05/2017 05:45 PM, Tobin C. Harding wrote:
> > Documentation/printk-formats.txt is a candidate for conversion to
> > ReStructuredText format. Some effort has already been made to do this
> > conversion even thought the suffix is currently .txt
> > 
> > Changes required to complete conversion
> > 
> > - Add double backticks where needed.
> > - Add entry to Documentation/index.rst
> > - Use flat-table instead of ASCII table.
> > - Fix minor grammatical errors.
> > - Capitalize headers and correctly order heading adornments.
> 
> That's a style choice and an unneeded change (referring to Capitalize 
> headers).
> 
> > - Use 'Passed by reference' uniformly.
> > - Update pointer documentation around %px specifier.
> > - Fix erroneous double backticks (to commas).
> > - Simplify documentation for kobject.
> > - Convert lib/vsnprintf.c function docs to use kernel-docs and
> >   include in Documentation/printk-formats.rst
> 
> good idea.
> 
> > 
> > Signed-off-by: Tobin C. Harding 
> > ---
> > 
> > The last two need special reviewing please. In particular the conversion
> > of kernel-docs in vsnprintf.c attempt was made to reduce documentation
> > duplication with comments in the source code being simplified in order
> > to be suitable for inclusion in Documentation/printk-formats.rst
> > 
> > I used -M when formatting the patch. If you don't like the diff with
> > this flag just holla.
> > 
> > thanks,
> > Tobin.
> > 
> >  Documentation/index.rst|  10 +
> >  .../{printk-formats.txt => printk-formats.rst} | 295 
> > -
> >  lib/vsprintf.c | 160 +--
> >  3 files changed, 235 insertions(+), 230 deletions(-)
> >  rename Documentation/{printk-formats.txt => printk-formats.rst} (61%)
> 
> > diff --git a/Documentation/printk-formats.txt 
> > b/Documentation/printk-formats.rst
> > similarity index 61%
> > rename from Documentation/printk-formats.txt
> > rename to Documentation/printk-formats.rst
> > index aa0a776c817a..51449d213748 100644
> > --- a/Documentation/printk-formats.txt
> > +++ b/Documentation/printk-formats.rst
> > @@ -1,6 +1,6 @@
> > -=
> > -How to get printk format specifiers right
> > -=
> > +=
> > +How to Get ``printk`` Format Specifiers Right
> > +=
> >  
> >  :Author: Randy Dunlap 
> >  :Author: Andrew Murray 
> > @@ -8,56 +8,91 @@ How to get printk format specifiers right
> >  Integer types
> >  =
> >  
> > -::
> > +For printing integer types, we have the following format specifiers:
> > +   
> > +   .. flat-table:: 
> > +  :widths: 2 2
> > +
> > +  * - **Type**
> > +   - **Specifier**
> > +
> > +  * - ``int``
> > +- ``%d`` or ``%x``
> > +
> > +  * - ``unsigned int``
> > +   - ``%u`` or ``%x``
> > +
> > +  * - ``long``
> > +   - ``%ld`` or ``%lx``
> > +
> > +  * - ``unsigned long``
> > +   - ``%lu`` or ``%lx``
> > +
> > +  * - ``long long``
> > +   - ``%lld`` or ``%llx``
> >  
> > -   If variable is of Type, use printk format specifier:
> > -   
> > -   int %d or %x
> > -   unsigned int%u or %x
> > -   long%ld or %lx
> > -   unsigned long   %lu or %lx
> > -   long long   %lld or %llx
> > -   unsigned long long  %llu or %llx
> > -   size_t  %zu or %zx
> > -   ssize_t %zd or %zx
> > -   s32 %d or %x
> > -   u32 %u or %x
> > -   s64 %lld or %llx
> > -   u64 %llu or %llx
> > -
> > -If  is dependent on a config option for its size (e.g., ``sector_t``,
> > +  * - ``unsigned long long``
> > +   - ``%llu`` or ``%llx``
> > +
> > +  * - ``size_t``
> > +   - ``%zu`` or ``%zx``
> > +
> > +  * - ``ssize_t``
> > +   - ``%zd`` or ``%zx``
> > +
> > +  * - ``s32``
> > +   - ``%d`` or ``%x``
> > +
> > +  * - ``u32``
> > +   - ``%u`` or ``%x``
> > +
> > +  * - ``s64``
> > +   - ``%lld`` or ``%llx``
> > +
> > +  * - ``u64``
> > +   - ``%llu`` or ``%llx``
> > +
> > +
> > +If  is dependent on a config option for its size (e.g., 
> > ``sector_t``,
> >  ``blkcnt_t``) or is architecture-dependent for its size (e.g., 
> > ``tcflag_t``),
> >  use a format specifier of its largest possible type and explicitly cast to 
> > it.
> >  
> >  Example::
> >  
> > -   printk("test: sector number/total blocks: %llu/%llu\n",
> > -   (unsigned long long)sector, (unsigned long long)blockcount);
> > +   

[PATCH] docs: add documentation on printing kernel addresses

[Tobin C. Harding]

Hashing addresses printed with printk specifier %p was implemented
recently. During development a number of issues were raised regarding
leaking kernel addresses to userspace. We should update the
documentation appropriately.

Add documentation regarding printing kernel addresses.

Signed-off-by: Tobin C. Harding 
---

Is there a proffered method for subscripts in sphinx kernel docs? Here
we use '[*]' 

thanks,
Tobin.

 Documentation/security/self-protection.rst | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/security/self-protection.rst 
b/Documentation/security/self-protection.rst
index 60c8bd8b77bf..e711280cfdd7 100644
--- a/Documentation/security/self-protection.rst
+++ b/Documentation/security/self-protection.rst
@@ -270,6 +270,20 @@ attacks, it is important to defend against exposure of 
both kernel memory
 addresses and kernel memory contents (since they may contain kernel
 addresses or other sensitive things like canary values).
 
+Kernel addresses
+
+
+Printing kernel addresses to userspace leaks sensitive information about
+the kernel memory layout. Care should be exercised when using any printk
+specifier that prints the raw address, currently %px, %p[ad], (and %p[sSb]
+in certain circumstances [*]).  Any file written to using one of these
+specifiers should be readable only by privileged processes.
+
+Kernels 4.14 and older printed the raw address using %p. As of 4.15-rc1
+addresses printed with the specifier %p are hashed before printing.
+
+[*] If symbol lookup fails, the raw address is currently printed.
+
 Unique identifiers
 --
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] docs: add documentation on printing kernel addresses

[Kees Cook]

On Wed, Dec 6, 2017 at 4:26 PM, Tobin C. Harding  wrote:
> Hashing addresses printed with printk specifier %p was implemented
> recently. During development a number of issues were raised regarding
> leaking kernel addresses to userspace. We should update the
> documentation appropriately.
>
> Add documentation regarding printing kernel addresses.
>
> Signed-off-by: Tobin C. Harding 

Acked-by: Kees Cook 

> ---
>
> Is there a proffered method for subscripts in sphinx kernel docs? Here
> we use '[*]'

Great question... I can't find an answer to this. :P

>
> thanks,
> Tobin.
>
>  Documentation/security/self-protection.rst | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/Documentation/security/self-protection.rst 
> b/Documentation/security/self-protection.rst
> index 60c8bd8b77bf..e711280cfdd7 100644
> --- a/Documentation/security/self-protection.rst
> +++ b/Documentation/security/self-protection.rst
> @@ -270,6 +270,20 @@ attacks, it is important to defend against exposure of 
> both kernel memory
>  addresses and kernel memory contents (since they may contain kernel
>  addresses or other sensitive things like canary values).
>
> +Kernel addresses
> +
> +
> +Printing kernel addresses to userspace leaks sensitive information about
> +the kernel memory layout. Care should be exercised when using any printk
> +specifier that prints the raw address, currently %px, %p[ad], (and %p[sSb]
> +in certain circumstances [*]).  Any file written to using one of these
> +specifiers should be readable only by privileged processes.
> +
> +Kernels 4.14 and older printed the raw address using %p. As of 4.15-rc1
> +addresses printed with the specifier %p are hashed before printing.
> +
> +[*] If symbol lookup fails, the raw address is currently printed.

Is there a plan to adjust this case?

Thanks!

-Kees

> +
>  Unique identifiers
>  --
>
> --
> 2.7.4
>



-- 
Kees Cook
Pixel Security
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] usb: core: Add "quirks" parameter for usbcore

[Greg KH]

On Wed, Dec 06, 2017 at 06:26:21PM +0800, Kai-Heng Feng wrote:
> Trying quirks in usbcore needs to rebuild the driver or the entire
> kernel if it's builtin. It can save a lot of time if usbcore has similar
> ability like "usbhid.quirks=" and "usb-storage.quirks=".
> 
> Rename the original quirk detection function to "static" as we introduce
> this new "dynamic" function.
> 
> Now users can use "usbcore.quirks=" as short term workaround before the
> next kernel release.
> 
> This is inspired by usbhid and usb-storage.
> 
> Signed-off-by: Kai-Heng Feng 
> ---
> v2: use in-kernel tolower() function.
> 
>  Documentation/admin-guide/kernel-parameters.txt |  55 +
>  drivers/usb/core/quirks.c   | 100 
> ++--
>  include/linux/usb/quirks.h  |   2 +
>  3 files changed, 151 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index 6571fbfdb2a1..d42fb278320b 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4302,6 +4302,61 @@
>  
>   usbcore.nousb   [USB] Disable the USB subsystem
>  
> + usbcore.quirks=
> + [USB] A list of quirks entries to supplement or
> + override the built-in usb core quirk list.  List
> + entries are separated by commas.  Each entry has
> + the form VID:PID:Flags where VID and PID are Vendor
> + and Product ID values (4-digit hex numbers) and
> + Flags is a set of characters, each corresponding
> + to a common usb core quirk flag as follows:
> + a = USB_QUIRK_STRING_FETCH_255 (string
> + descriptors must not be fetched using
> + a 255-byte read);
> + b = USB_QUIRK_RESET_RESUME (device can't resume
> + correctly so reset it instead);
> + c = USB_QUIRK_NO_SET_INTF (device can't handle
> + Set-Interface requests);
> + d = USB_QUIRK_CONFIG_INTF_STRINGS (device can't
> + handle its Configuration or Interface
> + strings);
> + e = USB_QUIRK_RESET (device can't be reset
> + (e.g morph devices), don't use reset);
> + f = USB_QUIRK_HONOR_BNUMINTERFACES (device has
> + more interface descriptions than the
> + bNumInterfaces count, and can't handle
> + talking to these interfaces);
> + g = USB_QUIRK_DELAY_INIT (device needs a pause
> + during initialization, after we read
> + the device descriptor);
> + h = USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL (For
> + high speed and super speed interrupt
> + endpoints, the USB 2.0 and USB 3.0 spec
> + require the interval in microframes (1
> + microframe = 125 microseconds) to be
> + calculated as interval = 2 ^
> + (bInterval-1).
> + Devices with this quirk report their
> + bInterval as the result of this
> + calculation instead of the exponent
> + variable used in the calculation);
> + i = USB_QUIRK_DEVICE_QUALIFIER (device can't
> + handle device_qualifier descriptor
> + requests);
> + j = USB_QUIRK_IGNORE_REMOTE_WAKEUP (device
> + generates spurious wakeup, ignore
> + remote wakeup capability);
> + k = USB_QUIRK_NO_LPM (device can't handle Link
> + Power Management);
> + l = USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL
> + (Device reports its bInterval as linear
> + frames instead of the USB 2.0
> + calculation);
> + m = USB_QUIRK_DISCONNECT_SUSPEND (Device needs
> + to be disconnected before suspend to
>