Re: [PATCH] MAINTAINERS: Add Krzysztof Kozlowski as maintainer of crypto/s5p-sss

2017-03-10 Thread Krzysztof Kozlowski 
On Fri, Mar 10, 2017 at 11:18:13PM +0200, Vladimir Zapolskiy wrote:
> Hi Krzysztof,
> 
> On 03/10/2017 09:10 PM, Krzysztof Kozlowski wrote:
> > Beside developing of this driver recently, I handle also reviews and
> > bug reports from users so having a maintainer entry will ensure that I
> > will be CC-ed on important emails.
> 
> if you assume that the driver needs a special maintainership, can you
> add me as a co-maintainer? I'll review new changes as usual and do
> regression testing on legacy SoCs.

Of course, I'll send a v2.

Best regards,
Krzysztof

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

2017-03-10 Thread Brijesh Singh 

Hi Boris,

On 03/10/2017 05:06 AM, Borislav Petkov wrote:

On Thu, Mar 02, 2017 at 10:15:15AM -0500, Brijesh Singh wrote:

If kernel_maps_pages_in_pgd is called early in boot process to change the


kernel_map_pages_in_pgd()


memory attributes then it fails to allocate memory when spliting large
pages. The patch extends the cpa_data to provide the support to use
memblock_alloc when slab allocator is not available.

The feature will be used in Secure Encrypted Virtualization (SEV) mode,
where we may need to change the memory region attributes in early boot
process.

Signed-off-by: Brijesh Singh 
---
 arch/x86/mm/pageattr.c |   51 
 1 file changed, 42 insertions(+), 9 deletions(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 46cc89d..9e4ab3b 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -37,6 +38,7 @@ struct cpa_data {
int flags;
unsigned long   pfn;
unsignedforce_split : 1;
+   unsignedforce_memblock :1;
int curpage;
struct page **pages;
 };
@@ -627,9 +629,8 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,

 static int
 __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,
-  struct page *base)
+ pte_t *pbase, unsigned long new_pfn)
 {
-   pte_t *pbase = (pte_t *)page_address(base);
unsigned long ref_pfn, pfn, pfninc = 1;
unsigned int i, level;
pte_t *tmp;
@@ -646,7 +647,7 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, 
unsigned long address,
return 1;
}

-   paravirt_alloc_pte(_mm, page_to_pfn(base));
+   paravirt_alloc_pte(_mm, new_pfn);

switch (level) {
case PG_LEVEL_2M:
@@ -707,7 +708,8 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, 
unsigned long address,
 * pagetable protections, the actual ptes set above control the
 * primary protection behavior:
 */
-   __set_pmd_pte(kpte, address, mk_pte(base, __pgprot(_KERNPG_TABLE)));
+   __set_pmd_pte(kpte, address,
+   native_make_pte((new_pfn << PAGE_SHIFT) + _KERNPG_TABLE));

/*
 * Intel Atom errata AAH41 workaround.
@@ -723,21 +725,50 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, 
unsigned long address,
return 0;
 }

+static pte_t *try_alloc_pte(struct cpa_data *cpa, unsigned long *pfn)
+{
+   unsigned long phys;
+   struct page *base;
+
+   if (cpa->force_memblock) {
+   phys = memblock_alloc(PAGE_SIZE, PAGE_SIZE);


Maybe there's a reason this fires:

WARNING: modpost: Found 2 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'

WARNING: vmlinux.o(.text+0x48edc): Section mismatch in reference from the 
function __change_page_attr() to the function .init.text:memblock_alloc()
The function __change_page_attr() references
the function __init memblock_alloc().
This is often because __change_page_attr lacks a __init
annotation or the annotation of memblock_alloc is wrong.

WARNING: vmlinux.o(.text+0x491d1): Section mismatch in reference from the 
function __change_page_attr() to the function .meminit.text:memblock_free()
The function __change_page_attr() references
the function __meminit memblock_free().
This is often because __change_page_attr lacks a __meminit
annotation or the annotation of memblock_free is wrong.



I can take a look at fixing those warning. In my initial attempt was to create
a new function to clear encryption bit but it ended up looking very similar to
__change_page_attr_set_clr() hence decided to extend the exiting function to
use memblock_alloc().



Why do we need this whole early mapping? For the guest? I don't like
that memblock thing at all.


Early in boot process, guest kernel allocates some structure (its either
statically allocated or dynamic allocated via memblock_alloc). And shares the 
physical
address of these structure with hypervisor. Since entire guest memory area is 
mapped
as encrypted hence those structure's are mapped as encrypted memory range. We 
need
a method to clear the encryption bit. Sometime these structure maybe part of 2M 
pages
and need to split into smaller pages.



So I think the approach with the .data..percpu..hv_shared section is
fine and we should consider SEV-ES

http://support.amd.com/TechDocs/Protecting%20VM%20Register%20State%20with%20SEV-ES.pdf

and do this right from the get-go so that when SEV-ES comes along, we
should simply be ready and extend that mechanism to put the whole Guest
Hypervisor Communication Block in there.




But then the fact that you're mapping those decrypted in init_mm.pgd
makes me think you don't need that early mapping thing at all. Those are
the decrypted mappings

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

2017-03-10 Thread Nathan Royce 
Sure, I went ahead and rebuilt it just using the bare exynos_defconfig
and adding XTS and ECB and no other changes.

No flags were used. No patches were used other than the 2 you
provided. Just the barest of bears, the barest of bones, the barest of
deserts, the barest of hairless cats.

I also wiped out the 4.10.1 modules directory and zImage and dtb
before copying them into place.
*
[   16.280951] s5p-jpeg 11f6.jpeg: Samsung S5P JPEG codec
[   16.327434] CPU: 3 PID: 115 Comm: irq/69-1083 Not tainted 4.10.1-dirty #1
[   16.334527] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   16.340533] task: edc52d00 task.stack: edcc
[   16.345040] PC is at post_crypt+0x194/0x1a0 [xts]
[   16.349712] LR is at post_crypt+0x188/0x1a0 [xts]
[   16.354390] pc : []lr : []psr: 200d0113
[   16.354390] sp : edcc1ea8  ip : ed6f38f4  fp : 30702272
[   16.365838] r10: 8ee5436d  r9 :   r8 : ed6f3800
[   16.371023] r7 :   r6 : 0400  r5 :   r4 : 
[   16.377523] r3 : ef5ead22  r2 : 0200  r1 : 0200  r0 : 
[   16.384024] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[   16.391128] Control: 10c5387d  Table: 6d6f806a  DAC: 0051
[   16.396847] Process irq/69-1083 (pid: 115, stack limit = 0xedcc0210)
[   16.403519] Stack: (0xedcc1ea8 to 0xedcc2000)
[   16.407853] 1ea0:   c0c08304 ef5ead20 ecd69200
ef5ead20 ecd69200 ed6f39dc
[   16.416011] 1ec0: 0400   0400 
c010f774 c0113bac 
[   16.424156] 1ee0:     
0010 0010 000f
[   16.432302] 1f00: ed6f3800 edcae3bc 000c edcae3e8 
600d0113 ee889d5c bf182764
[   16.440447] 1f20: edcae390 c0566d84  0001 edcacec0
eea14b00  eea14b00
[   16.448592] 1f40: edcacec0 c01651c4 eeb00528 c01651e0 edcc
edcacee4  c01654b4
[   16.456738] 1f60:  c01652b8 eeb00500 edcc 
edcacf00 edcacec0 c0165388
[   16.464884] 1f80: eeb00528 c013673c edcc edcacf00 c0136634
  
[   16.473029] 1fa0:    c0107778 
  
[   16.481174] 1fc0:     
  
[   16.489320] 1fe0:     0013
  
[   16.497473] [] (post_crypt [xts]) from []
(decrypt_done+0x4c/0x54 [xts])
[   16.505877] [] (decrypt_done [xts]) from []
(s5p_aes_interrupt+0x1bc/0x208)
[   16.514544] [] (s5p_aes_interrupt) from []
(irq_thread_fn+0x1c/0x54)
[   16.522592] [] (irq_thread_fn) from []
(irq_thread+0x12c/0x1e0)
[   16.530220] [] (irq_thread) from [] (kthread+0x108/0x138)
[   16.537324] [] (kthread) from []
(ret_from_fork+0x14/0x3c)
[   16.544514] Code: eb471ad2 e598c118 e58d0020 e1a04000 (e5906004)
[   16.550709] ---[ end trace 0e5ce4ea2ad2d7e2 ]---
[   16.555224] genirq: exiting task "irq/69-1083" (115) is an
active IRQ thread (irq 69)
*
I'm sure you could just copy my crypttab and fstab entries that is
shown in my first email.

On Fri, Mar 10, 2017 at 12:06 PM, Krzysztof Kozlowski  wrote:
> On Thu, Mar 09, 2017 at 05:16:35AM -0600, Nathan Royce wrote:
>> Gave it a try on 4.10.1, but still to no avail:
>
> (...)
>
>> Also for the sake of testing, I did not add any FLAGS for compilation this 
>> time.
>
> Damn, I am fixing bugs around but not the one you are hitting. Can you
> also check if exynos_defconfig (+XTS + any other needed setting sfor
> you) also has this issue?
>
> I want to reproduce it but my setup does not use cryptswap. Probably I
> will have to set it up.
>
> Best regards,
> Krzysztof
>


config_s5psss.tar.gz
Description: GNU Zip compressed data

Re: [PATCH] MAINTAINERS: Add Krzysztof Kozlowski as maintainer of crypto/s5p-sss

2017-03-10 Thread Vladimir Zapolskiy 
Hi Krzysztof,

On 03/10/2017 09:10 PM, Krzysztof Kozlowski wrote:
> Beside developing of this driver recently, I handle also reviews and
> bug reports from users so having a maintainer entry will ensure that I
> will be CC-ed on important emails.

if you assume that the driver needs a special maintainership, can you
add me as a co-maintainer? I'll review new changes as usual and do
regression testing on legacy SoCs.

Thanks.

--
With best wishes,
Vladimir

[PATCH] MAINTAINERS: Add Krzysztof Kozlowski as maintainer of crypto/s5p-sss

2017-03-10 Thread Krzysztof Kozlowski 
Beside developing of this driver recently, I handle also reviews and
bug reports from users so having a maintainer entry will ensure that I
will be CC-ed on important emails.

Cc: Vladimir Zapolskiy 
Cc: Herbert Xu 
Signed-off-by: Krzysztof Kozlowski 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 57634d0f3486..5dcd65e98b51 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10985,6 +10985,13 @@ F: 
Documentation/devicetree/bindings/regulator/samsung,s2m*.txt
 F: Documentation/devicetree/bindings/regulator/samsung,s5m*.txt
 F: Documentation/devicetree/bindings/clock/samsung,s2mps11.txt
 
+SAMSUNG S5P Security SubSystem (SSS) DRIVER
+M: Krzysztof Kozlowski 
+L: linux-crypto@vger.kernel.org
+L: linux-samsung-...@vger.kernel.org
+S: Maintained
+F: drivers/crypto/s5p-sss.c
+
 SAMSUNG S5P/EXYNOS4 SOC SERIES CAMERA SUBSYSTEM DRIVERS
 M: Kyungmin Park 
 M: Sylwester Nawrocki 
-- 
2.9.3

[PATCH] crypto: ccp - Assign DMA commands to the channel's CCP

2017-03-10 Thread Gary R Hook 
From: Gary R Hook 

The CCP driver generally uses a round-robin approach when
assigning operations to available CCPs. For the DMA engine,
however, the DMA mappings of the SGs are associated with a
specific CCP. When an IOMMU is enabled, the IOMMU is
programmed based on this specific device.

If the DMA operations are not performed by that specific
CCP then addressing errors and I/O page faults will occur.

Update the CCP driver to allow a specific CCP device to be
requested for an operation and use this in the DMA engine
support.

Cc:  # 4.9.x-
Signed-off-by: Gary R Hook 
---
 drivers/crypto/ccp/ccp-dev.c   |5 -
 drivers/crypto/ccp/ccp-dmaengine.c |1 +
 include/linux/ccp.h|2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index 511ab04..92d1c69 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -283,11 +283,14 @@ unsigned int ccp_version(void)
  */
 int ccp_enqueue_cmd(struct ccp_cmd *cmd)
 {
-   struct ccp_device *ccp = ccp_get_device();
+   struct ccp_device *ccp;
unsigned long flags;
unsigned int i;
int ret;
 
+   /* Some commands might need to be sent to a specific device */
+   ccp = cmd->ccp ? cmd->ccp : ccp_get_device();
+
if (!ccp)
return -ENODEV;
 
diff --git a/drivers/crypto/ccp/ccp-dmaengine.c 
b/drivers/crypto/ccp/ccp-dmaengine.c
index e5d9278..8d0eeb4 100644
--- a/drivers/crypto/ccp/ccp-dmaengine.c
+++ b/drivers/crypto/ccp/ccp-dmaengine.c
@@ -390,6 +390,7 @@ static struct ccp_dma_desc *ccp_create_desc(struct dma_chan 
*dma_chan,
goto err;
 
ccp_cmd = >ccp_cmd;
+   ccp_cmd->ccp = chan->ccp;
ccp_pt = _cmd->u.passthru_nomap;
ccp_cmd->flags = CCP_CMD_MAY_BACKLOG;
ccp_cmd->flags |= CCP_CMD_PASSTHRU_NO_DMA_MAP;
diff --git a/include/linux/ccp.h b/include/linux/ccp.h
index c71dd8f..c41b8d99 100644
--- a/include/linux/ccp.h
+++ b/include/linux/ccp.h
@@ -556,7 +556,7 @@ enum ccp_engine {
  * struct ccp_cmd - CCP operation request
  * @entry: list element (ccp driver use only)
  * @work: work element used for callbacks (ccp driver use only)
- * @ccp: CCP device to be run on (ccp driver use only)
+ * @ccp: CCP device to be run on
  * @ret: operation return code (ccp driver use only)
  * @flags: cmd processing flags
  * @engine: CCP operation to perform

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

2017-03-10 Thread Krzysztof Kozlowski 
On Thu, Mar 09, 2017 at 05:16:35AM -0600, Nathan Royce wrote:
> Gave it a try on 4.10.1, but still to no avail:

(...)

> Also for the sake of testing, I did not add any FLAGS for compilation this 
> time.

Damn, I am fixing bugs around but not the one you are hitting. Can you
also check if exynos_defconfig (+XTS + any other needed setting sfor
you) also has this issue?

I want to reproduce it but my setup does not use cryptswap. Probably I
will have to set it up.

Best regards,
Krzysztof

Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active

2017-03-10 Thread Brijesh Singh 

Hi Boris and Paolo,

On 03/09/2017 10:29 AM, Borislav Petkov wrote:

On Thu, Mar 09, 2017 at 05:13:33PM +0100, Paolo Bonzini wrote:

This is not how you check if running under a hypervisor; you should
check the HYPERVISOR bit, i.e. bit 31 of cpuid(1).ecx.  This in turn
tells you if leaf 0x4000 is valid.


Ah, good point, I already do that in the microcode loader :)

/*
 * CPUID(1).ECX[31]: reserved for hypervisor use. This is still not
 * completely accurate as xen pv guests don't see that CPUID bit set but
 * that's good enough as they don't land on the BSP path anyway.
 */
if (native_cpuid_ecx(1) & BIT(31))
return *res;


That said, the main issue with this function is that it hardcodes the
behavior for KVM.  It is possible that another hypervisor defines its
0x4001 leaf in such a way that KVM_FEATURE_SEV has a different meaning.

Instead, AMD should define a "well-known" bit in its own space (i.e.
0x80xx) that is only used by hypervisors that support SEV.  This is
similar to how Intel defined one bit in leaf 1 to say "is leaf
0x4000 valid".


+   if (eax > 0x4000) {
+   eax = 0x4001;
+   ecx = 0;
+   native_cpuid(, , , );
+   if (!(eax & BIT(KVM_FEATURE_SEV)))
+   goto out;
+
+   eax = 0x801f;
+   ecx = 0;
+   native_cpuid(, , , );
+   if (!(eax & 1))


Right, so this is testing CPUID_0x801f_ECX(0)[0], SME. Why not
simply set that bit for the guest too, in kvm?



CPUID_8000_001F[EAX] indicates whether the feature is supported.
CPUID_0x801F[EAX]:
 * Bit 0 - SME supported
 * Bit 1 - SEV supported
 * Bit 3 - SEV-ES supported

We can use MSR_K8_SYSCFG[MemEncryptionModeEnc] to check if memory encryption is 
enabled.
Currently, KVM returns zero when guest OS read MSR_K8_SYSCFG. I can update my 
patch sets
to set this bit for SEV enabled guests.

We could update this patch to use the below logic:

 * CPUID(0) - Check for AuthenticAMD
 * CPID(1) - Check if under hypervisor
 * CPUID(0x8000) - Check for highest supported leaf
 * CPUID(0x801F).EAX - Check for SME and SEV support
 * rdmsr (MSR_K8_SYSCFG)[MemEncryptionModeEnc] - Check if SMEE is set


Paolo,

One question, do we need "AuthenticAMD" check when we are running under 
hypervisor ?
I was looking at qemu code and found that qemu exposes parameters to change the 
CPU
vendor id. The above check will fail if user changes the vendor id while 
launching
the SEV guest.

-Brijesh

dm-crypt IV generation (summary)

2017-03-10 Thread Ondrej Mosnacek 
Hi all,

I was tasked to post a summary the whole dm-crypt IV generation
problem and all the suggested solutions along with their drawbacks, so
here it goes...

PROBLEM STATEMENT:
Currently, dm-crypt uses a fixed 512-byte sector size and handles
en-/decrypting of a bio by submitting a separate request to the crypto
API for each sector. This causes a performance problem with some
crypto drivers that have a high processing overhead for small
requests, i.e. most crypto accelerators [1][2] and also e.g. the
AES-NI driver [3].

POSSIBLE SOLUTIONS:
1. Move IV generator algorithms to crypto API and allow them to
process the whole bio at once. ([5] or something equivalent)
ISSUES:
a) The 'keycount' parameter.
In order to support multi-key modes from Loop-AES,
dm-crypt accepts a keycount parameter which, if it != 1, causes
consecutive sectors to be encrypted with a different key. This
parameter can be specified with any of the cipher modes, which makes
porting the whole scale of modes supported by dm-crypt to crypto API
rather messy, since a lot of dm-crypt specific stuff needs to be moved
into the crypto drivers.
b) New AEAD functionality; random IV generator.
The soon-to-be-added AEAD functionality in dm-crypt
introduces a new IV generator that generates IVs randomly and stores
them as sector metadata. This means IV generation cannot be handled
solely in the driver. Also, additional AEAD implementation of IV
generators would be eventually needed.

2. Restrict the keycount parameter to allow only reasonable
combinations and then move IV generators to crypto API.
In Loop-AES, the multi-key mode always uses exactly 64 keys and
there is no reasonable scenario where someone would like to use
keycount != 1 with other IV mode than LMK. Thus it might be acceptable
to only work with multiple keys in LMK (and only allow keycount == 64
for it) and work with just one key in all other modes (and only allow
keycount == 1 for them). I.e., the cipher format would remain the
same, just with more restricted values.

Note that this would be basically a breaking change (the keycount
parameter is documented [4], so there may be users somewhere that use
it in some unusual combination...). Still, such combinations would
have to be used explicitly, as they are never used with common
LUKS/Loop-AES/TrueCrypt partitions (something like cryptsetup --type
plain ... or dmsetup would have to be used directly).

Applying this change would allow implementing the IV generators as
simple crypto algorithms that honor the usual interface (without
setkey hacks and passing of special structures via IV).

ISSUES:
a) Backward incompatibility (see above).
b) Again need to somehow handle the new 'random' IV generator.

3. Extend crypto API to allow passing multiple requests at once (each
with a separate IV) to crypto drivers.
(see [3])
ISSUES:
a) HW accelerators would have to specifically support this
scheme (unless they are somehow programmable).
I.e. accelerators that already have the plain64 IV
generator hard-coded could not fully benefit from this (I don't know
how many are already out there). However, future ones could implement
this 'universal' IV mode and enjoy basically the same benefit.

4. Implement support of 4KB sectors (or other sizes, too) in dm-crypt.
This would partially help, since on devices with 4K sectors the
size of each crypto request would then be 8x bigger and overhead would
be reduced without the need to mess with the dm-crypt IV generators.

ISSUES:
a) Only 4KB would be processed at once, not the whole bio (but
it may suffice).
b) Partitions encrypted as 4KB sectors could not be safely
moved to a 512B-sector device (writes would not be atomic).

QUESTIONS:
@Mike/dm-devel: Do you think it would be feasible to apply solution 2
(thus introducing the small incompatibility)?

REFERENCES:
[1] 
https://nelenkov.blogspot.com/2015/05/hardware-accelerated-disk-encryption-in.html
[2] https://lkml.org/lkml/2017/3/2/274
[3] https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg23007.html
[4] https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt
[5] https://lkml.org/lkml/2017/2/7/182

Cheers,
Ondrej

CRYPTO_MAX_ALG_NAME is too low

2017-03-10 Thread Alexander Sverdlin 
Hello crypto maintainers!

We've found and example of the ipsec algorithm combination, which doesn't fit
into CRYPTO_MAX_ALG_NAME long buffers:

ip x s add src 1.1.1.1 dst 1.1.1.2 proto esp spi 0 mode tunnel enc des3_ede 0x0 
auth sha256 0x0 flag esn replay-window 256

produces "echainiv(authencesn(hmac(sha256-generic),cbc(des3_ede-generic)))"
on the machines without optimized crypto drivers, which doesn't fit into current
64-bytes buffers.

I see two possible options:

a) split CRYPTO_MAX_ALG_NAME into CRYPTO_MAX_ALG_NAME + CRYPTO_MAX_DRV_NAME pair
and make later, say, 96, because the former probably cannot be changed because 
of
numerous user-space exports. And change half of the code to use new define.

b) rename *-generic algorithms to *-gen, so that cra_driver_name will be 
shortened,
while MODULE_ALIAS_CRYPTO() could still be maintained in old and new form.

What are your thoughts?

-- 
Best regards,
Alexander Sverdlin.

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

2017-03-10 Thread Borislav Petkov 
On Thu, Mar 02, 2017 at 10:15:15AM -0500, Brijesh Singh wrote:
> If kernel_maps_pages_in_pgd is called early in boot process to change the

kernel_map_pages_in_pgd()

> memory attributes then it fails to allocate memory when spliting large
> pages. The patch extends the cpa_data to provide the support to use
> memblock_alloc when slab allocator is not available.
> 
> The feature will be used in Secure Encrypted Virtualization (SEV) mode,
> where we may need to change the memory region attributes in early boot
> process.
> 
> Signed-off-by: Brijesh Singh 
> ---
>  arch/x86/mm/pageattr.c |   51 
> 
>  1 file changed, 42 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> index 46cc89d..9e4ab3b 100644
> --- a/arch/x86/mm/pageattr.c
> +++ b/arch/x86/mm/pageattr.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -37,6 +38,7 @@ struct cpa_data {
>   int flags;
>   unsigned long   pfn;
>   unsignedforce_split : 1;
> + unsignedforce_memblock :1;
>   int curpage;
>   struct page **pages;
>  };
> @@ -627,9 +629,8 @@ try_preserve_large_page(pte_t *kpte, unsigned long 
> address,
>  
>  static int
>  __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,
> -struct page *base)
> +   pte_t *pbase, unsigned long new_pfn)
>  {
> - pte_t *pbase = (pte_t *)page_address(base);
>   unsigned long ref_pfn, pfn, pfninc = 1;
>   unsigned int i, level;
>   pte_t *tmp;
> @@ -646,7 +647,7 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, 
> unsigned long address,
>   return 1;
>   }
>  
> - paravirt_alloc_pte(_mm, page_to_pfn(base));
> + paravirt_alloc_pte(_mm, new_pfn);
>  
>   switch (level) {
>   case PG_LEVEL_2M:
> @@ -707,7 +708,8 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, 
> unsigned long address,
>* pagetable protections, the actual ptes set above control the
>* primary protection behavior:
>*/
> - __set_pmd_pte(kpte, address, mk_pte(base, __pgprot(_KERNPG_TABLE)));
> + __set_pmd_pte(kpte, address,
> + native_make_pte((new_pfn << PAGE_SHIFT) + _KERNPG_TABLE));
>  
>   /*
>* Intel Atom errata AAH41 workaround.
> @@ -723,21 +725,50 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, 
> unsigned long address,
>   return 0;
>  }
>  
> +static pte_t *try_alloc_pte(struct cpa_data *cpa, unsigned long *pfn)
> +{
> + unsigned long phys;
> + struct page *base;
> +
> + if (cpa->force_memblock) {
> + phys = memblock_alloc(PAGE_SIZE, PAGE_SIZE);

Maybe there's a reason this fires:

WARNING: modpost: Found 2 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'

WARNING: vmlinux.o(.text+0x48edc): Section mismatch in reference from the 
function __change_page_attr() to the function .init.text:memblock_alloc()
The function __change_page_attr() references
the function __init memblock_alloc().
This is often because __change_page_attr lacks a __init
annotation or the annotation of memblock_alloc is wrong.

WARNING: vmlinux.o(.text+0x491d1): Section mismatch in reference from the 
function __change_page_attr() to the function .meminit.text:memblock_free()
The function __change_page_attr() references
the function __meminit memblock_free().
This is often because __change_page_attr lacks a __meminit
annotation or the annotation of memblock_free is wrong.

Why do we need this whole early mapping? For the guest? I don't like
that memblock thing at all.

So I think the approach with the .data..percpu..hv_shared section is
fine and we should consider SEV-ES

http://support.amd.com/TechDocs/Protecting%20VM%20Register%20State%20with%20SEV-ES.pdf

and do this right from the get-go so that when SEV-ES comes along, we
should simply be ready and extend that mechanism to put the whole Guest
Hypervisor Communication Block in there.

But then the fact that you're mapping those decrypted in init_mm.pgd
makes me think you don't need that early mapping thing at all. Those are
the decrypted mappings of the hypervisor. And that you can do late.

Now, what would be better, IMHO (and I have no idea about virtualization
design so take with a grain of salt) is if the guest would allocate
enough memory for the GHCB and mark it decrypted from the very
beginning. It will be the communication vehicle with the hypervisor
anyway.

And we already do similar things in sme_map_bootdata() for the baremetal
kernel to map boot_data, initrd, EFI, ... and so on things decrypted.

And we should extend that mechanism to map the GHCB in the guest too and
then we can get rid of all that need for ->force_memblock which makes
the crazy mess in pageattr.c even crazier. And it would be lovely if

[ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)

2017-03-10 Thread Stephan Müller 
Hi,

The patch set that can be downloaded at [1] provides a different approach to /
dev/random which I call Linux Random Number Generator (LRNG) to collect 
entropy within the Linux kernel. The main improvements compared to the legacy 
/dev/random is to provide sufficient entropy during boot time as well as in 
virtual environments and when using SSDs or Device Mapper targets. A secondary 
design goal is to limit the impact of the entropy collection on massive 
parallel systems and also allow the use accelerated cryptographic primitives. 
Also, all steps of the entropic data processing are testable. Finally 
performance improvements are visible at /dev/urandom and get_random_bytes.

The design and implementation is driven by a set of goals described in [2]
that the LRNG completely implements. Furthermore, [2] includes a
comparison with RNG design suggestions such as SP800-90B, SP800-90C, and
AIS20/31.

The LRNG has a flexible design by allowing an easy replacement of the
deterministic random number generator component. Currently implemented DRNGs
are an SP800-90A DRBG and a ChaCha20 DRNG.

[1] http://www.chronox.de/lrng.html

[2] http://www.chronox.de/lrng/doc/lrng.pdf

Ciao
Stephan