On Wed, Feb 1, 2023, at 08:05, Jessica Clarke wrote:
> On 1 Feb 2023, at 06:31, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
>> On Mon, Jan 30, 2023 at 03:24:40PM +0000, Matthew Wilcox wrote:
>>
>>> Before we go too deeply into it, how much would it cost to buy all of
>>> these parts and feed them into a shredder? I'm not entirely joking;
>>> if it's less than the software engineering time it'd take to develop
>>> and support this feature, we should do it.
>>
>> The above suggests this is in no way an actual hardware problem, but the
>> stupid decision is done in the M-Mode firmware. I think it is very
>> reasonable to simply not support the devices in Linux until the firmware
>> is fixed.
>
> No, it really is a hardware spec violation. Virtual addresses within
> the magic range bypass translation with no way to turn it off. The
> firmware is being (has been?) patched to block those accesses at the
> physical memory protection level so any attempt to use those virtual
> addresses will fault, but if Linux wants to support this cursed
> hardware and its gross spec violation then it needs to forbid any
> allocation of the VA range.
For a local build of an embedded system it's probably enough to
set CONFIG_DEFAULT_MMAP_MIN_ADDR and CONFIG_LSM_MMAP_MIN_ADDR
in order to force userspace outside of the broken address
range.
If that configuration can no longer run most regular userspace
binaries, there is probably not much need to detect the hardware
that needs it and do this automatically in the kernel, beyond
perhaps some platform specific code that refuses to boot unless
the config options are set this way on the affected chip
revisions.
Arnd
