| 1 |
Sorry Mick, that was directed at the original poster of this disinformation. Not sorry about the venom for the original corporate whore. |
| 2 |
|
| 3 |
mad.scientist.at.large (a good madscientist) |
| 4 |
-- |
| 5 |
God bless the rich, the greedy and the corrupt politicians they have put into office. God bless them for helping me do the right thing by giving the rich my little pile of cash. After all, the rich know what to do with money. |
| 6 |
|
| 7 |
|
| 8 |
13. Feb 2018 14:50 by mad.scientist.at.large@××××××××.com: |
| 9 |
|
| 10 |
|
| 11 |
> That is specious reasoning at best. The jit option requires that you allow mixed instructions/data in memory, which leaves you open to a lot more than spectre. The problem is you've (Red Hat) sold people a bill of goods with java jit, the solution is for people to write proper code and corporations to not tolerate bad code that ignores everything that's been learned about security. |
| 12 |
> |
| 13 |
> Besides, there's no reason to think, particularly given it's sloppy, sloppy coding that the jit option has fewer security holes in general. |
| 14 |
> |
| 15 |
> This is the same type of CRAP that has led to systemD (for Dumb Ass) and other bloat wear like gnome3. If i wanted bad security, unreliability, bloatware and the destruction of the illusion of "high speed data processing" i'd use winblows. |
| 16 |
> |
| 17 |
> seriously, can we try to keep these corporate schills the hell off the list? |
| 18 |
> |
| 19 |
> Yes, i hate red hat, google, chrome, and now firefox. |
| 20 |
> |
| 21 |
> It's not so much that we've produced a generation of bad coders who don't know better, the problem is no one cares about anything other than $$$ in america any more. I'm ashamed of my fellow "citizens". |
| 22 |
> |
| 23 |
> If you are going to blatently lie and obfuscate please do it on fox news! |
| 24 |
> |
| 25 |
> mad.scientist.at.large (a good madscientist) |
| 26 |
> -- |
| 27 |
> God bless the rich, the greedy and the corrupt politicians they have put into office. God bless them for helping me do the right thing by giving the rich my little pile of cash. After all, the rich know what to do with money. |
| 28 |
> |
| 29 |
> |
| 30 |
> 13. Feb 2018 02:48 by > michaelkintzios@×××××.com> : |
| 31 |
> |
| 32 |
> |
| 33 |
>> On Tuesday, 13 February 2018 02:18:33 GMT Nikos Chantziaras wrote: |
| 34 |
>>> On 13/02/18 03:31, Ian Zimmerman wrote: |
| 35 |
>>> > On 2018-02-13 03:13, Nikos Chantziaras wrote: |
| 36 |
>>> >> Apparently, and contrary to what people (me included) wrote here in |
| 37 |
>>> >> the past, BPF JIT is the secure option, and the interpreter is the |
| 38 |
>>> >> insecure one. |
| 39 |
>>> > |
| 40 |
>>> > Do you have a reference for this? It sounds strange indeed. |
| 41 |
>>> |
| 42 |
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i |
| 43 |
>>> d=290af86629b25ffd1ed6232c4e9107da031705cb |
| 44 |
>>> |
| 45 |
>>> "The BPF interpreter has been used as part of the spectre 2 attack |
| 46 |
>>> CVE-2017-5715. |
| 47 |
>>> [...] |
| 48 |
>>> To make attacker job harder introduce BPF_JIT_ALWAYS_ON config |
| 49 |
>>> option that removes interpreter from the kernel in favor of JIT-only mode." |
| 50 |
>> |
| 51 |
>> Thanks for sharing this Nikos. |
| 52 |
>> |
| 53 |
>> Perhaps I'm reading the referenced post wrong. If the BPF interpreter has |
| 54 |
>> been used for spectre2, then disabling CONFIG_BPF_SYSCALL does away with it |
| 55 |
>> altogether, rather than turning it on and then setting BPF_JIT_ALWAYS_ON to |
| 56 |
>> guard against its inherent vulnerability by using JIT-only mode? Is there |
| 57 |
>> some overriding benefit of having BPF enabled at all in the first place? |
| 58 |
>> |
| 59 |
>> PS. I don't remotely assume I properly understand the BPF mechanism, I just |
| 60 |
>> want to test my understanding above. |
| 61 |
>> -- |
| 62 |
>> Regards, |
| 63 |
>> Mick |
Archives