Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Rowhammer intensifies

Name: Anonymous 2019-06-12 3:09

https://rambleed.com/
tl;dr now you can read data from ECC ram.

Name: Anonymous 2019-06-12 4:14

████████

Name: Anonymous 2019-06-12 8:15

>>2
IHBT

Name: Anonymous 2019-06-12 9:21

People live under the assumption hardware operation is always correct, but its like assuming DNA replicates flawlessly every time.

Name: Anonymous 2019-06-13 2:58

Dependent types would have prevented this.

Name: Anonymous 2019-06-13 7:19

>>5
how?

Name: Anonymous 2019-06-13 8:52

>>6
you're shitting me.

Name: Anonymous 2019-06-13 13:21

>>7
nah, not really into scat

Name: Anonymous 2019-06-14 5:05

>>6
By using them to prove that the hardware that you manufacture does not suck.

Name: Anonymous 2019-06-14 7:12

>>9
Wut
Unlike >>5, I've read CVE-2019-0174, shit's fucked by hardware level. You'll need to design quite physically slots for RAM programs cannot fuzz bits outside. Quite literally a new architecture model. RISCV doesn't even have an answer to this. I'm pissed off, just read the whole AI movement being abused by ECHELON to control and warfare win everything.
I'm at a point of suicide.

Name: Anonymous 2019-06-14 7:20

>>11
dubs would have prevented this
>>9
how do you use software verification methods to prove hardware? this isn't even something that hardware correctness proof would solve, given that it wouldn't even be covered by the assumptions

Name: Anonymous 2019-06-14 9:26

Could you formalize the whole hardware stack and then make high-level assertions about it, such as, a process cannot read physical memory not belonging to it?

Name: Anonymous 2019-06-14 9:34

>>12
theoretically you could, but you must remember that Rowhammer is not a design issue, it's a physics issue. at a logical level, the process cannot read the memory of other processes. in practice it can because of electromagnetic interference. good fucking luck formalizing electromagnetics with dependent types

Name: Anonymous 2019-06-14 9:52

Put everything in a vm.

Name: Anonymous 2019-06-14 10:59

>>6
https://en.wikichip.org/wiki/x86/sme

Name: Anonymous 2019-06-14 11:11

>>15
that has nothing to do with dependent types, anus

Name: Anonymous 2019-06-14 11:50

>>16
Dependent types are abstract enough to be relevant in domains your stub brain could not fathom.

Name: Anonymous 2019-06-14 12:15

>>16
you're shitting me?

Name: Anonymous 2019-06-14 13:02

>>10
Dependent types will be used to prove that your design is correct.

>>11
And you wouldn't understand. A shame, you seemed like an honest man.

Name: Anonymous 2019-06-14 13:09

>>19
it's 'and you don't seem to understand', anus

Name: Anonymous 2019-06-14 20:11

Anus man makes a blunder and fucking

Name: Anonymous 2019-06-14 20:12

dies

Name: Anonymous 2019-06-14 23:28

>>13
But that's not what CVE-2019-0174 is about. Simple process isolation to physically inaccessible RAM slots is enough to prevent this exploit. What you're describing is Faraday cages per slot, which is extremely doable with with proper isolation and two coils. But then the costs would skyrocket.
What academics and research labs are doing (Pentagon) are just DMZ networks, physically SSD hotswapping, no joke.
I'm pissed off the real cudder isn't exposing how much she actually knows&is involved. But I don't blame zher for being a kike.

Name: Cudder !cXCudderUE 2019-06-15 3:40

Don't run untrusted code or use the newer crappier error-prone RAM, problem solved.

All these increasingly inane "exploits" are nothing but more excuses for the authoritarian "security" fucktards to gradually lock down platforms so only the corporatocracy can control what the users do and think.

Pre-ME, pre-Rowhammer, pre-EFI/"secure" boot, pre-SGX hardware is currently cheap as rubbish but won't be if/when the sheeple awaken.

Name: Angry/prog/rider 2019-06-15 6:42

>>24
Fuck off. Any OS can easily be fuzzed to run untrusted code, BROP already proved that. Current architecture is flawed, an rethinking about how to isolate logic and memory addressing needs to be rethought. Harvard is utterly compromised.

Name: Anonymous 2019-06-17 4:57

>>25
>isolate logic and memory addressing
b-but my metaprogramming, my poor LISP!

Name: Anonymous 2019-06-17 6:05

>>26
There is no reason that prevents languages running on Harvard addressing schemes, LISP especially due its high-level nature.

Name: Anonymous 2019-06-17 6:38

>>24
How is your browser doing, Cudder-kun? I want to Surf The Web!

Name: Anonymous 2019-06-17 7:26

>>27
Lisp machines & their implementation are more vulnerable that metaprogramming means nothing to security.
>>28
Right? They probably are still on some Windows 98 machine on IE.
Ah 98, good year.
Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode + RSS -