Re: [PATCHv2 4/7] Documentation: dt: socfpga: Add Arria10 Ethernet binding

2016-04-27 Thread Rob Herring 
On Mon, Apr 25, 2016 at 12:52:45PM -0500, ttha...@opensource.altera.com wrote:
> From: Thor Thayer 
> 
> Add the device tree bindings needed to support the Altera Ethernet
> FIFO buffers on the Arria10 chip.
> 
> Signed-off-by: Thor Thayer 
> ---
> v2  No Change
> ---
>  .../bindings/arm/altera/socfpga-eccmgr.txt |   24 
> 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt 
> b/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
> index 5a6b160..aa1c593 100644
> --- a/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
> +++ b/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
> @@ -76,6 +76,18 @@ Required Properties:
>  - compatible : Should be "altr,socfpga-a10-ocram-ecc"
>  - reg: Address and size for ECC block registers.
>  
> +Ethernet FIFO ECC
> +Required Properties:
> +- compatible : Should be "altr,socfpga-a10-emac0-rx-ecc" for the 1st EMAC
> + Receive buffer
> + or "altr,socfpga-a10-emac0-tx-ecc" for the 1st EMAC Transmit buffer
> + or "altr,socfpga-a10-emac1-rx-ecc" for the 2nd EMAC Receive buffer
> + or "altr,socfpga-a10-emac1-tx-ecc" for the 2nd EMAC Transmit buffer
> + or "altr,socfpga-a10-emac2-rx-ecc" for the 3rd EMAC Receive buffer
> + or "altr,socfpga-a10-emac2-tx-ecc" for the 3rd EMAC Transmit buffer

These blocks don't really appear to be different other than the 
interrupt mask (which is in another block?). I think they should be the 
same compatible with a property for the interrupt (perhaps a full 
interrupt-controller binding). 

> +- reg: Address and size for ECC block registers.
> +- parent : phandle to parent Ethernet node.

Needs a better name and altr prefix. Maybe altr,eth-mac?

Rob
--
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: [RFC6 PATCH v6 00/21] ILP32 for ARM64 - LTP results

2016-04-27 Thread Andrew Pinski 
On Wed, Apr 27, 2016 at 12:30 AM, Andrew Pinski  wrote:
> On Fri, Apr 22, 2016 at 8:37 PM, Zhangjian (Bamvor)
>  wrote:
>> Hi, Yury
>>
>>
>> On 2016/4/6 6:44, Yury Norov wrote:
>>>
>>> There are about 20 failing tests of 782 in lite scenario.
>>> float_bessel
>>> float_exp_log
>>> float_iperb
>>> float_power
>>> float_trigo
>>> pipeio_1
>>> pipeio_3
>>> pipeio_5
>>> pipeio_8
>>> abort01
>>> clone02
>>> kill11
>>> mmap16
>>> open12
>>> pause01
>>> rename11
>>> rmdir02
>>> umount2_01
>>> umount2_02
>>> umount2_03
>>> utime06
>>> mtest06
>>>
>>> The list is rough because some tests fail not every time.
>>>
>>> Tests abort01 and kill11 fail for lp64 too, so maybe there's
>>> a reason unrelated to ilp32 itself.
>>>
>>> float_xxx tests fail because they call unwind() from signal context,
>>> and GCC for ilp32 has problem with it, as Andrew told.
>>
>> Is there some progress about this issue. When we talk about unwind
>> functions, do you mean the function in libgcc?
>>
>> We encountered another issue(abort not segfault) which also called
>> pthread_cancel(). The test code is in the attachment. Here is the
>> backtrace:
>
> Yes this was a known issue I knew about.  I have a patch GCC to fix
> this.  Basically REG_VALUE_IN_UNWIND_CONTEXT needs to be defined while
> building libgcc to support the correct unwind information.
> I will be posting a GCC patch to fix this tomorrow.  This was a bug
> even in the original set of ilp32 patches.  I only finally was able to
> sit down and fix it today.

Here is the link to the GCC patch which I said was going to submit today:
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01726.html

Thanks,
Andrew

>
>
> Thanks,
> Andrew
>
>>
>> ```
>> Program received signal SIGABRT, Aborted.
>> [Switching to Thread 0xf77ee330 (LWP 2958)]
>> 0x0040f5bc in raise (sig=sig@entry=6)
>> at ../sysdeps/unix/sysv/linux/raise.c:55
>> 55  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>> (gdb) bt
>> #0  0x0040f5bc in raise (sig=sig@entry=6)
>> at ../sysdeps/unix/sysv/linux/raise.c:55
>> #1  0x0040f884 in abort () at abort.c:89
>>
>> #2  0x004073b4 in uw_update_context_1 (
>> context=context@entry=0xf77ec820, fs=fs@entry=0xf77ebec8)
>> at /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind-dw2.c:1430
>>
>> #3  0x004078c0 in uw_update_context
>> (context=context@entry=0xf77ec820,
>> fs=fs@entry=0xf77ebec8)
>>at
>> /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind-dw2.c:1506
>> #4  0x00407a9c in uw_advance_context (fs=0xf77ebec8,
>> context=0xf77ec820)
>> at
>> /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind-dw2.c:1529
>> #5  _Unwind_ForcedUnwind_Phase2 (exc=exc@entry=0xf77ee580,
>> context=context@entry=0xf77ec820)
>> at /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind.inc:185
>> #6  0x00408228 in _Unwind_ForcedUnwind (exc=0xf77ee580,
>> stop=stop@entry=0x405440 , stop_argument=0xf77eddd8)
>> at /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind.inc:207
>> #7  0x004055c4 in __pthread_unwind (buf=)
>> at unwind.c:126
>> #8  0x004050b4 in __do_cancel () at ./pthreadP.h:283
>> #9  sigcancel_handler (sig=, si=,
>> ctx=) at nptl-init.c:225
>> ---Type  to continue, or q  to quit---
>> #10 
>>
>> #11 0x in ?? ()
>>
>> #12 0x00423084 in __select (nfds=-1, readfds=,
>> writefds=, exceptfds=, timeout=0x0)
>> at ../sysdeps/unix/sysv/linux/generic/select.c:45
>> #13 0x00400604 in TEST_TaskDelay (
>> uiMillSecs=)
>> at test-cancel.c:18
>> #14 0x00400680 in printids (
>> s=)
>> at test-cancel.c:38
>> #15 0x004006d0 in thr_fn (
>> arg=)
>> at test-cancel.c:49
>> #16 0x00401b28 in start_thread (arg=0x4a3000) at
>> pthread_create.c:335
>> #17 0x00401b28 in start_thread (arg=0x4a3000) at
>> pthread_create.c:335
>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>> ```
>>
>> Such abort is raise by the following code:
>> ```
>> static void
>> uw_update_context_1 (struct _Unwind_Context *context, _Unwind_FrameState
>> *fs)
>> {
>> //...
>>   /* Compute this frame's CFA.  */
>>   switch (fs->regs.cfa_how)
>> {
>> case CFA_REG_OFFSET:
>>   cfa = _Unwind_GetPtr (_context, fs->regs.cfa_reg);
>>   cfa += fs->regs.cfa_offset;
>>   break;
>>
>> case CFA_EXP:
>>   {
>> const unsigned char *exp = fs->regs.cfa_exp;
>> _uleb128_t len;
>>
>> exp = read_uleb128 (exp, );
>> cfa = (void *) (_Unwind_Ptr)
>>   execute_stack_op (exp, exp + len, _context, 0);
>> break;
>>   }
>>
>> default:
>>   gcc_unreachable ();
>> }
>>   context->cfa = cfa;
>> //...
>> }
>> ``
>>
>> Any suggestion is appreciated.
>>
>> CC gcc mailing list. Sorry if it is off topic.
>>
>> Regards
>>
>> Bamvor

Re: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)

2016-04-27 Thread Tom Lendacky 
On 04/27/2016 09:39 AM, Andy Lutomirski wrote:
> On Tue, Apr 26, 2016 at 3:55 PM, Tom Lendacky  wrote:
>> This RFC patch series provides support for AMD's new Secure Memory
>> Encryption (SME) feature.
>>
>> SME can be used to mark individual pages of memory as encrypted through the
>> page tables. A page of memory that is marked encrypted will be automatically
>> decrypted when read from DRAM and will be automatically encrypted when
>> written to DRAM. Details on SME can found in the links below.
> 
> Having read through the docs briefly, some questions:
> 
> 1. How does the crypto work?  Is it straight AES-ECB?  Is it a
> tweakable mode?  If so, what does into the tweak?  For example, if I
> swap the ciphertext of two pages, does the plaintext of the pages get
> swapped?  If not, why not?

The AES crypto uses a tweak such that two identical plaintexts at
different locations will have different ciphertext. So swapping the
ciphertext of two pages will not result in the plaintext being swapped.

> 
> 2. In SEV mode, how does the hypervisor relocate a physical backing
> page?  Does it simple move it and update the 2nd-level page tables?
> If so, is the result of decryption guaranteed to be garbage if it
> relocates a page and re-inserts it at the wrong guest physical
> address?

For SEV mode, relocating a physical backing page takes extra steps.
There are APIs that are used to have the AMD Secure Processor create a
transportable encrypted page that can then be moved to a new location
in memory. After moving it to the new location the APIs are used to
haves the AMD Secure Processor re-encrypt the page for use with the
guests SEV key. Based on #1 above, just moving a page without invoking
the necessary APIs will result in the decryption returning garbage.

> 
> 3. In SEV mode, does anything prevent the hypervisor from resuming a
> guest with the wrong ASID, or is this all relying on the resulting
> corruption of the guest code and data to cause a crash?

There is nothing that prevents resuming a guest with the wrong ASID.
This relies on the resulting corruption of the guest code/data to
cause a crash.

> 
> 4. As I understand it, the caches are all unencrypted, and they're
> tagged with the physical address, *including* the SME bit (bit 47).
> In SEV mode, are they also tagged with the ASID?  I.e. if I have a
> page in cache for ASID 1 and I try to read it with ASID 2, will I get
> a fresh copy decrypted with ASID 2's key?  If so, will the old ASID 1
> copy be evicted, or will it stay in cache and be non-coherent?

In SEV mode, the caches are tagged with the ASID. So if you try to read
a cached page with a different ASID, it would result in a cache miss
for that ASID and will instead fetch from memory and decrypt using
the that ASID's key.

Thanks,
Tom

> 
> --Andy
> 
--
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: [RFC PATCH v1 02/18] x86: Secure Memory Encryption (SME) build enablement

2016-04-27 Thread Pavel Machek 
On Wed 2016-04-27 17:41:40, Borislav Petkov wrote:
> On Wed, Apr 27, 2016 at 05:30:10PM +0200, Pavel Machek wrote:
> > Doing it early will break bisect, right?
> 
> How exactly? Please do tell.

Hey look, SME slowed down 30% since being initially merged into
kernel!
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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: [RFC PATCH v1 03/18] x86: Secure Memory Encryption (SME) support

2016-04-27 Thread Tom Lendacky 
On 03/22/2016 08:03 AM, Pavel Machek wrote:
> On Tue 2016-04-26 17:56:26, Tom Lendacky wrote:
>> Provide support for Secure Memory Encryption (SME). This initial support
>> defines the memory encryption mask as a variable for quick access and an
>> accessor for retrieving the number of physical addressing bits lost if
>> SME is enabled.
>>
>> Signed-off-by: Tom Lendacky 
>> ---
>>  arch/x86/include/asm/mem_encrypt.h |   37 
>> 
>>  arch/x86/kernel/Makefile   |2 ++
>>  arch/x86/kernel/mem_encrypt.S  |   29 
>>  arch/x86/kernel/x8664_ksyms_64.c   |6 ++
>>  4 files changed, 74 insertions(+)
>>  create mode 100644 arch/x86/include/asm/mem_encrypt.h
>>  create mode 100644 arch/x86/kernel/mem_encrypt.S
>>
>> index 000..ef7f325
>> --- /dev/null
>> +++ b/arch/x86/kernel/mem_encrypt.S
>> @@ -0,0 +1,29 @@
>> +/*
>> + * AMD Memory Encryption Support
>> + *
>> + * Copyright (C) 2016 Advanced Micro Devices, Inc.
>> + *
>> + * Author: Tom Lendacky 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include 
>> +
>> +.text
>> +.code64
>> +ENTRY(sme_get_me_loss)
>> +xor %rax, %rax
>> +mov sme_me_loss(%rip), %al
>> +ret
>> +ENDPROC(sme_get_me_loss)
> 
> Does this really need to be implemented in assembly?

That particular routine probably doesn't need to be in assembly. But
since it was such a simple routine I put it there because a later
patch derives the value in this file.

Thanks,
Tom

> 
> 
--
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] scripts/spelling.txt: add "fimware" misspelling

2016-04-27 Thread Kees Cook 
On Tue, Apr 26, 2016 at 9:06 PM, Zhao Lei  wrote:
> Hi, Kees Cook
>
> * From: Kees Cook [mailto:keesc...@chromium.org]
>> Sent: Wednesday, April 27, 2016 7:48 AM
>> To: Andrew Morton 
>> Cc: Randy Dunlap ; Andy Whitcroft
>> ; Joe Perches ; Zhao Lei
>> ; linux-doc@vger.kernel.org;
>> linux-ker...@vger.kernel.org
>> Subject: [PATCH] scripts/spelling.txt: add "fimware" misspelling
>>
>> A few instances of "fimware" instead of "firmware" were found. Fix these
>> and add it to the spelling.txt file.
>>
> Better to add this change:
>   # grep fimware * -R
>   Documentation/firmware_class/README:- kernel searchs the fimware image 
> with name
$FIRMWARE directly

Yup! That's actually going in via another batch of spelling fixes
(Randy noticing this one is what made me check for more).

Thanks!

-Kees

>
> Thanks
> Zhaolei
>
>> Reported-by: Randy Dunlap 
>> Signed-off-by: Kees Cook 
>> ---
>> Looks like spelling.txt changes have been going in through -mm?
>> ---
>>  drivers/media/usb/dvb-usb/dib0700_core.c  | 2 +-
>>  drivers/scsi/bfa/bfi.h| 2 +-
>>  drivers/staging/comedi/drivers/daqboard2000.c | 2 +-
>>  scripts/spelling.txt  | 1 +
>>  4 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c
>> b/drivers/media/usb/dvb-usb/dib0700_core.c
>> index c16f999b9d7c..bf890c3d9cda 100644
>> --- a/drivers/media/usb/dvb-usb/dib0700_core.c
>> +++ b/drivers/media/usb/dvb-usb/dib0700_core.c
>> @@ -517,7 +517,7 @@ int dib0700_download_firmware(struct usb_device
>> *udev, const struct firmware *fw
>>   if (nb_packet_buffer_size < 1)
>>   nb_packet_buffer_size = 1;
>>
>> - /* get the fimware version */
>> + /* get the firmware version */
>>   usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
>> REQUEST_GET_VERSION,
>> USB_TYPE_VENDOR | USB_DIR_IN, 0, 0,
>> diff --git a/drivers/scsi/bfa/bfi.h b/drivers/scsi/bfa/bfi.h
>> index 97600dcec649..5f698d038b21 100644
>> --- a/drivers/scsi/bfa/bfi.h
>> +++ b/drivers/scsi/bfa/bfi.h
>> @@ -356,7 +356,7 @@ struct bfi_ioc_image_hdr_s {
>>   u8  port0_mode; /* device mode for port 0   */
>>   u8  port1_mode; /* device mode for port 1   */
>>   u32 exec;   /* exec vector  */
>> - u32 bootenv;/* fimware boot env */
>> + u32 bootenv;/* firmware boot env*/
>>   u32 rsvd_b[2];
>>   struct bfi_ioc_fwver_s  fwver;
>>   u32 md5sum[BFI_IOC_MD5SUM_SZ];
>> diff --git a/drivers/staging/comedi/drivers/daqboard2000.c
>> b/drivers/staging/comedi/drivers/daqboard2000.c
>> index 57ab6680e3ae..a536a15c1d30 100644
>> --- a/drivers/staging/comedi/drivers/daqboard2000.c
>> +++ b/drivers/staging/comedi/drivers/daqboard2000.c
>> @@ -26,7 +26,7 @@
>>   * Much of the functionality of this driver was determined from reading
>>   * the source code for the Windows driver.
>>   *
>> - * The FPGA on the board requires fimware, which is available from
>> + * The FPGA on the board requires firmware, which is available from
>>   * http://www.comedi.org in the comedi_nonfree_firmware tarball.
>>   *
>>   * Configuration options: not applicable, uses PCI auto config
>> diff --git a/scripts/spelling.txt b/scripts/spelling.txt
>> index 946caf3bd694..fa79c6d2a5b8 100644
>> --- a/scripts/spelling.txt
>> +++ b/scripts/spelling.txt
>> @@ -428,6 +428,7 @@ feautures||features
>>  fetaure||feature
>>  fetaures||features
>>  fileystem||filesystem
>> +fimware||firmware
>>  finanize||finalize
>>  findn||find
>>  finilizes||finalizes
>> --
>> 2.6.3
>>
>>
>> --
>> Kees Cook
>> Chrome OS & Brillo Security
>
>
>
>



-- 
Kees Cook
Chrome OS & Brillo 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: [RFC PATCH v1 02/18] x86: Secure Memory Encryption (SME) build enablement

2016-04-27 Thread Borislav Petkov 
On Wed, Apr 27, 2016 at 05:30:10PM +0200, Pavel Machek wrote:
> Doing it early will break bisect, right?

How exactly? Please do tell.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
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: [RFC PATCH v1 01/18] x86: Set the write-protect cache mode for AMD processors

2016-04-27 Thread Borislav Petkov 
On Wed, Apr 27, 2016 at 08:12:56AM -0700, Andy Lutomirski wrote:
> I think there are some errata

Isn't that addressed by the first branch of the if-test in pat_init():

if ((c->x86_vendor == X86_VENDOR_INTEL) &&
(((c->x86 == 0x6) && (c->x86_model <= 0xd)) ||
 ((c->x86 == 0xf) && (c->x86_model <= 0x6 {


-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
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: [RFC PATCH v1 02/18] x86: Secure Memory Encryption (SME) build enablement

2016-04-27 Thread Tom Lendacky 
On 03/22/2016 08:01 AM, Pavel Machek wrote:
> On Tue 2016-04-26 17:56:14, Tom Lendacky wrote:
>> Provide the Kconfig support to build the SME support in the kernel.
> 
> 
> Probably should go last in the series?

Yeah, I've seen arguments both ways for this. Doing it early
allows compiling and testing with it enabled and doing it late
doesn't enable anything until it's all there. I just chose the
former.

Thanks,
Tom

> 
>> Signed-off-by: Tom Lendacky 
>> ---
>>  arch/x86/Kconfig |9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 7bb1574..13249b5 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -1356,6 +1356,15 @@ config X86_DIRECT_GBPAGES
>>supports them), so don't confuse the user by printing
>>that we have them enabled.
>>  
>> +config AMD_MEM_ENCRYPT
>> +bool "Secure Memory Encryption support for AMD"
>> +depends on X86_64 && CPU_SUP_AMD
>> +---help---
>> +  Say yes to enable the encryption of system memory. This requires
>> +  an AMD processor that supports Secure Memory Encryption (SME).
>> +  The encryption of system memory is disabled by default but can be
>> +  enabled with the mem_encrypt=on command line option.
>> +
>>  # Common NUMA Features
>>  config NUMA
>>  bool "Numa Memory Allocation and Scheduler Support"
> 
--
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: [RFC PATCH v1 01/18] x86: Set the write-protect cache mode for AMD processors

2016-04-27 Thread Andy Lutomirski 
On Wed, Apr 27, 2016 at 8:05 AM, Tom Lendacky  wrote:
> On 04/27/2016 09:47 AM, Andy Lutomirski wrote:
>> On Wed, Apr 27, 2016 at 7:44 AM, Tom Lendacky  
>> wrote:
>>> On 04/27/2016 09:33 AM, Andy Lutomirski wrote:
 On Tue, Apr 26, 2016 at 3:56 PM, Tom Lendacky  
 wrote:
> For AMD processors that support PAT, set the write-protect cache mode
> (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05).

 What's the purpose of using the WP memory type?
>>>
>>> The WP memory type is used for encrypting or decrypting data "in place".
>>> The use of the WP on the source data will prevent any of the source
>>> data from being cached.  Refer to section 7.10.8 "Encrypt-in-Place" in
>>> the AMD64 APM link provided in the cover letter.
>>>
>>> This memory type will be used in subsequent patches for this purpose.
>>
>> OK.
>>
>> Why AMD-only?  I thought Intel supported WP, too.
>
> Just me being conservative. If there aren't any objections from the
> Intel folks about it we can remove the vendor check and just set it.

I think there are some errata that will cause high PAT references to
incorrectly reference the low parts of the table, but I don't recall
any that go the other way around.  So merely setting WP in a high
entry should be harmless unless something tries to use it.

>
> Thanks,
> Tom
>
>>
>> --Andy
>>



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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: [RFC PATCH v1 01/18] x86: Set the write-protect cache mode for AMD processors

2016-04-27 Thread Tom Lendacky 
On 04/27/2016 09:47 AM, Andy Lutomirski wrote:
> On Wed, Apr 27, 2016 at 7:44 AM, Tom Lendacky  wrote:
>> On 04/27/2016 09:33 AM, Andy Lutomirski wrote:
>>> On Tue, Apr 26, 2016 at 3:56 PM, Tom Lendacky  
>>> wrote:
 For AMD processors that support PAT, set the write-protect cache mode
 (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05).
>>>
>>> What's the purpose of using the WP memory type?
>>
>> The WP memory type is used for encrypting or decrypting data "in place".
>> The use of the WP on the source data will prevent any of the source
>> data from being cached.  Refer to section 7.10.8 "Encrypt-in-Place" in
>> the AMD64 APM link provided in the cover letter.
>>
>> This memory type will be used in subsequent patches for this purpose.
> 
> OK.
> 
> Why AMD-only?  I thought Intel supported WP, too.

Just me being conservative. If there aren't any objections from the
Intel folks about it we can remove the vendor check and just set it.

Thanks,
Tom

> 
> --Andy
> 
--
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: [RFC PATCH v1 01/18] x86: Set the write-protect cache mode for AMD processors

2016-04-27 Thread Andy Lutomirski 
On Wed, Apr 27, 2016 at 7:44 AM, Tom Lendacky  wrote:
> On 04/27/2016 09:33 AM, Andy Lutomirski wrote:
>> On Tue, Apr 26, 2016 at 3:56 PM, Tom Lendacky  
>> wrote:
>>> For AMD processors that support PAT, set the write-protect cache mode
>>> (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05).
>>
>> What's the purpose of using the WP memory type?
>
> The WP memory type is used for encrypting or decrypting data "in place".
> The use of the WP on the source data will prevent any of the source
> data from being cached.  Refer to section 7.10.8 "Encrypt-in-Place" in
> the AMD64 APM link provided in the cover letter.
>
> This memory type will be used in subsequent patches for this purpose.

OK.

Why AMD-only?  I thought Intel supported WP, too.

--Andy
--
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: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)

2016-04-27 Thread Pavel Machek 
On Wed 2016-04-27 16:05:20, Borislav Petkov wrote:
> On Tue, Mar 22, 2016 at 02:00:58PM +0100, Pavel Machek wrote:
> > Why would I want SME on my system? My system seems to work without it.
> 
> Your system doesn't have it and SME is default off.

That does not answer the question. "Why would I want SME on my
system?".

And that answer should go to Documentation/.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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: [RFC PATCH v1 01/18] x86: Set the write-protect cache mode for AMD processors

2016-04-27 Thread Tom Lendacky 
On 04/27/2016 09:33 AM, Andy Lutomirski wrote:
> On Tue, Apr 26, 2016 at 3:56 PM, Tom Lendacky  wrote:
>> For AMD processors that support PAT, set the write-protect cache mode
>> (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05).
> 
> What's the purpose of using the WP memory type?

The WP memory type is used for encrypting or decrypting data "in place".
The use of the WP on the source data will prevent any of the source
data from being cached.  Refer to section 7.10.8 "Encrypt-in-Place" in
the AMD64 APM link provided in the cover letter.

This memory type will be used in subsequent patches for this purpose.

Thanks,
Tom

> 
> --Andy
> 
--
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: Kernel docs: muddying the waters a bit

2016-04-27 Thread Grant Likely 
On Tue, Apr 12, 2016 at 4:46 PM, Jonathan Corbet  wrote:
> On Fri, 8 Apr 2016 17:12:27 +0200
> Markus Heiser  wrote:
>
>> motivated by this MT, I implemented a toolchain to migrate the kernel’s
>> DocBook XML documentation to reST markup.
>>
>> It converts 99% of the docs well ... to gain an impression how
>> kernel-docs could benefit from, visit my sphkerneldoc project page
>> on github:
>>
>>   http://return42.github.io/sphkerneldoc/
>
> So I've obviously been pretty quiet on this recently.  Apologies...I've
> been dealing with an extended death-in-the-family experience, and there is
> still a fair amount of cleanup to be done.
>
> Looking quickly at this work, it seems similar to the results I got.  But
> there's a lot of code there that came from somewhere?  I'd put together a
> fairly simple conversion using pandoc and a couple of short sed scripts;
> is there a reason for a more complex solution?
>
> Thanks for looking into this, anyway; I hope to be able to focus more on
> it shortly.

Hi Jon,

Thanks for digging into this. FWIW, here is my $0.02. I've been
working on restarting the devicetree specification, and after looking
at both reStructuredText and Asciidoc(tor) I thought I liked the
Asciidoc markup better, so chose that. I then proceeded to spend weeks
trying to get reasonable output from the toolchain. When I got fed up
and gave Sphinx a try, I was up and running with reasonable PDF and
HTML output in a day and a half.

Honestly, in the end I think we could make either tool do what is
needed of it. However, my impression after trying to do a document
that needs to have nice publishable output with both tools is that
Sphinx is easier to work with, simpler to extend, better supported. My
vote is firmly behind Sphinx/reStructuredText.

g.
--
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: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)

2016-04-27 Thread Tom Lendacky 
On 03/22/2016 08:00 AM, Pavel Machek wrote:
> Hi!
> 
>> This RFC patch series provides support for AMD's new Secure Memory
>> Encryption (SME) feature.
>>
>> SME can be used to mark individual pages of memory as encrypted through the
>> page tables. A page of memory that is marked encrypted will be automatically
>> decrypted when read from DRAM and will be automatically encrypted when
>> written to DRAM. Details on SME can found in the links below.
> 
> Well, actually brief summary should go to changelog and probably to the 
> documentation,
> too...
> 
> Why would I want SME on my system? My system seems to work without it.

The whitepaper explains the technologies and the value they provide.
It's up to you to decide if you'd want to use it.

> 
> Does it protect against cold boot attacks? Rowhammer (I guess not?)

It does protect well against cold boot attacks. It might offer some
protection against Rowhammer since if a bit got flipped the entire
16B chunk would be decrypted differently.

> 
> Does it cost some performance?

The whitepaper talks about this a little, but it has a minimal impact
on system performance when accessing an encrypted page.

> 
> Does it break debugging over JTAG?
> 
>> The approach that this patch series takes is to encrypt everything possible
>> starting early in the boot where the kernel is encrypted. Using the page
>> table macros the encryption mask can be incorporated into all page table
>> entries and page allocations. By updating the protection map, userspace
>> allocations are also marked encrypted. Certain data must be accounted for
>> as having been placed in memory before SME was enabled (EFI, initrd, etc.)
>> and accessed accordingly.
> 
> Do you also need to do something special for device DMA?

DMA should function normally unless the device does not support the
addressing requirements when SME is active. When the encryption mask is
applied (bit 47 of the physical address in this case), if the device
doesn't support 48 bit or higher DMA then swiotlb bounce buffers will
be used.

Thanks,
Tom

> 
> Thanks,
> 
>   Pavel
> 
--
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 0/6] Intel Secure Guard Extensions

2016-04-27 Thread Andy Lutomirski 
On Apr 27, 2016 1:18 AM, "Ingo Molnar"  wrote:
>
>
> * Andy Lutomirski  wrote:
>
> > > What new syscalls would be needed for ssh to get all this support?
> >
> > This patchset or similar, plus some user code and an enclave to use.
> >
> > Sadly, on current CPUs, you also need Intel to bless the enclave.  It looks 
> > like
> > new CPUs might relax that requirement.
>
> That looks like a fundamental technical limitation in my book - to an open 
> source
> user this is essentially a very similar capability as tboot: it only allows 
> the
> execution of externally blessed static binary blobs...
>
> I don't think we can merge any of this upstream until it's clear that the 
> hardware
> owner running open-source user-space can also freely define/start his own 
> secure
> enclaves without having to sign the enclave with any external party. I.e.
> self-signed enclaves should be fundamentally supported as well.

Certainly, if this were a *graphics* driver, airlied would refuse to
merge it without open source userspace available.

We're all used to Intel sending patches that no one outside Intel can
test without because no one has the hardware.  Heck, I recently sent a
vdso patch that *I* can't test.  But in this case I have the hardware
and there is no way that I can test it, and I don't like this at all.

See my earlier comments about not allowing user code to provide
EINITTOKEN.  Implementing that would mostly solve this problem, with
the big caveat that it may be impossible to implement that suggestion
until Intel changes its stance (which is clearly in progress, given
the recent SDM updates).

This could easily end up bring a CNL-only feature in Linux.  (Or
whatever generation that change is in.)

--Andy
--
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: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)

2016-04-27 Thread Borislav Petkov 
On Tue, Mar 22, 2016 at 02:00:58PM +0100, Pavel Machek wrote:
> Why would I want SME on my system? My system seems to work without it.

Your system doesn't have it and SME is default off.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
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: [RFC PATCH v1 03/18] x86: Secure Memory Encryption (SME) support

2016-04-27 Thread Pavel Machek 
On Tue 2016-04-26 17:56:26, Tom Lendacky wrote:
> Provide support for Secure Memory Encryption (SME). This initial support
> defines the memory encryption mask as a variable for quick access and an
> accessor for retrieving the number of physical addressing bits lost if
> SME is enabled.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/mem_encrypt.h |   37 
> 
>  arch/x86/kernel/Makefile   |2 ++
>  arch/x86/kernel/mem_encrypt.S  |   29 
>  arch/x86/kernel/x8664_ksyms_64.c   |6 ++
>  4 files changed, 74 insertions(+)
>  create mode 100644 arch/x86/include/asm/mem_encrypt.h
>  create mode 100644 arch/x86/kernel/mem_encrypt.S
> 
> index 000..ef7f325
> --- /dev/null
> +++ b/arch/x86/kernel/mem_encrypt.S
> @@ -0,0 +1,29 @@
> +/*
> + * AMD Memory Encryption Support
> + *
> + * Copyright (C) 2016 Advanced Micro Devices, Inc.
> + *
> + * Author: Tom Lendacky 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +
> + .text
> + .code64
> +ENTRY(sme_get_me_loss)
> + xor %rax, %rax
> + mov sme_me_loss(%rip), %al
> + ret
> +ENDPROC(sme_get_me_loss)

Does this really need to be implemented in assembly?


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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: [RFC PATCH v1 02/18] x86: Secure Memory Encryption (SME) build enablement

2016-04-27 Thread Pavel Machek 
On Tue 2016-04-26 17:56:14, Tom Lendacky wrote:
> Provide the Kconfig support to build the SME support in the kernel.


Probably should go last in the series?

> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/Kconfig |9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 7bb1574..13249b5 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1356,6 +1356,15 @@ config X86_DIRECT_GBPAGES
> supports them), so don't confuse the user by printing
> that we have them enabled.
>  
> +config AMD_MEM_ENCRYPT
> + bool "Secure Memory Encryption support for AMD"
> + depends on X86_64 && CPU_SUP_AMD
> + ---help---
> +   Say yes to enable the encryption of system memory. This requires
> +   an AMD processor that supports Secure Memory Encryption (SME).
> +   The encryption of system memory is disabled by default but can be
> +   enabled with the mem_encrypt=on command line option.
> +
>  # Common NUMA Features
>  config NUMA
>   bool "Numa Memory Allocation and Scheduler Support"

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)

2016-04-27 Thread Pavel Machek 
Hi!

> This RFC patch series provides support for AMD's new Secure Memory
> Encryption (SME) feature.
> 
> SME can be used to mark individual pages of memory as encrypted through the
> page tables. A page of memory that is marked encrypted will be automatically
> decrypted when read from DRAM and will be automatically encrypted when
> written to DRAM. Details on SME can found in the links below.

Well, actually brief summary should go to changelog and probably to the 
documentation,
too...

Why would I want SME on my system? My system seems to work without it.

Does it protect against cold boot attacks? Rowhammer (I guess not?)

Does it cost some performance?

Does it break debugging over JTAG?

> The approach that this patch series takes is to encrypt everything possible
> starting early in the boot where the kernel is encrypted. Using the page
> table macros the encryption mask can be incorporated into all page table
> entries and page allocations. By updating the protection map, userspace
> allocations are also marked encrypted. Certain data must be accounted for
> as having been placed in memory before SME was enabled (EFI, initrd, etc.)
> and accessed accordingly.

Do you also need to do something special for device DMA?

Thanks,

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

2016-04-27 Thread Yongji Xie 
Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio
page may be shared with other BARs. This will cause some
performance issues when we passthrough a PCI device with
this kind of BARs. Guest will be not able to handle the mmio
accesses to the BARs which leads to mmio emulations in host.

However, not all sub-page BARs will share page with other BARs.
We should allow to mmap those sub-page MMIO BARs which we can
make sure will not share page with other BARs.

This patch adds support for this case. And we also try to use 
shadow resource to reserve the remaind of the page which hot-add 
device's BAR might be assigned into.

Signed-off-by: Yongji Xie 
---
 drivers/vfio/pci/vfio_pci.c |   58 ++-
 drivers/vfio/pci/vfio_pci_private.h |8 +
 2 files changed, 59 insertions(+), 7 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 98059df..dc1779c 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -110,13 +110,47 @@ static inline bool vfio_pci_is_vga(struct pci_dev *pdev)
return (pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA;
 }
 
+static bool vfio_pci_bar_mmap_supported(struct vfio_pci_device *vdev, int 
index)
+{
+   struct resource *res = vdev->pdev->resource + index;
+   struct vfio_pci_shadow_resource *shadow_res;
+
+   if (IS_ENABLED(CONFIG_VFIO_PCI_MMAP) && res->flags & IORESOURCE_MEM &&
+   resource_size(res) > 0) {
+   if (resource_size(res) >= PAGE_SIZE)
+   return true;
+
+   if (!(res->start & ~PAGE_MASK)) {
+   /*
+* Add shadow resource for sub-page bar whose mmio
+* page is exclusive in case that hot-add device's
+* bar is assigned into the mem hole.
+*/
+   shadow_res = kzalloc(sizeof(*shadow_res), GFP_KERNEL);
+   shadow_res->resource.start = res->end + 1;
+   shadow_res->resource.end = res->start + PAGE_SIZE - 1;
+   shadow_res->resource.flags = res->flags;
+   if (request_resource(res->parent,
+   _res->resource)) {
+   kfree(shadow_res);
+   return false;
+   }
+   shadow_res->index = index;
+   list_add(_res->res_next,
+   >shadow_resources_list);
+   return true;
+   }
+   }
+   return false;
+}
+
 static void vfio_pci_try_bus_reset(struct vfio_pci_device *vdev);
 static void vfio_pci_disable(struct vfio_pci_device *vdev);
 
 static int vfio_pci_enable(struct vfio_pci_device *vdev)
 {
struct pci_dev *pdev = vdev->pdev;
-   int ret;
+   int ret, bar;
u16 cmd;
u8 msix_pos;
 
@@ -183,12 +217,17 @@ static int vfio_pci_enable(struct vfio_pci_device *vdev)
}
}
 
+   for (bar = PCI_STD_RESOURCES; bar <= PCI_STD_RESOURCE_END; bar++) {
+   vdev->bar_mmap_supported[bar] =
+   vfio_pci_bar_mmap_supported(vdev, bar);
+   }
return 0;
 }
 
 static void vfio_pci_disable(struct vfio_pci_device *vdev)
 {
struct pci_dev *pdev = vdev->pdev;
+   struct vfio_pci_shadow_resource *shadow_res, *tmp;
int i, bar;
 
/* Stop the device from further DMA */
@@ -217,6 +256,13 @@ static void vfio_pci_disable(struct vfio_pci_device *vdev)
vdev->barmap[bar] = NULL;
}
 
+   list_for_each_entry_safe(shadow_res, tmp,
+>shadow_resources_list, res_next) {
+   list_del(_res->res_next);
+   release_resource(_res->resource);
+   kfree(shadow_res);
+   }
+
vdev->needs_reset = true;
 
/*
@@ -587,9 +633,7 @@ static long vfio_pci_ioctl(void *device_data,
 
info.flags = VFIO_REGION_INFO_FLAG_READ |
 VFIO_REGION_INFO_FLAG_WRITE;
-   if (IS_ENABLED(CONFIG_VFIO_PCI_MMAP) &&
-   pci_resource_flags(pdev, info.index) &
-   IORESOURCE_MEM && info.size >= PAGE_SIZE) {
+   if (vdev->bar_mmap_supported[info.index]) {
info.flags |= VFIO_REGION_INFO_FLAG_MMAP;
if (info.index == vdev->msix_bar) {
ret = msix_sparse_mmap_cap(vdev, );
@@ -1011,16 +1055,16 @@ static int vfio_pci_mmap(void *device_data, struct 
vm_area_struct *vma)
return -EINVAL;
if (index >= VFIO_PCI_ROM_REGION_INDEX)
return -EINVAL;
-   if

Re: [PATCH 0/6] Intel Secure Guard Extensions

2016-04-27 Thread Ingo Molnar 

* Andy Lutomirski  wrote:

> > What new syscalls would be needed for ssh to get all this support?
> 
> This patchset or similar, plus some user code and an enclave to use.
> 
> Sadly, on current CPUs, you also need Intel to bless the enclave.  It looks 
> like 
> new CPUs might relax that requirement.

That looks like a fundamental technical limitation in my book - to an open 
source 
user this is essentially a very similar capability as tboot: it only allows the 
execution of externally blessed static binary blobs...

I don't think we can merge any of this upstream until it's clear that the 
hardware 
owner running open-source user-space can also freely define/start his own 
secure 
enclaves without having to sign the enclave with any external party. I.e. 
self-signed enclaves should be fundamentally supported as well.

Thanks,

Ingo
--
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 0/6] Intel Secure Guard Extensions

2016-04-27 Thread Pavel Machek 
Hi!

> > > Preventing cold boot attacks is really just icing on the cake.  The
> > > real point of this is to allow you to run an "enclave".  An SGX
> > > enclave has unencrypted code but gets access to a key that only it can
> > > access.  It could use that key to unwrap your ssh private key and sign
> > > with it without ever revealing the unwrapped key.  No one, not even
> > > root, can read enclave memory once the enclave is initialized and gets
> > > access to its personalized key.  The point of the memory encryption
> > > engine to to prevent even cold boot attacks from being used to read
> > > enclave memory.
> >
> > Ok, so the attacker can still access the "other" machine, but ok, key
> > is protected.
> >
> > But... that will mean that my ssh will need to be SGX-aware, and that
> > I will not be able to switch to AMD machine in future. ... or to other
> > Intel machine for that matter, right?
> 
> That's the whole point.  You could keep an unwrapped copy of the key
> offline so you could provision another machine if needed.
> 
> >
> > What new syscalls would be needed for ssh to get all this support?
> 
> This patchset or similar, plus some user code and an enclave to use.
> 
> Sadly, on current CPUs, you also need Intel to bless the enclave.  It
> looks like new CPUs might relax that requirement.

Umm. I'm afraid my evil meter just went over "smells evil" and "bit
evil" areas straight to "certainly looks evil".

> > > Replay Protected Memory Block.  It's a device that allows someone to
> > > write to it and confirm that the write happened and the old contents
> > > is no longer available.  You could use it to implement an enclave that
> > > checks a password for your disk but only allows you to try a certain
> > > number of times.
> >
> > Ookay... I guess I can get a fake Replay Protected Memory block, which
> > will confirm that write happened and not do anything from China, but
> > ok, if you put that memory on the CPU, you raise the bar to a "rather
> > difficult" (tm) level. Nice.
> 
> It's not so easy for the RPMB to leak things.  It would be much easier
> for it to simply not provide replay protection (i.e. more or less what
> the FBI asked from Apple: keep allowing guesses even though that
> shouldn't work).

Yup.

> > But that also means that when my CPU dies, I'll no longer be able to
> > access the encrypted data.
> 
> You could implement your own escrow policy and keep a copy in the
> safe.

And then Intel would have to bless my own escrow policy, which is,
realistically, not going to happen, right?

> > And, again, it means that quite complex new kernel-user interface will
> > be needed, right?
> 
> It's actually fairly straightforward, and the kernel part doesn't care
> what you use it for (the kernel part is the same for disk encryption
> and ssh, for example, except that disk encryption would care about
> replay protection, whereas ssh wouldn't).

So we end up with parts of kernel we can not change, and where we may
not even change the compiler. That means assembly. Hey, user, you have
freedom to this code, except it will not work. That was called TiVo
before. We'd have security-relevant parts of kernel where we could not
even fix a securit holes without Intel.

If anything, this is reason to switch to GPLv3.

I'm sorry. This is evil.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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: [RFC6 PATCH v6 00/21] ILP32 for ARM64 - LTP results

2016-04-27 Thread Andrew Pinski 
On Fri, Apr 22, 2016 at 8:37 PM, Zhangjian (Bamvor)
 wrote:
> Hi, Yury
>
>
> On 2016/4/6 6:44, Yury Norov wrote:
>>
>> There are about 20 failing tests of 782 in lite scenario.
>> float_bessel
>> float_exp_log
>> float_iperb
>> float_power
>> float_trigo
>> pipeio_1
>> pipeio_3
>> pipeio_5
>> pipeio_8
>> abort01
>> clone02
>> kill11
>> mmap16
>> open12
>> pause01
>> rename11
>> rmdir02
>> umount2_01
>> umount2_02
>> umount2_03
>> utime06
>> mtest06
>>
>> The list is rough because some tests fail not every time.
>>
>> Tests abort01 and kill11 fail for lp64 too, so maybe there's
>> a reason unrelated to ilp32 itself.
>>
>> float_xxx tests fail because they call unwind() from signal context,
>> and GCC for ilp32 has problem with it, as Andrew told.
>
> Is there some progress about this issue. When we talk about unwind
> functions, do you mean the function in libgcc?
>
> We encountered another issue(abort not segfault) which also called
> pthread_cancel(). The test code is in the attachment. Here is the
> backtrace:

Yes this was a known issue I knew about.  I have a patch GCC to fix
this.  Basically REG_VALUE_IN_UNWIND_CONTEXT needs to be defined while
building libgcc to support the correct unwind information.
I will be posting a GCC patch to fix this tomorrow.  This was a bug
even in the original set of ilp32 patches.  I only finally was able to
sit down and fix it today.


Thanks,
Andrew

>
> ```
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 0xf77ee330 (LWP 2958)]
> 0x0040f5bc in raise (sig=sig@entry=6)
> at ../sysdeps/unix/sysv/linux/raise.c:55
> 55  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x0040f5bc in raise (sig=sig@entry=6)
> at ../sysdeps/unix/sysv/linux/raise.c:55
> #1  0x0040f884 in abort () at abort.c:89
>
> #2  0x004073b4 in uw_update_context_1 (
> context=context@entry=0xf77ec820, fs=fs@entry=0xf77ebec8)
> at /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind-dw2.c:1430
>
> #3  0x004078c0 in uw_update_context
> (context=context@entry=0xf77ec820,
> fs=fs@entry=0xf77ebec8)
>at
> /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind-dw2.c:1506
> #4  0x00407a9c in uw_advance_context (fs=0xf77ebec8,
> context=0xf77ec820)
> at
> /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind-dw2.c:1529
> #5  _Unwind_ForcedUnwind_Phase2 (exc=exc@entry=0xf77ee580,
> context=context@entry=0xf77ec820)
> at /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind.inc:185
> #6  0x00408228 in _Unwind_ForcedUnwind (exc=0xf77ee580,
> stop=stop@entry=0x405440 , stop_argument=0xf77eddd8)
> at /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind.inc:207
> #7  0x004055c4 in __pthread_unwind (buf=)
> at unwind.c:126
> #8  0x004050b4 in __do_cancel () at ./pthreadP.h:283
> #9  sigcancel_handler (sig=, si=,
> ctx=) at nptl-init.c:225
> ---Type  to continue, or q  to quit---
> #10 
>
> #11 0x in ?? ()
>
> #12 0x00423084 in __select (nfds=-1, readfds=,
> writefds=, exceptfds=, timeout=0x0)
> at ../sysdeps/unix/sysv/linux/generic/select.c:45
> #13 0x00400604 in TEST_TaskDelay (
> uiMillSecs=)
> at test-cancel.c:18
> #14 0x00400680 in printids (
> s=)
> at test-cancel.c:38
> #15 0x004006d0 in thr_fn (
> arg=)
> at test-cancel.c:49
> #16 0x00401b28 in start_thread (arg=0x4a3000) at
> pthread_create.c:335
> #17 0x00401b28 in start_thread (arg=0x4a3000) at
> pthread_create.c:335
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> ```
>
> Such abort is raise by the following code:
> ```
> static void
> uw_update_context_1 (struct _Unwind_Context *context, _Unwind_FrameState
> *fs)
> {
> //...
>   /* Compute this frame's CFA.  */
>   switch (fs->regs.cfa_how)
> {
> case CFA_REG_OFFSET:
>   cfa = _Unwind_GetPtr (_context, fs->regs.cfa_reg);
>   cfa += fs->regs.cfa_offset;
>   break;
>
> case CFA_EXP:
>   {
> const unsigned char *exp = fs->regs.cfa_exp;
> _uleb128_t len;
>
> exp = read_uleb128 (exp, );
> cfa = (void *) (_Unwind_Ptr)
>   execute_stack_op (exp, exp + len, _context, 0);
> break;
>   }
>
> default:
>   gcc_unreachable ();
> }
>   context->cfa = cfa;
> //...
> }
> ``
>
> Any suggestion is appreciated.
>
> CC gcc mailing list. Sorry if it is off topic.
>
> Regards
>
> Bamvor
>
>
>
>
>> pipeio_x tests are very unstable and may fail randomly. I strongly
>> suspect race conditions, as they all work like a charm if pinned to
>> single CPU with taskset. Probably, race is the reason of clone02 too.
>> Though I'm not sure, is the race in kernel, glibc or test itself.
>>
>> But I know for sure that pause01 fails due to test design:
>> if

Re: [PATCH] fs: fix over-zealous use of "const"

2016-04-27 Thread James Morris 
On Thu, 21 Apr 2016, Kees Cook wrote:

> When I was fixing up const recommendations from checkpatch.pl, I went
> overboard. This fixes the warning (during a W=1 build):
> 
> include/linux/fs.h:2627:74: warning: type qualifiers ignored on function 
> return type [-Wignored-qualifiers]
> static inline const char * const kernel_read_file_id_str(enum 
> kernel_read_file_id id)
> 
> Reported-by: Andy Shevchenko 
> Signed-off-by: Kees Cook 
> ---
> This is for linux-security next
> ---

Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next


-- 
James Morris


--
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