After carefully studying all the very useful replies, and to order all the info I've gathered, I make here a fast resume of the knowledge I've achieved that has served to me as a satisfactory answer.
First of all I'm very grateful to @cort-ammon comment:
"The key concept is that no chip is obliged to precisely execute code according to the instructions. The obligation is instead that it must execute "as if" the code was precisely executed according to the instructions. All modern processors take advantage of this freedom."
This concept is really necessary in order to understand why all these CPU features (as Branch Target Prediction, Speculative Execution and so on) have been implemented in the first place - and why they remain as good (and now we know: as dangerous!) as ever.
Now as for the question:
- what would have prevented access to that zone of memory in a normal execution if the code would have try to do so explicitly?
Nothing (As @immibis & @gnasher729 pointed out!):
because this version of the Spectre vulnerability only allows to read data that the processor determines the process have access to.
There's no difference in the code from, for example, a read from a buffer overflow inside the same process memory space (See for example this code).
That is: the code indicated in the question is extracted from Variant 1: Bounds check bypass, in which the generic Proof of Concept (PoC) is shown.
This PoC is used then in various ways: in order to use the code in Variant 1 for attacking the kernel, access to an eBPF bytecode interpreter is necessary, so that "Unprivileged userspace code can supply bytecode to the kernel". This is the characteristic (!) behaviour of eBPF ("extended Berkeley Packet Filter", a programmable feature of linux kernels) that the attack make full use of: this way the attack pass inaltered to the kernel, where it can read memory positions that it shouldn't (they'll be out of its supossed reserved memory, but in the same process space) without triggering any alarm - and it wouldn't even if the code were examined by the eBPF compiler (and it is not), because no direct out-of-bounds memory read is made at all.
But the PoC can also be used in Variant 2: Branch target injection in which that, with other tricks, force the CPU to make directed jumps in mis-speculated execution of other processes in order to gain read access to arbitrary virtual memory locations.
This attack makes full use of the fact that the Branch Target Buffer (BTB) of some CPUs (at least Intel Haswell Xeon) only uses part of the full memory address to store branch prediction information. This is part of the fact that leads to the ability (attack) of one process to influence the Branch target predictor for another completely different process, thus bypassing userspace/kernel (and other) protections.
And now I understand where this partial memory address BTB fits in the answer that I pointed out to in my question, that stated that in order to protect a CPU from Spectre attacks:
"Branch predictor state must take the full address of the branch instruction into account (currently, to save space, only the low-order bits are used)." (@Mark)
As for the second question:
- wouldn't the checks (if the answer to the first question is that additional checks are needed) or that 'flushing' impact in performance? and if so, has it been estimated how much? (when those supposed CPUs would/will be made).
now that I'm aware of the internals of these attacks, and also of the internals of CPU optimizations (BTB, speculative exec...) the question seems to me less imperative: CPU designers will try to maintain the balance between performance and security... may be just that security was not in this balance before these attacks were made public (even though very promissing side-channel attacks were already known... but that's another story).
For example, as (again) @cort-ammon points:
"For example, I'm certain there's an Intel designer looking right now at whether the next generation CPUs can un-evict cache lines if a speculative read falls though to get them one step closer to "as if.""
Thanks again for all the answers.