Fixed
Status Update
No update yet.
Comments
le...@bollerup.org
Agree, Also teste PBi7 and on 3 other chromebooks.. some "older" onces becomes close to unuseable - futher more - Acording to Microsoft there is better ways to deal wth the security issue that causes less performance issues
eg...@azswa.org
Understanding there is a potential security risk - could the flag be returned with a more severe warning text? With crostini, many are using chromeos devices for development work, recommending chromeos devices to developer friends/colleagues, and are utilizing these machines for far more than web based tasks. Given that chromeos devices are shipping with low power processors, performance is already reduced compared to larger machines. Testing my device(c630 w/ i5) without hyper-threading resulted in a substantially slower experience, making development work utilizing multiple tools/processes very difficult. If one is informed enough to activate HT via a flag, hopefully they would be cognizant of any major new security threats discovered, including if any active threats were to be found utilizing the HT exploits.
ke...@gmail.com
There has to be another solution. If they do not want to find another way to circumvent the issue with intel chips, they need to let US decide to user hyperthreading. My pixelbook runs like molasses, and I will probably sell it if I can not use all 4 cores.
ta...@gmail.com
VS Code performance without hyperthreading on my i7 Pixelbook is noticeably slower. I moved from Windows to Chrome OS to have access to Linux for development work and Jupyter Notebook data analysis. It's extremely disappointing to give up reasonable performance for development work. I am willing to be subject to the hyperthreading security risks to have the performance improvement. Better yet would be to solve the security problem without having to disable hyperthreading.
za...@gmail.com
I get that it's a security vulnerability, my day job is security. However, I still believe that mitigated by default (So HT off) and then having the ability to turn it on if you want to is a decent middle ground. I'd love the ability to disable it across my entire org too in Enterprise, but allow it to be turned on if my personal threat model allows it.
dr...@gmail.com
re: https://www.chromium.org/chromium-os/mds-on-chromeos
"As of May 14th, 2019, Google is not aware of any active exploitation of the MDS vulnerabilities."
See also:https://www.google.com/about/appsecurity/
"We notify vendors of vulnerabilities immediately, with details shared in public with the defensive community after 90 days, or sooner if the vendor releases a fix. That deadline can vary in the following ways:"
paraphrasing this info:
- most vulnerabilities follow a 90 day disclosure schedule
- holidays can delay disclosure
- vendor-scheduled patches within the 14-day deadline can delay disclosure
- there is a 7-day deadline on zero day exploits
Perhaps this flag was removed for a good reason? Are we sure this is a bug? 6 months is a long time for a canary to not return.
"As of May 14th, 2019, Google is not aware of any active exploitation of the MDS vulnerabilities."
See also:
"We notify vendors of vulnerabilities immediately, with details shared in public with the defensive community after 90 days, or sooner if the vendor releases a fix. That deadline can vary in the following ways:"
paraphrasing this info:
- most vulnerabilities follow a 90 day disclosure schedule
- holidays can delay disclosure
- vendor-scheduled patches within the 14-day deadline can delay disclosure
- there is a 7-day deadline on zero day exploits
Perhaps this flag was removed for a good reason? Are we sure this is a bug? 6 months is a long time for a canary to not return.
dt...@chromium.org
[Empty comment from Monorail migration]
[Monorail components: OS>Systems>Settings]
[Monorail components: OS>Systems>Settings]
jh...@google.com
about:flags is not a part of OS Settings.
[Monorail components: -OS>Systems>Settings]
[Monorail components: -OS>Systems>Settings]
ze...@chromium.org
Looks like someone let the flag expire, but someone has already extended it. https://chromium-review.googlesource.com/c/chromium/src/+/1922547
Leaving it up to security team to figure out if if/where they need to backport to fill the gap on releases that contain the expired flag.
[Monorail components: Security]
Leaving it up to security team to figure out if if/where they need to backport to fill the gap on releases that contain the expired flag.
[Monorail components: Security]
dt...@chromium.org
mnissler@ can you triage this? Apparently it isn't OS>Systems>Settings
[Monorail components: OS>Kernel]
[Monorail components: OS>Kernel]
dt...@chromium.org
[Empty comment from Monorail migration]
jo...@google.com
This should be assigned to Greg.
jo...@google.com
Let's ask for merge to 79 since we probably want to intercept that one as soon as possible. Krishna, can we merge this to 79?
[Monorail components: -OS>Kernel]
[Monorail components: -OS>Kernel]
le...@bollerup.org
Big thank you to the team for taking care of this - for some of us are well aware of the security issues it might bring, performance is key!
On a user experience level - limiting the user - but still giving them an option to choose them-self - is what makes ChromeOS great.
On a user experience level - limiting the user - but still giving them an option to choose them-self - is what makes ChromeOS great.
sh...@chromium.org
This bug requires manual review: M79's targeted beta branch promotion date has already passed, so this requires manual review
Before a merge request will be considered, the following information is required to be added to this bug:
1. Does your merge fit within the Merge Decision Guidelines?
- Chrome:https://goto.google.com/chrome-release-branch-merge-guidelines
- Chrome OS:https://goto.google.com/cros-release-branch-merge-guidelines
2. Links to the CLs you are requesting to merge.
3. Has the change landed and been verified on master/ToT?
4. Why are these changes required in this milestone after branch?
5. Is this a new feature?
6. If it is a new feature, is it behind a flag using finch?
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Before a merge request will be considered, the following information is required to be added to this bug:
1. Does your merge fit within the Merge Decision Guidelines?
- Chrome:
- Chrome OS:
2. Links to the CLs you are requesting to merge.
3. Has the change landed and been verified on master/ToT?
4. Why are these changes required in this milestone after branch?
5. Is this a new feature?
6. If it is a new feature, is it behind a flag using finch?
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)
For more details visit
go...@chromium.org
This is for Chrome OS, please reach out cindyb@ (Chrome OS M79 TPM) for Chrome OS M79 merges. Thank you.
jo...@google.com
Gotcha, just pointing out that this is in Chrome code.
Cindy, thoughts?
Cindy, thoughts?
jo...@google.com
CL is https://chromium-review.googlesource.com/c/chromium/src/+/1922547 .
It's a change in a JSON file so it should be safe to merge.
It has landed in ToT and has been verified to work.
It does not require test.
It's a change in a JSON file so it should be safe to merge.
It has landed in ToT and has been verified to work.
It does not require test.
an...@delenda.co.uk
Currently running 79.0.3945.42 with Beta.
Not having this option destroys crostini for me. CrosVM gets stuck at 90% for 15 mins before settling at 30% when idle - with termina crashing when doing something as simple as an "apt update" within a container. Before this update, turning on hyperthreading was the only way I could do work with my pixelbook.
Not having this option destroys crostini for me. CrosVM gets stuck at 90% for 15 mins before settling at 30% when idle - with termina crashing when doing something as simple as an "apt update" within a container. Before this update, turning on hyperthreading was the only way I could do work with my pixelbook.
ci...@google.com
Thanks #19, merge approved M79 ChromeOS
ci...@google.com
[Empty comment from Monorail migration]
jo...@google.com
I think the only question left is whether a cherry-pick to 78 is in order.
wp...@gmail.com
#24 Was working for me on 78
jo...@google.com
In that case I'm going to mark this as fixed.
ri...@gmail.com
This bug should be reopened. I'm on chrome os 89 and the flag has expired once more.
jo...@chromium.org
Greg, does this flag need to be re-enabled?
ke...@chromium.org
Yes, let me figure out how to make it permanent.
ha...@google.com
[Empty comment from Monorail migration]
ri...@gmail.com
I believe this should be marked as fixed now
Description
Platform: 12607.34.0 (Official Build) beta-channel eve
Steps to reproduce the problem:
1. go to chrome://flags
2. look for #scheduler-configuration flag as documented here:
What is the expected behavior?
#scheduler-configuration flag is available and can be set to "Enables Hyper-Threading on relevant CPUs"
What went wrong?
Flag is not available and Hyper-Threading is disabled, causing a 33% performance drop.
Did this work before? Yes CrOS 78
Chrome version: 79.0.3945.42 Channel: beta
OS Version: 12607.34.0
Flash Version: n/a
The scheduler configuration flag is a documented way to mitigate the performance drop caused by disabling hyper-threading on Chrome OS. Without the flag, I have documented a 30-40% performance drop on my i7 PixelBooke, which is not acceptable to me. Can this flag be added back please?