Re: [QUERY]: Block region to mmap

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:
>>> Basically we are making use of the memory protection unit (MPU) so
>>> that only M-mode is allowed to access this region and S/U modes are
>>> blocked.
>> 
>> This sounds like RISC-V terminology.  I have no idea what M, S or U
>> modes are (Supervisor and User, I'd guess for the last two?)
> 
> 
> Yes, M = Machine, S = Supervisor, and U = User.
> M omde is the absolutele worst idea of RISC-V and basically a mix
> of microcode and super-SMM mode.
> 
>> 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.

This magic range also overlaps with the default base address used for
both GNU ld and LLVM LLD, for added entertainment, so almost every
position-dependent binary that exists in the world for RISC-V cannot be
run on this hardware. One could change that for future binaries, but
that doesn’t seem right to me... IMO this hardware is even more “not
RISC-V” than the D1 with its page table mess, but I don’t think we’ll
ever see RISC-V International come out and say that, so it’s up to the
open-source communities to decide what they want to support and what
they view as too much of a violation to be acceptable.

Jess






[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux