| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Support
Forum: Suggestions / Feedback
Thread: Build Science Apps With Newer glibc or at least disable Virtual Syscalls [Linux] |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 14
|
|
| Author |
|
|
hchc
Veteran Cruncher USA Joined: Aug 15, 2006 Post Count: 746 Status: Offline Project Badges: 
|
From this post:
----------------------------------------daka said: I'm guessing none from the HST or SCC projects? You will probably get problems once you get one of them. They seem to be the project binaries currently compiled with glibc 2.13 or earlier. From the Debian kernel changelog for version 4.10: * [amd64] Enable LEGACY_VSYSCALL_NONE instead of LEGACY_VSYSCALL_EMULATE and from /usr/share/doc/linux-image-amd64/NEWS.Debian.gz * From Linux 4.10, the old 'virtual syscall' interface on 64-bit PCs In other words, on newer Linux kernels 4.10 or later, I'm having to use a workaround in GRUB to set "vsyscall=emulate" in order to run SCC1 and HSTB tasks. This weakens the overall security of the system. From the thread Smash Childhood Cancer Beta Test July 26, 2018 [Linux Only], uplinger said: We are conducting a beta test for Smash Childhood Cancer on the Linux platform only. The updated version of the application is 7.16. This version of the application does not include any code changes but has been built with GCC 4.85 and glibc 2.17. We will be running 10k work units. So SCC1 for Linux has been built with glibc 2.17 yet for some reason it's still requiring vsyscalls. Is there a way to disable vsyscalls when you're compiling SCC1 and HSTB?
[Edit 2 times, last edit by hchc at Oct 14, 2019 1:57:20 PM] |
||
|
|
hchc
Veteran Cruncher USA Joined: Aug 15, 2006 Post Count: 746 Status: Offline Project Badges:
|
The security implications of vsyscall=emulate:
----------------------------------------From the thread vsyscall is now disabled on latest Linux distros at the Einstein@home forums, UNIONJACK said: This is the help text from vsyscall=emulate in the kernel "make menuconfig": The kernel traps and emulates calls into the fixed vsyscall address mapping. This makes the mapping non-executable, but it still contains known contents, which could be used in certain rare security vulnerability exploits. This configuration is recommended when userspace still uses the vsyscall area. This is for vsyscall=native: Actual executable code is located in the fixed vsyscall address mapping, implementing time() efficiently. Since this makes the mapping executable, it can be used during security vulnerability exploitation (traditionally as ROP gadgets). This configuration is not recommended. And for vsyscall=none: There will be no vsyscall mapping at all. This will eliminate any risk of ASLR bypass due to the vsyscall fixed address mapping. Attempts to use the vsyscalls will be reported to dmesg, so that either old or malicious userspace programs can be identified.
|
||
|
|
hchc
Veteran Cruncher USA Joined: Aug 15, 2006 Post Count: 746 Status: Offline Project Badges:
|
Hello!
----------------------------------------I was wondering if building SCC1 and HSTB apps using the latest version of gcc for Linux is on the radar. I'm seeing a few people making posts or threads that they are getting Signal 11 (SIGSEGV) errors, and it's still a workaround at this point (and small security issue) for Linux users to modify grub to use legacy virtual syscall emulation. Thanks! I know y'all are busy with maintenance as well as launching OpenPandemics.
[Edit 2 times, last edit by hchc at Apr 20, 2020 10:08:58 PM] |
||
|
|
mihelm
Cruncher Joined: Jun 18, 2007 Post Count: 20 Status: Offline Project Badges: 
|
Hi!
I'm probably missing something, but I'm not having any issues running SCC1 and HSTB on my Linux boxes. Occasionally I see an error from ARP1, but there seems to be more of that going around. I run Ubuntu 18.04, with a kernel very much newer than 4.10. My glibc version is also newer than what you mention. Ubuntu isn't Debian, but it's pretty closely related... Cheers, michael. |
||
|
|
alanb1951
Veteran Cruncher Joined: Jan 20, 2006 Post Count: 858 Status: Offline Project Badges:
|
Hi! I'm probably missing something, but I'm not having any issues running SCC1 and HSTB on my Linux boxes. Occasionally I see an error from ARP1, but there seems to be more of that going around. I run Ubuntu 18.04, with a kernel very much newer than 4.10. My glibc version is also newer than what you mention. Ubuntu isn't Debian, but it's pretty closely related... Cheers, michael. Ubuntu has left the vsyscall emulation mechanism enabled (at least, it has in 18.04 which I run...) so 18.04 users using default setting are unlikely to see the same issues as, say, Debian Buster. So one could say we've been lucky on those projects that are still in need of newer binaries. At some point, Ubuntu will probably also completely pull the plug on vsyscall (let's see what 20.04 brings!) - then a new build of SCC1 (for instance) will become essential for Ubuntu users! The issue has been raised elsewhere recently, but I suspect that trying to get the new OPN project going will have pushed that way down the priority chain (which is fair enough, really) |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
No issue seen on Ubuntu 19.10 and CentOS 8....
----------------------------------------[Edit 1 times, last edit by Doneske at Apr 21, 2020 1:04:09 PM] |
||
|
|
hchc
Veteran Cruncher USA Joined: Aug 15, 2006 Post Count: 746 Status: Offline Project Badges:
|
End of May 2020 bump.
----------------------------------------Hello! I was wondering if building SCC1 and HSTB apps using the latest version of gcc for Linux is on the radar. I'm seeing a few people making posts or threads that they are getting Signal 11 (SIGSEGV) errors, and it's still a workaround at this point (and small security issue) for Linux users to modify grub to use legacy virtual syscall emulation. Thanks! I know y'all are busy with maintenance as well as launching OpenPandemics. Now that OPN1 has launched, can this be put on the radar? Once SCC1 and HSTB binaries are compiled for Linux with the latest version of GLIBC I can remove the vsyscall emulation workaround on my Linux boxes and improve overall system security. Thanks.
|
||
|
|
hchc
Veteran Cruncher USA Joined: Aug 15, 2006 Post Count: 746 Status: Offline Project Badges:
|
Bump. Can this pretty please be done before SCC work resumes? Looking at the link in the OP, uplinger said in July 2018:
----------------------------------------We are conducting a beta test for Smash Childhood Cancer on the Linux platform only. The updated version of the application is 7.16. This version of the application does not include any code changes but has been built with GCC 4.85 and glibc 2.17. We will be running 10k work units. but for some reason I don't believe this beta test was ever moved to production, as Linux SCC binaries are not on 7.16 and still require vsyscall emulation. The sooner that newer SCC and HSTB binaries are compiled, the sooner all WCG Linux clients can disable vsyscall emulation for better security. Is building new binaries with no code changes that much level of effort? I'm sure WCG volunteers would compile for free and be willing to sign a non-disclosure agreement.
[Edit 3 times, last edit by hchc at Jul 17, 2020 2:33:24 PM] |
||
|
|
hchc
Veteran Cruncher USA Joined: Aug 15, 2006 Post Count: 746 Status: Offline Project Badges:
|
Is there a reason why this is being ignored wholesale? I'd @mention, but this obsolete, ancient forum doesn't have @mentions. I'd PM, but there's no PM capability.
----------------------------------------There was a beta test in July 2018 to build SCC with a newer version of glibc... why is simply asking why that was never promoted to production a reason to ignore the question? Is the Level of Effort that mammoth to simply ignore Linux users? All that is being asked is new binaries for SCC and HSTB so that workarounds that weaken security no longer have to be put into place. I realize there's basic alpha and beta testing with a newer binary (even with no code changes), but good grief. This shouldn't take multiple years of neglect for SCC and HSTB. Before ARP1 launched, it was understandable that priorities were on launching the first of the 2-3 total climate projects. Before OPN1 (COVID19) launched, it was understandable that priorities were on launching OPN1 (COVID19). But now that both have launched, why is simply releasing new builds for two subprojects getting ignored? There's multiple threads of SIGSEGV (Signal 11) errors in the SCC and HSTB forums, and less technical users are getting frustrated and giving up. The workaround is to modify grub to emulate virtual syscalls, and that method is deprecated for security reasons.
[Edit 3 times, last edit by hchc at Jul 27, 2020 7:02:00 AM] |
||
|
|
uplinger
Former World Community Grid Tech Joined: May 23, 2005 Post Count: 3952 Status: Offline Project Badges: 
|
Hello hchc,
----------------------------------------Their are a few things that go into this. 1. The SCC1 beta that you referred to was done near the end of a set of targets. It was not promoted because there was weeks left of work at that time. Then when we ran more work, it was missed on the new targets. This was a mistake on my end. However, I have it on my list of things we are going to beta test when the new SCC1 target is released. Note: we have gotten a new target from the researchers and are going to alpha test them soon. In beta we will test the latest version of SCC1 binary again. 2. HST1 has very few results, recompiling the application, doing a full proper beta, etc is not high on the task board I'm afraid to say. A full proper beta for any application requires us to send results back to researchers for their review to make sure nothing went astray. Note: We have lots of things on our board still, we have GPU Autodock for OPN1, MCM1 application update, and a new climate project that we are working towards onboarding. [Edit] - Forgot to mention, we have many other tasks on our boards that are not directly connected to onboarding science applications. For example, I've been working on the backend to change our storage around. We have modifications that are needed to validators/assimilators that are needed. There was a bug found in the generation of OPN1 work units that caused work units to error out that could be fixed by changing the build scripts. All of these things are high priority. In what I just mentioned, those are only the high priority tasks associated with my board, and also providing level 3 support for members. I hope this helps give a bit of insight into what is happening on the backend. Thanks, -Uplinger [Edit 1 times, last edit by uplinger at Jul 28, 2020 1:53:47 PM] |
||
|
|
|