On Mon, 12 Feb 2018, Pavel Machek wrote:
> On Tue 2017-12-26 23:43:54, Tom Lendacky wrote:
> > AMD processors are not subject to the types of attacks that the kernel
> > page table isolation feature protects against. The AMD microarchitecture
> > does not allow memory references, including
On Mon, 12 Feb 2018, Pavel Machek wrote:
> On Tue 2017-12-26 23:43:54, Tom Lendacky wrote:
> > AMD processors are not subject to the types of attacks that the kernel
> > page table isolation feature protects against. The AMD microarchitecture
> > does not allow memory references, including
On Mon, Feb 12, 2018 at 10:26 AM, Pavel Machek wrote:
> On Tue 2017-12-26 23:43:54, Tom Lendacky wrote:
>> AMD processors are not subject to the types of attacks that the kernel
>> page table isolation feature protects against. The AMD microarchitecture
>> does not allow memory
On Mon, Feb 12, 2018 at 10:26 AM, Pavel Machek wrote:
> On Tue 2017-12-26 23:43:54, Tom Lendacky wrote:
>> AMD processors are not subject to the types of attacks that the kernel
>> page table isolation feature protects against. The AMD microarchitecture
>> does not allow memory references,
On Tue 2017-12-26 23:43:54, Tom Lendacky wrote:
> AMD processors are not subject to the types of attacks that the kernel
> page table isolation feature protects against. The AMD microarchitecture
> does not allow memory references, including speculative references, that
> access higher privileged
On Tue 2017-12-26 23:43:54, Tom Lendacky wrote:
> AMD processors are not subject to the types of attacks that the kernel
> page table isolation feature protects against. The AMD microarchitecture
> does not allow memory references, including speculative references, that
> access higher privileged
On 12/26/2017 09:43 PM, Tom Lendacky wrote:
>AMD processors are not subject to the types of attacks that the kernel page
>table isolation
feature protects against.
There is no doubt this is a serious flaw. This thread reminded me - about a
year ago we
discovered a software code that bricked
On 12/26/2017 09:43 PM, Tom Lendacky wrote:
>AMD processors are not subject to the types of attacks that the kernel page
>table isolation
feature protects against.
There is no doubt this is a serious flaw. This thread reminded me - about a
year ago we
discovered a software code that bricked
Why this wonderful tiny patch by Tom Lendacky is still not merged? If
it is just Intel who made these insecure CPUs , for which this
"slowdown workaround" is required, ---> why the AMD CPU owners should
suffer from Intel's design faults ? " cpu_insecure " is Intel's
problem ; according to Tom
Why this wonderful tiny patch by Tom Lendacky is still not merged? If
it is just Intel who made these insecure CPUs , for which this
"slowdown workaround" is required, ---> why the AMD CPU owners should
suffer from Intel's design faults ? " cpu_insecure " is Intel's
problem ; according to Tom
On Tue, Dec 26, 2017 at 11:43:54PM -0600, Tom Lendacky wrote:
> AMD processors are not subject to the types of attacks that the kernel
> page table isolation feature protects against. The AMD microarchitecture
> does not allow memory references, including speculative references, that
> access
On Tue, Dec 26, 2017 at 11:43:54PM -0600, Tom Lendacky wrote:
> AMD processors are not subject to the types of attacks that the kernel
> page table isolation feature protects against. The AMD microarchitecture
> does not allow memory references, including speculative references, that
> access
On 12/27/2017 2:48 AM, Dave Hansen wrote:
> On 12/26/2017 09:43 PM, Tom Lendacky wrote:
>> --- a/arch/x86/kernel/cpu/common.c
>> +++ b/arch/x86/kernel/cpu/common.c
>> @@ -923,8 +923,8 @@ static void __init early_identify_cpu(struct cpuinfo_x86
>> *c)
>>
>>
On 12/27/2017 2:48 AM, Dave Hansen wrote:
> On 12/26/2017 09:43 PM, Tom Lendacky wrote:
>> --- a/arch/x86/kernel/cpu/common.c
>> +++ b/arch/x86/kernel/cpu/common.c
>> @@ -923,8 +923,8 @@ static void __init early_identify_cpu(struct cpuinfo_x86
>> *c)
>>
>>
On 12/26/2017 09:43 PM, Tom Lendacky wrote:
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -923,8 +923,8 @@ static void __init early_identify_cpu(struct cpuinfo_x86
> *c)
>
> setup_force_cpu_cap(X86_FEATURE_ALWAYS);
>
> - /* Assume for now that ALL
On 12/26/2017 09:43 PM, Tom Lendacky wrote:
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -923,8 +923,8 @@ static void __init early_identify_cpu(struct cpuinfo_x86
> *c)
>
> setup_force_cpu_cap(X86_FEATURE_ALWAYS);
>
> - /* Assume for now that ALL
AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that
AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that
18 matches
Mail list logo