Is that me or there is an increase of critical security flaws over the last 5 years?
Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
371–380 of 567 posts
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#372Would the perf hits introduced by the Linux/Windows patches also be paid by kernels of guest VMs? or just the hosts/hypervisors?
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#373AMD must be pretty happy about this patch: https://lkml.org/lkml/2017/12/27/2
Not so sure about that. I am reading the merge commit, and comments are pretty interesting: --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h + * On Intel CPUs, if a SYSCALL instruction is at the highest canonical + * address, then that syscall will enter the kernel with a + * non-canonical return address, and SYSRET will explode dangerously. + * We avoid this particular problem by prevent…
That's an old issue, fixed many months ago, not related to the 'new' Intel bug. The comment was updated in this patch series, that's it.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#374Earlier quoted context omitted.
> So, every time either pages are touched/accessed this check needs to be triggered, which causes it to be much slower. Not to be mean, but that's not what is being changed. You're right on the bug - userlevel code can now read any memory regardless of privilege level. However the fix isn't to manually check the privileges on each access - that would be extremely slow and wouldn't actually fix the problem. The fix is…
But doesn't the CPU enter kernelspace every time a syscall takes place? So based on what you've described, every time a syscall returns control back to userspace, the TLB will be flushed, which means slower page access times in general.
The distinction I was trying to make was the above commenters thinking that the kernel is now checking page permissions instead of the CPU doing it - IE. Doing privileged checks in software. That's not what's happening, the kernel is just unmapping itself when usercode is run so the kernel can't be seen at all. Then the privileged checks (which are now broken) don't matter because there is no kernel memory to read.
All your points are right though. Page access times will in general be slower because of all the extra TLB flushes, leading to more TLB misses when accessing memory.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#375When pondering whether I should be grumpled about this situation or accept it as "just how it goes", I wonder if Intel would be OK with me giving them up to 30% less money after agreeing to 100% before walking out the Intel shop without prejudice.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#376Can someone help me understand why this is such a big deal? This doesn’t seem to be a flaw in the sense of the Pentium FDIV bug where the processor returned incorrect data. It doesn’t even seem to be a bug at all, but a side channel attack that would be almost expected in a processor with speculative execution unless special measures were taken to prevent it. And it doesn’t seem like it can be used for privilege esca…
If “reading secret data out of kernel memory” translates into “read the page cache from a stranger’s VM that happens to be on the same cloud server” then this could be worse than Heartbleed.
[deleted]
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#377Earlier quoted context omitted.
Reading secret data out of kernel memory is very bad on cloud environments. Keep in mind that the kernel deals with a lot of cryptography.
Is there anything this bug can give you that you can't get with sudo cat /dev/mem ? I'm having a hard time understanding why this is worse than any other local root escalation bug except for the consequences of the necessary patch. EDIT: I see that /dev/mem is no longer a window on all of physical RAM in a default secure configuration. Is it true that there's no way for root to read kernel memory in a typical Linux i…
We don't know what the actual bug is yet, or how easy it would be to exploit it. People are speculating that either:
a) It would allow any non-root process to read full memory, including the kernel and other processes, or
b) It would allow one cloud VM to read full memory of other cloud VMs on the same physical machine, or
c) With enough cleverness, it would allow even sandboxed Javascript on a web page to read full memory of the computer that it is running on.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#378"Intel has a bug that lets some software gain access to parts of a computer’s memory that are set aside to protect things like passwords." Seems like very little got through to the media about the details regarding this flaws effects and costly workaround.
Very little by way of details has been made public yet. Not even the technical press. Even relevant comments in the Linux source are redacted at the moment. Hopefully, further details will be released in good time (in the next month?) when people have had time to install the patches that are going out RealSoonNow (i.e. the huge plan of updates on Azure's VM hosts).
> Even relevant comments in the Linux source are redacted at the moment.
People keep repeating this claim because it sounds dramatic, but I'm not sure it's a fair description. The original source appears to be a single snide tweet from @grsecurity [1] referencing this comment [2].
It's far from obvious that the comment was even "redacted" at all. It seems more likely that "stay tuned" is either a reference to the more detailed comments elsewhere in the patch (in arch/x86/kernel/ldt.c), or a reflection of the fact (which is clearly spelled out in the commit message) that future patches are likely to change the location of the LDT mapping.
I've skimmed through the commit messages and comments from the latest patchset [3] and couldn't find anything else that even hinted at redaction, nor could I find any mention of redactions on the linux-kernel mailing list.
Furthermore, it's worth bearing in mind that @grsecurity has been involved in numerous public feuds with the Linux security folks. So in the absence of concrete evidence, I'm not particularly inclined to assume his tweet was made in good faith.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#379Considering the late Intel problems, Apple is going to be even more tempted to design its own CPUs/GPUs for the mac.
What do you think, is this realistic?
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#380Earlier quoted context omitted.
As a billion other people have already said, that all depends on their workloads. This isn't a 30% clockspeed deduction.
As i understand the problem, this isn't about clockspeed reduction, now it is the software's responsibility to check if the page is a kernel page/user page. So, the impact is significant. So, every time either pages are touched/accessed this check needs to be triggered, which causes it to be much slower.
You don't understand the problem.