Re:size_t-to-int vulnerability in Linux’s filesystem layer
by simias on Tuesday July 20, 2021 @01:27PM
(#27896599)
I assume they meant throwing an exception like divisions by zero usually do, i.e. a hardware trap.
I always thought that overflows should be checked in hardware, I suppose it's not a stretch to extend that to truncation. It's controversial though, and obviously mostly a thought experiment anyway unless we manage to convince some CPU manufacturer to extend their ISA that way.
MIPS does have (optional) trapping overflow on signed add/sub overflow, so at least there's a small precedent for it.
Re:size_t-to-int vulnerability in Linux’s filesystem layer
by ridiculous_fish on Tuesday July 20, 2021 @01:32PM
(#27896657)
Swift checks all arithmetic by default: https://swift.godbolt.org/z/rW614G5aq
It seems obvious that future Apple CPUs will have hardware support for this, if they don't already.
Re:size_t-to-int vulnerability in Linux’s filesystem layer
by saagarjha on Tuesday July 20, 2021 @04:59PM
(#27899243)
I don’t see this happening unless it makes it into the ARM ISA.
Re:size_t-to-int vulnerability in Linux’s filesystem layer
by gumby on Tuesday July 20, 2021 @05:04PM
(#27899305)
I don’t know the terms of Apple’s license with ARM, do you? I’m quite interested.
Given that Apple was one of the original founders of ARM it’s quite possible that their license allows much more latitude anyone else’s.
Re:size_t-to-int vulnerability in Linux’s filesystem layer
by saagarjha on Tuesday July 20, 2021 @06:05PM
(#27899962)
Adding new instructions to userspace programs is almost certainly not going to fly. All of their extensions have been hidden behind an opaque API, or limited to use in the kernel.
Re:size_t-to-int vulnerability in Linux’s filesystem layer
by masklinn on Wednesday July 21, 2021 @03:43AM
(#27903462)
That… makes no architectural difference at all. As far as the architecture is concerned, these are architectural extensions either way: userspace programs can observably contain and execute instructions which are not standard ARM.
If AMX is allowed under their license, there is no reason why checked extensions would not be.
Re:size_t-to-int vulnerability in Linux’s filesystem layer
by ridiculous_fish on Wednesday July 21, 2021 @02:46AM
(#27903048)
Apple benefits from compatibility with the ARM ecosystem, but there’s no downsides (from their perspective) from extending it. Their chips are “Apple Silicon”, setting the stage for forging ahead alone. I think it’s a card they hold in reserve, to be played when the time is right, like the Intel transition.
Re:size_t-to-int vulnerability in Linux’s filesystem layer
by hermitdev on Tuesday July 20, 2021 @06:00PM
(#27899930)
I'm not familiar with ARM ISA, but from the godbolt disassembly, it doesn't look like anything special going on here - just the ASM being generated. What's happening here is it just does the add, jumps on overflow flag set to an invalid opcode...
I know Erlang's BEAM VM has a "fail jump pointer register", where instructions that can fail have relative-jump offsets encoded as immediates for those instructions, and if the instruction "fails" in whatever semantic sense, it takes the jump.
But most CPUs don't have anything like that.
Would you want it to trap, like with integer division by zero?
CPU traps are pretty hard to handle in most language runtimes, such that most compilers generate runtime checks to work around them, rather than attempting to handle them.