4 ms·
Auxiliary values are a part of the ELF specification. Did you compare older versions of OpenSSL against the kernels that were contemporary to their release dat
by akira2501 2y ago
Auxiliary values are a part of the ELF specification.
Did you compare older versions of OpenSSL against the kernels that were contemporary to their release dates?
And I read the LKML thread. In particular, I don't agree with statement 2, which seems to boil down to "it's harder to get right on VMs, and one time we forgot we had to special case hibernation, so that serves as justification for the vDSO."
The notion seemingly being "we want to make it easy to write carefree cryptographically secure code all managed by the kernel." I think you can have two of those three but probably not all three at once. What end state are we actually trying to create here?
- dale_glass 2y agoI don't see what the big deal is here? Why fight so much over such a tiny patch? To me this all seems like a no-brainer. A performant way to do a security-critical thing with less footguns, using an already existing mechanism.
- akira2501 2y agoI don't see what's making you interpret this as a "big deal" or a "fight." This is Hacker News on a Saturday. I'm offering some really light and off the cuff analysis over what may potentially be a bad feature. I would not consider the kernel's internal entropy management a way to find "less foot guns." I don't think I'm the only one who feels this way, in particular, I think it's telling that the only way to form a cogent argument around this feature is by invoking VMs with bad vendor state management facilities. Anyways.. I felt like commenting because this generally feels like the "worse is actually better" trend in kernel development that's become en vogue lately. I personally, just don't like it, and I thought this was a forum where I could just basically say that, without someone feeling confronted by it.
- dale_glass 2y ago> I don't see what's making you interpret this as a "big deal" or a "fight." I meant the general amount of discussion about it, including here, LWN and LKML > I'm offering some really light and off the cuff analysis over what may potentially be a bad feature. In what way could it be bad? I can only see it as a bit more complexity than needed, perhaps. > I would not consider the kernel's internal entropy management a way to find "less foot guns." Why not? The kernel is the ultimate arbiter of everything and the best place to have an accurate view. Userspace is at the mercy of the kernel, so it can't be as good. > I think it's telling that the only way to form a cogent argument around this feature is by invoking VMs with bad vendor state management facilities. That's what I mean by less footguns: a solution where userspace code can be written in a straightforward manner and not worry that everything might have changed underneath is less likely to go wrong. > I felt like commenting because this generally feels like the "worse is actually better" trend in kernel development that's become en vogue lately. What do you see as "worse"? It's faster, and it's less troublesome. Win/Win as far as I can see.
- johnisgood 2y agoWell, I would have never considered to use getauxval() for the purposes mentioned and I have not seen it used either, so thank you for mentioning it.
- fanf2 2y agoAuxiliary values are part of ELF, but it only specifies the layout in memory. ELF doesn’t specify a header that defines the AT_… values and some systems don’t even spell them with that prefix.
- djbusby 2y ago> What end state are we actually trying to create here? Getting sufficiently random bits (perhaps crypto) in a portable and fast way.