Does anyone still use Synth1?

[MuTools]

Is there a way to make it an option?

Not really. (except from the theoretic option to offer separate builds, which feels like overkill, waste of precious time, and possibly confusion)

Or, is this something that has to be set at compile time?

Yes.

When you say that it is "less secure", are you referring to the ability of someone to hack into my computer, or are you referring to the stability of the system somehow?

From what i read: Any app built with DYNAMICBASE:NO is more vulnerable to hacker exploits.

[mgiambro]

Now i'm left with a difficult dilemma: Should i choose to build MuLab with a less secure build setting to support a couple of old VST2 plugins?

I vote no.

[audiojunkie]

Now i'm left with a difficult dilemma: Should i choose to build MuLab with a less secure build setting to support a couple of old VST2 plugins?

I vote no.

Has anyone checked to see if a bridge such as patchworks, jbridge, etc., works? If things like that work, there is no need to worry about MuLab.

[syntonica]

If somebody wants to hack my system through an insecure plugin, they're welcome to try! The hard part is finding me with my music software even open.

[Cochrane]

Now i'm left with a difficult dilemma: Should i choose to build MuLab with a less secure build setting to support a couple of old VST2 plugins?

I vote YES!

[EvilDragon]

I agree with syntonica. All other hosts are also linking using this option and we don't really hear anyone got hacked through a DAW plugin. I vote YES, build with this option and move on.

[EvilDragon]

Has anyone checked to see if a bridge such as patchworks, jbridge, etc., works? If things like that work, there is no need to worry about MuLab.

I tried with Kush Element and Unify but that didn't work, it still crashed. Possibly because both rely on JUCE AudioPluginHost.

But this is the wrong way to look at it. It hampers the user experience having to use these workaround subhosts. I think that should be avoided.


I will conclude by saying that audio plugins are more concerned with performance, rather than security. This is why some older plugins (two which we know, but who knows how many more?) relied on hardcoded memory offsets.

I think it's a mistake not to support these oldies but goldies.

People who want to hack a thing will find a way to hack it regardless of how your build flags are set, Jo.

[EvilDragon]

This linker option does not affect stability, but it might have a slight impact on performance. It simply randomizes memory offsets used. Which is bad for programs which expect a certain thing to be at a certain exact memory offset.

Imagine, you load a plugin, it requests 2 MB of RAM. Host gives it to the plugin but since it's built with dynamicbase yes, plugin doesn't get a single contiguous block of memory, it gets memory from all over the address space. Therein lies the problem.

I think historically it was implied and expected that plugins would get a contiguous block of memory, and some plugins absolutely relied on that.

[audiojunkie]

Has anyone checked to see if a bridge such as patchworks, jbridge, etc., works? If things like that work, there is no need to worry about MuLab.

I tried with Kush Element and Unify but that didn't work, it still crashed. Possibly because both rely on JUCE AudioPluginHost.

But this is the wrong way to look at it. It hampers the user experience having to use these workaround subhosts. I think that should be avoided.


I will conclude by saying that audio plugins are more concerned with performance, rather than security. This is why some older plugins (two which we know, but who knows how many more?) relied on hardcoded memory offsets.

I think it's a mistake not to support these oldies but goldies.

People who want to hack a thing will find a way to hack it regardless of how your build flags are set, Jo.

I don't disagree with your reasoning at all.

[audiojunkie]

This linker option does not affect stability, but it might have a slight impact on performance. It simply randomizes memory offsets used. Which is bad for programs which expect a certain thing to be at a certain exact memory offset.

Imagine, you load a plugin, it requests 2 MB of RAM. Host gives it to the plugin but since it's built with dynamicbase yes, plugin doesn't get a single contiguous block of memory, it gets memory from all over the address space. Therein lies the problem.

I think historically it was implied and expected that plugins would get a contiguous block of memory, and some plugins absolutely relied on that.

I'll be running Mulab through WINE on my Linux box anyway, so I'm not worried about security with a plugin. Performance-wise, I would imagine that running through WINE would be a bigger performance hit than this linker option. How slight of an impact on performance are you suggesting?

[EvilDragon]

I think this build option probably doesn't have discernible impact with modern fast memory. 20 years ago (option was introduced with Windows Vista) it probably had a bit more impact. You're right in your assessment that you're likely losing more performance through the WINE layer.

[syntonica]

I think historically it was implied and expected that plugins would get a contiguous block of memory, and some plugins absolutely relied on that.

If I call for a memory allocation, I don't just expect it to be contiguous, I demand it. The whole concept of memory address translation by the OS just annoys me to no end. It interferes with my ability to go fast. I long for the days when stupid programming brought down the whole system. You learn proper memory management very quickly!

But yeah... Evil hackers. I hope they get reincarnated as abacuses.

[sl23]

Looking at both sides, I'm with Jo on this. Stick to the book, or it starts getting messy. When other plugins start failing, more hacks, then more, and it goes on, then you end up with a mess instead of a rock solid DAW. I really would love to find a solution, not just for this, but for Roland plugins too. Some old plugins are really good. But be honest, it's mostly nostalgia. I've let go of many and have around 10 old 32bit synths and 5 32bit FX vst's.

I have cut down all my collection to a mere 295 VST's so far, with around 40-50 of those being synths and only around twenty or so of the 295 are VST2, the rest have been replaced by VST3. I would prefer to use CLAP, but two reasons I don't:
1. I use NanoHost and SaviHost extensively for testing and trying VST's. Nothing like this exists for CLAP.
2. Few of those 295 VST's exist as CLAP versions.

I have around 100,000 presets for Sylenth1, many are likely similar to Synth1. But there are many things about Synth1 that makes it a good synth to use. I'm trying to emulate it as much as possible in a Mux preset, which is going ok, but I'm no expert. Many things aren't available though. This is probably the only VST2 synth I would keep. I even uninstalled V-Station, which was a great synth for it's time. Preset management is one of the main reasons for moving on.

[MuTools]

All other hosts are also linking using this option and we don't really hear anyone got hacked through a DAW plugin. I vote YES, build with this option and move on.

I will conclude by saying that audio plugins are more concerned with performance, rather than security. I think it's a mistake not to support these oldies but goldies.

I fully understand your pov.
But i think there are other povs too.
The security of the user's system may not be of big concern to many users, it can be (very) important to others.

People who want to hack a thing will find a way to hack it regardless of how your build flags are set, Jo.

Sure, no security method is 100% safe. That's a golden rule in any type of hardware/software security, in IT and outside IT, eg in securing a home. The thing about security is making it more difficult to break in. That's what security systems are about. That's what Microsoft intended with ASLR. I don't want to ignore that without proper thought, as i feel responsible for the user's system security. But i also fully understand the musical pov: Don't overthink this and compile with DYNAMICBASE:NO in favor of those plugins.

I need more time to reflect on this.

It definitely would be handy if there would be a wrapper plugin that can make abstraction of this aspect. That would solve the practical issue.

Imagine, you load a plugin, it requests 2 MB of RAM. Host gives it to the plugin but since it's built with dynamicbase yes, plugin doesn't get a single contiguous block of memory, it gets memory from all over the address space. Therein lies the problem.
I think historically it was implied and expected that plugins would get a contiguous block of memory, and some plugins absolutely relied on that.

I assume there is some misunderstanding somewhere but when you malloc a ram block, you do get a contiguous ram block. I think that the ASLR may impact the memory layout of global variables and maybe that's where Synth1/PG8X make false assumptions. Just a guess.

[oldcastle]

That's my concern too.

I'll be running Mulab through WINE on my Linux box anyway, so I'm not worried about security with a plugin. Performance-wise, I would imagine that running through WINE would be a bigger performance hit than this linker option. How slight of an impact on performance are you suggesting?