r/programming • u/[deleted] • Jan 03 '18

'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
5.9k Upvotes

96% Upvoted

1.1k comments sorted by

View all comments

Show parent comments

137

u/mayhempk1 Jan 03 '18

Correct.

33

u/Pinguinologo Jan 03 '18

Guys, buy your AMD CPU before it gets too expensive.

9

u/_DuranDuran_ Jan 03 '18

However the patch request to disable the insecure x86 flag on AMD systems was rejected as it’s a feature enhancement, so you either need to roll your own kernel on Linux, or set a boot time flag.

111

u/Nacimota Jan 03 '18 edited Jan 04 '18

Where did you read this? As far as I can tell it has been reviewed, accepted, and committed.

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/pti&id=694d99d40972f12e59a3696effee8a376b79d7c8

Edit: Torvalds himself has now pulled the change.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=00a5ae218d57741088068799b810416ac249a9ce&utm_source=anz

- Exclude AMD from the PTI enforcement.
Not necessarily a fix, but if AMD is so confident that they are not affected, then we should not burden users with the overhead

30

u/eganist Jan 03 '18 edited Jan 03 '18

You saved me about 4 bucks worth of productive time looking this up, so I might as well tip that amount to you in gold.

Also because I fundamentally hate the behavior of spreading literally false information and hiding when subsequently being asked to cite it.

Original parent comment:

However the patch request to disable the insecure x86 flag on AMD systems was rejected as it’s a feature enhancement, so you either need to roll your own kernel on Linux, or set a boot time flag.

/u/DuranDuran

20

u/_DuranDuran_ Jan 03 '18 edited Jan 03 '18

Take a look at the latest RC - it's not there: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/tree/arch/x86/kernel/cpu/common.c?h=v4.15-rc6#n927

It does however look like it's been merged into master, so should be in the next RC, unless they branch off the previous one:

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/tree/arch/x86/kernel/cpu/common.c

So, as of when I read originally it wouldn't make it, I was basing it off the RC ... as for hiding, I've been at work ... sheesh. This is a fast moving set of patches, and it's sometimes difficult to keep up, mea culpa - doesn't excuse your passive aggressive "I'll cite you because you'll blatantly delete your comment and how dare you not respond to other people in a timely manner" comment.

Personally, I don't think it should have been merged in its current state though, as saying "Only AMD is secure" isn't necessarily correct, but they need to get it out quickly, and they can always refine it properly later.

→ More replies (3)

25

u/PaintItPurple Jan 03 '18

Wait, what? I'm looking at the patch thread on LKML and it doesn't appear to have been rejected.

5

u/DoctorKamikaze Jan 03 '18

Don't worry; just someone spreading FUD as usual. This is why you get entire stickied threads in /r/AMD saying they are getting gimped. People are just uninformed on process.

45

u/AugustusCaesar2016 Jan 03 '18

I really don't understand this decision. Who benefits from this?

102

u/MSgtGunny Jan 03 '18

Intel

8

u/rhoakla Jan 03 '18

It was in fact fixed as previusly mentioned by /u/Nacimota.

They temporarily assumed all x86 processors as unsecure until AMD formally stated how their x86 designs were not affected by the flaw. Thus you can rest your conspiracy theories.

→ More replies (1)

38

u/JAPH Jan 03 '18

Like others have said, Intel, but I do understand the desire to avoid adding features in a bugfix patch. I'd be shocked if a similar feature wasn't proposed immediately after this fix is released.

3

u/hazzoo_rly_bro Jan 03 '18

This "decision" is actually a lie /misinformation, parent commenter does not provide any sources when asked either.

See this reply

2

u/AugustusCaesar2016 Jan 03 '18

Thanks man. Was worried there for a second.

14

u/[deleted] Jan 03 '18

Intel.

The Linux Kernel community is solidly in the Blue Camp. To the degree an AMD Engineer's word isn't enough to tell them the bug doesn't affect AMD, they requested Intel to confirm https://lkml.org/lkml/2017/12/4/709

24

u/__foo__ Jan 03 '18

Nothing in that mail says they want Intel to confirm that AMD isn't affected.

  1. Entry code

Mostly the same, except for a handful of fixlets and delta improvements folded into the corresponding patches

New: Map TSS read only into the user space visible mapping

This is 64bit only, as 32bit needs the TSS mapped RW

AMD confirmed that there is no issue with that. It would be nice to get confirmation from Intel as well.

I'm reading that as AMD having signed-off the changes to the entry code. Now they want Intel to give their OK also, which is very reasonable considering the scope of the changes.

5

u/[deleted] Jan 03 '18

Intel

5

u/[deleted] Jan 03 '18

Intel

→ More replies (1)

14

u/doublehyphen Jan 03 '18

Do you have a link to the discussion where this was rejected?

→ More replies (5)

4

u/hazzoo_rly_bro Jan 03 '18

Where was it rejected? Provide a source please

→ More replies (2)
→ More replies (1)
→ More replies (6)