<beneroth>
ECC memory was presumed to be safe from rowhammer attack
<Regenaxer>
Hi beneroth
<beneroth>
Hi Regenaxer !
xkapastel has joined #picolisp
<aw->
hi all
<aw->
beneroth: does this work against arm64?
<Regenaxer>
Hi aw-
<aw->
initial rowhammer was only x86
freemint2 has joined #picolisp
<aw->
(and x86-64)
freemint has quit [Ping timeout: 250 seconds]
<beneroth>
aw-, I think we're already past this for a while now, no?
<beneroth>
in the paper they're targeting AMD opteron 6376
<aw->
?
<beneroth>
the big remaining obstacle was ECC and that there are multiple varying ECC algorithms in use, and the algorithms are proprietary
<aw->
past what?
<beneroth>
CPU mattering
<beneroth>
maybe I'm wrong or missed something. they list AMD opteron 6373 as a target system in their paper (beside 3 Intel CPUs)
<aw->
AMD != ARM
<beneroth>
ah right, sorry
<beneroth>
though x64 != amd64 architecture :P
<beneroth>
ah
<beneroth>
sorry I'm not fully functional
<aw->
i'm looking at the arm website and they are discussing the rowhammer issue, so maybe they are affected
<aw->
like back with the Spectre/Mitre issue, only certain arm64 cpus were affected, not all
<beneroth>
as I understood it, CPU is not a real obstacle, but the secret ECC algorithm in actual use is one. for the paper I linked they reversed engineered the ECC algorithms which are used.
<aw->
i can't keep up with all of this anymore
<beneroth>
yes, but Spectre is an attack on CPU cache
<aw->
"secret" algorithm, hah
<beneroth>
proprietary
<beneroth>
rowhammer is attack on RAM, flipping bits by making many writes/reads to a neighbouring memory bank
<beneroth>
its hard to see if your attack is working when ECC is correcting the bits on reading.
<beneroth>
so you need to flip the right bits to have some gain, and additionally you have to flip additional bits to satisfy the ECC code so it doesn't correct your manipulation, and you have do to it in a way which does not crash the target system.
<aw->
ok
<aw->
how is it exploited remotely?
<aw->
webgl again?
<beneroth>
aw-, yes in practice both Spectre and Rowhammer are a security issue for shared hosting. I wonder if it will affect cloud business.
<beneroth>
well rowhammer requires code running on the target machine.
<beneroth>
so.. cloud tenant? :)
<beneroth>
there was a rowhammer for javascript implementation, I don't know if they changed javascript standard to not make it functional anymore.
<beneroth>
(they did so for spectre, or so they think)
<aw->
i see
<beneroth>
the big issue I see with shared hosting (which includes cloud). one tenant using rowhammer (or spectre) to make privilege escalation attack to gain access to host and/or root, or to spy on another tenant or manipulate it
<aw->
yeah... i can see that being an issue for all the companies running services on cloud providers
<beneroth>
ARM would be interesting. because this attacks would allow to make an app which can attack the eBanking app on the same mobile :P
<aw->
yeah...
<beneroth>
but most eBanking providers exclude your phone if you root'ed it.. so its security theatre anyway, not real security they care about
<beneroth>
aw-, when I google for "ARM rowhammer" I get this paper from 2016 as first hit: rowhammer is attack on RAM,
<beneroth>
"Despite the fact that powerful cross-core cache attacks have been consid-
<beneroth>
ered not applicable [87] on smartphones, we showed the possibility of
<beneroth>
highly accurate attacks on ARM. "
<beneroth>
"In this thesis, we demonstrated that
<beneroth>
the cross-core cache attacks
<beneroth>
,
<beneroth>
Prime+Probe
<beneroth>
Flush+Reload
<beneroth>
,
<beneroth>
Evict+Reload
<beneroth>
and
<beneroth>
Flush+Flush
<beneroth>
can be performed on ARM-based devices."
<beneroth>
argh sorry
<beneroth>
PDF formatting goes not well with IRC it seems
<beneroth>
"Moreover, we showed that it is possible to monitor the cache activity
<beneroth>
of the ARM TrustZone from within the normal world."
<beneroth>
hm
<aw->
like i said, i can't keep up with this stuff
<aw->
mostly don't care anymore tbh
<beneroth>
well you don't have to keep up. you just have to know that shared hosting (software from multiple actors, maybe including malicious ones, on the same physical machine) is not absolutely secure
ubLIX has joined #picolisp
<beneroth>
so if you want to have something isolated, isolate it on physical level - have it running on its own machine.
<aw->
seems like every week there's a new thing that will cause the world to collapse
<beneroth>
not the world, just some big business models.
<aw->
i can't do anything about the things i can't control
<aw->
so why should i care?
<beneroth>
I think you can control if you run something on the cloud or on your own physical machine on premise
<aw->
i only use shared-hosting for html only websites
<aw->
and i have my own co-location servers here in Japan
<beneroth>
you traditionalist :)
<aw->
haven't "run something on the cloud" ever
<aw->
i've known about the "cloud" issues since the day the work was coined to represent "other people's servers"
<aw->
word* was coined
<beneroth>
it comes from visio.. the symbol painting program. "Internet" is usually pictured as a cloud symbol in such diagrams.
<aw->
yes i know
<aw->
it was supposed to represent "a mystical place where things happen which we don't know or care about"
<beneroth>
I'm using VPS root servers, so that is not exactly cloud, but its vulnerable to this attacks.
<beneroth>
well there is even now "server-less" computing, can you imagine? :D
<aw->
yes and it's stupid
<aw->
my company is 100% based on anti-cloud
<aw->
since day 1 we've always been promoting on-prem
<aw->
i'm the worst person to talk to about cloud stuff if you don't want to have your brain implode by my non-cloud propaganda haha
<beneroth>
I'm similar :)
<aw->
so i can re-iterate briefly: don't trust the cloud
<beneroth>
well I can see the value for SaaS applications with big variations in load, e.g. game servers.... but ... well its applied to many use-cases where it doesn't help (nor it is cheaper)... and I would not want to use it for something which should be "secure"
<beneroth>
cloud is similarly pronounced as german "geklaut" which means stolen :)
<Regenaxer>
I know what a differential equation is, but what are differentiable numbers then?
<Regenaxer>
You rather need fractions
<razzy>
and you need to be able to say (x/inf)+(y/inf)=(z/inf)
<razzy>
yes with implemented fractions
<Regenaxer>
Arithmetics with inf can easily be implemented with NIL and T
<Regenaxer>
See the checks above
<razzy>
hmm.
<Regenaxer>
You must check anyway
<Regenaxer>
and check for bools is easier than (if (= N 1000000000000000000000) ...
<Regenaxer>
and a lot cheaper
<razzy>
T
<razzy>
hm
<razzy>
stil not sure if just T will be sufficient in all cases
<razzy>
because you have loss of information with just T
<Regenaxer>
true, there are many kinds of infinite
<Regenaxer>
It all depends on the use case
<razzy>
if i need to know highest number, best would be function that search through all numbers, yes?
<Regenaxer>
The highest number currently in the heap?
<beneroth>
razzy, see (max)
<beneroth>
or (maxi)
<beneroth>
Regenaxer I recently missed (maxi) in C#, there is one returning the maximum value but none to return the element with the maximum value. their solution is List.OrderDescending.First() ^^
<beneroth>
ugly :)
<Regenaxer>
yeah
<razzy>
i was asking if there is no picolisp system variable
<Regenaxer>
You mean a variable maintained upon every arithmetic operation?
<razzy>
well yes :]
<Regenaxer>
Would be rather meaningless
<razzy>
yes
<Regenaxer>
Numbers are garbage quickly
<razzy>
T
<Regenaxer>
Anyway there is no such var
<razzy>
maybe picolisp archive maximum number of 60bit stacks used
<razzy>
for whatever purpose
<Regenaxer>
What means "archive" here?
<Regenaxer>
and "stacks"?
<beneroth>
you could build an FEXPR which uses (let) to locally bind custom versions of all arithmetic functions to maintain the extra variables you require for your special case :)
<razzy>
"i have used 3 60bit frames"
<beneroth>
what do you mean by "frame" ?
<beneroth>
^^
<razzy>
my vocabulary is limited
<beneroth>
I suspect to care too much about implementation detals which ought not matter.
<beneroth>
I suspect you care too much about implementation details which ought not matter.
<razzy>
ah, "maximum number of heap cells used in representing number "
<razzy>
yop, thx, out
<Regenaxer>
What would that max be?
<Regenaxer>
There is no "maximum number of heap cells used in representing number"
<Regenaxer>
can fill whole memory
<razzy>
yes
<Regenaxer>
ok, yes, the address space
<razzy>
maximum used per one number so far
<razzy>
forget it, not really important
<Regenaxer>
I see, to keep this maximum small?
<razzy>
for some purposes yes
<Regenaxer>
ok
<razzy>
could be variable that picolisp could care
<razzy>
if not, nevermind
<Regenaxer>
No, still too expensive
<razzy>
thx
<Regenaxer>
ok :)
rob_w has quit [Quit: Leaving]
lodsw has quit [Ping timeout: 250 seconds]
lodsw has joined #picolisp
orivej has joined #picolisp
lodsw has quit [Read error: Connection reset by peer]