|
|
Subscribe / Log in / New account

Developers split over split-lock detection

Developers split over split-lock detection

Posted Dec 9, 2019 0:31 UTC (Mon) by Tov (subscriber, #61080)
In reply to: Developers split over split-lock detection by tux3
Parent article: Developers split over split-lock detection

So it might be a nice feature to be able to enable specifically on cloud servers. However, I am sure all desktop/laptop users with less than optimal firmware implementations and little chance of getting their firmware fixed will be thrilled by the thought of kernel panics starting to appear out of nowhere.

Furthermore people will have little sympathy of their trusty old applications suddenly being killed with SIGBUS errors due to some new standards of performance and "correctness".

Hopefully I am misunderstanding how this is supposed to work...


to post comments

Developers split over split-lock detection

Posted Dec 9, 2019 3:20 UTC (Mon) by hmh (subscriber, #3838) [Link] (3 responses)

I foresee it getting reverted about one week after it gets exposed to a wide range of users, unless it is optional. It is almost certain that enough embedded crapware (aka firmware) and x86-only commercial applications out there will trigger split locking.

Not to mention truly ancient stuff that runs under DOSEMU and friends...

So, I bet one will be able to disable this "feature" in its final form during boot, if not at any time...

Developers split over split-lock detection

Posted Dec 9, 2019 11:37 UTC (Mon) by pbonzini (subscriber, #60935) [Link]

Truly ancient stuff is not going to use locked instructions at all (except perhaps XCHG which got an automatic LOCK prefix with the 386, but even that is quite unlikely)

Developers split over split-lock detection

Posted Dec 9, 2019 12:07 UTC (Mon) by smooth1x (guest, #25322) [Link] (1 responses)

It would have to be optional as not every environment will be capabale of being 100% clean.

I would expect distributions to either have this turned off on Desktop installs or have their installer have a blacklist for firmware versions.

However for commercial environments would they not test first?

Surely all commercial environments are agile pipeline driven environments who break early and can fix things instantly? :->>

Developers split over split-lock detection

Posted Dec 12, 2019 16:03 UTC (Thu) by dps (guest, #5725) [Link]

A lot of commercial environments are agile but many of them build up vast piles of low priority bugs which never get fixed. In many agile environments is hard to fix code which sorts vast buffers with bubble sort because the code works. Customers can't see the source code and therefore won't be aware of this problem.

Tasks like fixing spelling mistakes, especially those in comments, become almost impossible.

The only way agile environments will be made to fix split locks is for them to cause something very bad to happen somewhere they care about. A demonstration that an allegedly safe interface to root allowed anybody to read /etc/shadow was required to get time to fix it.

As you might expect no customers where told anything and no fix issued. I will neither confirm nor deny any suggestions about the company or product involved.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds