On Thu, Sep 15, 2016 at 12:08:04PM -0500, Tom Lendacky wrote:
> The problem is that this physical address does not contain the
> encryption bit, and even if it did, it wouldn't matter. The __va()
> define creates a virtual address that will be mapped as encrypted given
> the current approach (whic
On 09/14/2016 09:51 AM, Borislav Petkov wrote:
> On Wed, Sep 14, 2016 at 09:29:41AM -0500, Tom Lendacky wrote:
>> This is still required because just using the __va() would still cause
>> the mapping created to have the encryption bit set. The ioremap call
>> will result in the mapping not having t
On Wed, Sep 14, 2016 at 09:29:41AM -0500, Tom Lendacky wrote:
> This is still required because just using the __va() would still cause
> the mapping created to have the encryption bit set. The ioremap call
> will result in the mapping not having the encryption bit set.
I meant this: https://lkml.k
On 09/12/2016 11:59 AM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 05:38:59PM -0500, Tom Lendacky wrote:
>> Since the setup data is in memory in the clear, it must be accessed as
>> un-encrypted. Always use ioremap (similar to sysfs setup data support)
>> to map the data.
>>
>> Signed-off-by
On Mon, Aug 22, 2016 at 05:38:59PM -0500, Tom Lendacky wrote:
> Since the setup data is in memory in the clear, it must be accessed as
> un-encrypted. Always use ioremap (similar to sysfs setup data support)
> to map the data.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/kernel/kdebugfs.c |
Since the setup data is in memory in the clear, it must be accessed as
un-encrypted. Always use ioremap (similar to sysfs setup data support)
to map the data.
Signed-off-by: Tom Lendacky
---
arch/x86/kernel/kdebugfs.c | 30 +++---
1 file changed, 11 insertions(+), 19 d
