<ekleog>
somedays I wonder why the stack isn't placed *below* the heap, then in the absence of memory vulnerability and of overflows there wouldn't be any way of saving stuff
<pie_>
its a meme
<ekleog>
gchristensen: systemd is the source of most of the CVEs I have to patch on my server, I think
<gchristensen>
systemd has incredible features to make software more secure by default
<pie_>
so, how could this vuln have been avoided with foresight?
<gchristensen>
also, systemd is a widely researched target
<ekleog>
well, I'm following oss-security, so it's not only not hearing about other ones
<pie_>
theo de raadt seems pretty caustic but he is very against additional attack surface and doesnt seem very wrong about it...though isolation features certanly are convenient
<ekleog>
it totally is, that's why I'm speaking in terms of source of CVEs I have to patch and not in terms of currently opened vulns
<gchristensen>
or unknown vulns
<ekleog>
I included unknown vulns in “currently opened vulns”, sorry if it wasn't clear (let's say I quite hope known vulns have a CVE and are announced on oss-sec, as I run only oss stuff on my server)
<ekleog>
oh wait maybe the linux kernel competes with systemd actually
<pie_>
ok id love to stay and have an honest chat but i need to force myself to sleep, ive managed to sleep properly for two days. maybe thisll help someone else feel better about the above too :P https://www.youtube.com/watch?v=c7VlkvW0Lio
<pie_>
i was serious about the foresight question though, im all about categorically fixing things
<gchristensen>
I don't know what large allocations really means, so I have no idea
<ekleog>
stack clash is basically “actually segmentation was nice, paging is meh”
<ekleog>
we'd need segregated address spaces to properly handle it
<ekleog>
but we don't have usable segregated address spaces since quite long, so the only solution is to probe everywhere, hence that gcc flag
<ekleog>
s/since/for/
<pie_>
ekleog, does riscv
LnL has quit [Ping timeout: 268 seconds]
<ekleog>
“large allocations” is basically “enough to jump from a stack address to a heap address”, which is something like from 0xc94d033c to 0x018f4260 on a quick test with `int main() { int a; printf("%016x %016x\n", &a, malloc(1)); }`
<ekleog>
(btw, about the 3G on my test, there are ways to reduce the allocation, that's more of a higher bound than a lower bound, and the case I'm considering is the simplest one for stack clash)
tilpner has quit [Ping timeout: 250 seconds]
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-security
labancle has joined #nixos-security
labancle has left #nixos-security ["ERC (IRC client for Emacs 25.2.2)"]
<gchristensen>
I don't believe so, IIRC it didn't build with that option at some point and we weren't able to fix it then
<gchristensen>
but, we could/should obviously yes do that
<pietranera>
maybe they can be turned on incrementally? E.g. with systemd-* stuff?... or when you say "it didn't build with that option" you are actually referring to systemd-*?
<fpletz>
I'm right now compiling on our hardware but if you got a juicy packet.net box, it would be faster :>
<fpletz>
hmm :)
<andi->
fpletz: on my way to a concert.. Earliest around 11pm or later
<gchristensen>
the c2.medium.x86 is pretty nice -- turbos to 3.0ghz
<fpletz>
hard to decide, but the epyc does indeed look nice
<fpletz>
yeah, the c2.medium.x86 would be awesome
<fpletz>
how long could we get that? I would use that for the gcc8 and hardening stuff, no more than a few days probably
<gchristensen>
let's go to PM for some details
<fpletz>
thanks!
Synthetica has joined #nixos-security
rain1 has joined #nixos-security
<fpletz>
andi-: awesome :)
<fpletz>
aszlig is also going to take a look
<pie_>
ekleog, re riscv iiuc that means you have hardware a hardware enforced memory range?
<pie_>
ekleog, that *sounds* sufficient
lassulus has joined #nixos-security
<ekleog>
pie_: the issue is that one hardware-enforced memory range is not enough (otherwise regular pagination does it too)
<ekleog>
you need a separate hardware-enforced memory range for at least the stack and the heap (and ideally one different per heap item but for that I know of no architecture that'd provide this)
<ekleog>
and not just “here are two ranges you can access”, you'd need to have each memory access be “I want address X in the stack”
<pie_>
ekleog, i mean i figured you could do that
<pie_>
two memory ranges that is
<pie_>
but ok im not very knoelwdgeable about this yet
<ekleog>
I didn't understand that (hear: the “I want address X in stack” that would check X is actually in the stack)and not in the heap even if the heap is accessible too) as possible from the short read I did
<ekleog>
but I may very well have missed the place where it's stated as possible :)
gchristensen is now known as c
c is now known as gchristensen
erictapen has joined #nixos-security
erictapen has quit [Ping timeout: 252 seconds]
<gchristensen>
fpletz: whats the word?
tilpner has quit [Ping timeout: 268 seconds]
labancle has left #nixos-security ["ERC (IRC client for Emacs 25.2.2)"]