2018-07-31 11:39:26 +00:00
|
|
|
# SPDX-License-Identifier: GPL-2.0
|
|
|
|
|
|
2018-07-31 11:39:27 +00:00
|
|
|
menu "UML-specific options"
|
|
|
|
|
|
|
|
|
|
config UML
|
|
|
|
|
bool
|
|
|
|
|
default y
|
2023-06-13 23:39:36 +00:00
|
|
|
select ARCH_HAS_CPU_FINALIZE_INIT
|
2022-02-10 00:32:24 +00:00
|
|
|
select ARCH_HAS_FORTIFY_SOURCE
|
2022-04-14 10:34:51 +00:00
|
|
|
select ARCH_HAS_GCOV_PROFILE_ALL
|
2018-07-31 11:39:27 +00:00
|
|
|
select ARCH_HAS_KCOV
|
2021-05-17 07:22:34 +00:00
|
|
|
select ARCH_HAS_STRNCPY_FROM_USER
|
|
|
|
|
select ARCH_HAS_STRNLEN_USER
|
2024-07-02 08:25:50 +00:00
|
|
|
select ARCH_NO_PREEMPT_DYNAMIC
|
2018-07-31 11:39:27 +00:00
|
|
|
select HAVE_ARCH_AUDITSYSCALL
|
UML: add support for KASAN under x86_64
Make KASAN run on User Mode Linux on x86_64.
The UML-specific KASAN initializer uses mmap to map the ~16TB of shadow
memory to the location defined by KASAN_SHADOW_OFFSET. kasan_init()
utilizes constructors to initialize KASAN before main().
The location of the KASAN shadow memory, starting at
KASAN_SHADOW_OFFSET, can be configured using the KASAN_SHADOW_OFFSET
option. The default location of this offset is 0x100000000000, which
keeps it out-of-the-way even on UML setups with more "physical" memory.
For low-memory setups, 0x7fff8000 can be used instead, which fits in an
immediate and is therefore faster, as suggested by Dmitry Vyukov. There
is usually enough free space at this location; however, it is a config
option so that it can be easily changed if needed.
Note that, unlike KASAN on other architectures, vmalloc allocations
still use the shadow memory allocated upfront, rather than allocating
and free-ing it per-vmalloc allocation.
If another architecture chooses to go down the same path, we should
replace the checks for CONFIG_UML with something more generic, such
as:
- A CONFIG_KASAN_NO_SHADOW_ALLOC option, which architectures could set
- or, a way of having architecture-specific versions of these vmalloc
and module shadow memory allocation options.
Also note that, while UML supports both KASAN in inline mode
(CONFIG_KASAN_INLINE) and static linking (CONFIG_STATIC_LINK), it does
not support both at the same time.
Signed-off-by: Patricia Alfonso <trishalfonso@google.com>
Co-developed-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Signed-off-by: David Gow <davidgow@google.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2022-07-01 09:16:20 +00:00
|
|
|
select HAVE_ARCH_KASAN if X86_64
|
|
|
|
|
select HAVE_ARCH_KASAN_VMALLOC if HAVE_ARCH_KASAN
|
2018-07-31 11:39:27 +00:00
|
|
|
select HAVE_ARCH_SECCOMP_FILTER
|
2019-08-19 05:54:20 +00:00
|
|
|
select HAVE_ASM_MODVERSIONS
|
2018-07-31 11:39:27 +00:00
|
|
|
select HAVE_UID16
|
|
|
|
|
select HAVE_DEBUG_KMEMLEAK
|
2018-10-30 11:58:10 +00:00
|
|
|
select HAVE_DEBUG_BUGVERBOSE
|
2024-02-26 16:14:13 +00:00
|
|
|
select HAVE_PAGE_SIZE_4KB
|
um: add PCI over virtio emulation driver
To support testing of PCI/PCIe drivers in UML, add a PCI bus
support driver. This driver uses virtio, which in UML is really
just vhost-user, to talk to devices, and adds the devices to
the virtual PCI bus in the system.
Since virtio already allows DMA/bus mastering this really isn't
all that hard, of course we need the logic_iomem infrastructure
that was added by a previous patch.
The protocol to talk to the device is has a few fairly simple
messages for reading to/writing from config and IO spaces, and
messages for the device to send the various interrupts (INT#,
MSI/MSI-X and while suspended PME#).
Note that currently no offical virtio device ID is assigned for
this protocol, as a consequence this patch requires defining it
in the Kconfig, with a default that makes the driver refuse to
work at all.
Finally, in order to add support for MSI/MSI-X interrupts, some
small changes are needed in the UML IRQ code, it needs to have
more interrupts, changing NR_IRQS from 64 to 128 if this driver
is enabled, but not actually use them for anything so that the
generic IRQ domain/MSI infrastructure can allocate IRQ numbers.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2021-03-05 12:19:58 +00:00
|
|
|
select NO_DMA if !UML_DMA_EMULATION
|
2021-12-08 15:11:23 +00:00
|
|
|
select OF_EARLY_FLATTREE if OF
|
2018-07-31 11:39:27 +00:00
|
|
|
select GENERIC_IRQ_SHOW
|
|
|
|
|
select GENERIC_CPU_DEVICES
|
|
|
|
|
select HAVE_GCC_PLUGINS
|
2023-01-13 17:03:00 +00:00
|
|
|
select ARCH_SUPPORTS_LTO_CLANG
|
|
|
|
|
select ARCH_SUPPORTS_LTO_CLANG_THIN
|
2021-07-31 05:22:32 +00:00
|
|
|
select TRACE_IRQFLAGS_SUPPORT
|
2018-07-31 11:39:27 +00:00
|
|
|
select TTY # Needed for line.c
|
2021-08-11 14:58:26 +00:00
|
|
|
select HAVE_ARCH_VMAP_STACK
|
arch: um: rust: Add i386 support for Rust
At present, Rust in the kernel only supports 64-bit x86, so UML has
followed suit. However, it's significantly easier to support 32-bit i386
on UML than on bare metal, as UML does not use the -mregparm option
(which alters the ABI), which is not yet supported by rustc[1].
Add support for CONFIG_RUST on um/i386, by adding a new target config to
generate_rust_target, and replacing various checks on CONFIG_X86_64 to
also support CONFIG_X86_32.
We still use generate_rust_target, rather than a built-in rustc target,
in order to match x86_64, provide a future place for -mregparm, and more
easily disable floating point instructions.
With these changes, the KUnit tests pass with:
kunit.py run --make_options LLVM=1 --kconfig_add CONFIG_RUST=y
--kconfig_add CONFIG_64BIT=n --kconfig_add CONFIG_FORTIFY_SOURCE=n
An earlier version of these changes was proposed on the Rust-for-Linux
github[2].
[1]: https://github.com/rust-lang/rust/issues/116972
[2]: https://github.com/Rust-for-Linux/linux/pull/966
Signed-off-by: David Gow <davidgow@google.com>
Link: https://patch.msgid.link/20240604224052.3138504-1-davidgow@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-06-04 22:40:50 +00:00
|
|
|
select HAVE_RUST
|
2024-07-01 20:00:35 +00:00
|
|
|
select ARCH_HAS_UBSAN
|
2018-07-31 11:39:27 +00:00
|
|
|
|
|
|
|
|
config MMU
|
|
|
|
|
bool
|
|
|
|
|
default y
|
|
|
|
|
|
um: add PCI over virtio emulation driver
To support testing of PCI/PCIe drivers in UML, add a PCI bus
support driver. This driver uses virtio, which in UML is really
just vhost-user, to talk to devices, and adds the devices to
the virtual PCI bus in the system.
Since virtio already allows DMA/bus mastering this really isn't
all that hard, of course we need the logic_iomem infrastructure
that was added by a previous patch.
The protocol to talk to the device is has a few fairly simple
messages for reading to/writing from config and IO spaces, and
messages for the device to send the various interrupts (INT#,
MSI/MSI-X and while suspended PME#).
Note that currently no offical virtio device ID is assigned for
this protocol, as a consequence this patch requires defining it
in the Kconfig, with a default that makes the driver refuse to
work at all.
Finally, in order to add support for MSI/MSI-X interrupts, some
small changes are needed in the UML IRQ code, it needs to have
more interrupts, changing NR_IRQS from 64 to 128 if this driver
is enabled, but not actually use them for anything so that the
generic IRQ domain/MSI infrastructure can allocate IRQ numbers.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2021-03-05 12:19:58 +00:00
|
|
|
config UML_DMA_EMULATION
|
|
|
|
|
bool
|
|
|
|
|
|
2018-07-31 11:39:27 +00:00
|
|
|
config NO_IOMEM
|
2021-03-05 12:19:51 +00:00
|
|
|
bool "disable IOMEM" if EXPERT
|
um: add PCI over virtio emulation driver
To support testing of PCI/PCIe drivers in UML, add a PCI bus
support driver. This driver uses virtio, which in UML is really
just vhost-user, to talk to devices, and adds the devices to
the virtual PCI bus in the system.
Since virtio already allows DMA/bus mastering this really isn't
all that hard, of course we need the logic_iomem infrastructure
that was added by a previous patch.
The protocol to talk to the device is has a few fairly simple
messages for reading to/writing from config and IO spaces, and
messages for the device to send the various interrupts (INT#,
MSI/MSI-X and while suspended PME#).
Note that currently no offical virtio device ID is assigned for
this protocol, as a consequence this patch requires defining it
in the Kconfig, with a default that makes the driver refuse to
work at all.
Finally, in order to add support for MSI/MSI-X interrupts, some
small changes are needed in the UML IRQ code, it needs to have
more interrupts, changing NR_IRQS from 64 to 128 if this driver
is enabled, but not actually use them for anything so that the
generic IRQ domain/MSI infrastructure can allocate IRQ numbers.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2021-03-05 12:19:58 +00:00
|
|
|
depends on !INDIRECT_IOMEM
|
2021-03-05 12:19:51 +00:00
|
|
|
default y
|
|
|
|
|
|
um: add PCI over virtio emulation driver
To support testing of PCI/PCIe drivers in UML, add a PCI bus
support driver. This driver uses virtio, which in UML is really
just vhost-user, to talk to devices, and adds the devices to
the virtual PCI bus in the system.
Since virtio already allows DMA/bus mastering this really isn't
all that hard, of course we need the logic_iomem infrastructure
that was added by a previous patch.
The protocol to talk to the device is has a few fairly simple
messages for reading to/writing from config and IO spaces, and
messages for the device to send the various interrupts (INT#,
MSI/MSI-X and while suspended PME#).
Note that currently no offical virtio device ID is assigned for
this protocol, as a consequence this patch requires defining it
in the Kconfig, with a default that makes the driver refuse to
work at all.
Finally, in order to add support for MSI/MSI-X interrupts, some
small changes are needed in the UML IRQ code, it needs to have
more interrupts, changing NR_IRQS from 64 to 128 if this driver
is enabled, but not actually use them for anything so that the
generic IRQ domain/MSI infrastructure can allocate IRQ numbers.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2021-03-05 12:19:58 +00:00
|
|
|
config UML_IOMEM_EMULATION
|
|
|
|
|
bool
|
|
|
|
|
select INDIRECT_IOMEM
|
2024-04-03 12:43:00 +00:00
|
|
|
select HAS_IOPORT
|
um: add PCI over virtio emulation driver
To support testing of PCI/PCIe drivers in UML, add a PCI bus
support driver. This driver uses virtio, which in UML is really
just vhost-user, to talk to devices, and adds the devices to
the virtual PCI bus in the system.
Since virtio already allows DMA/bus mastering this really isn't
all that hard, of course we need the logic_iomem infrastructure
that was added by a previous patch.
The protocol to talk to the device is has a few fairly simple
messages for reading to/writing from config and IO spaces, and
messages for the device to send the various interrupts (INT#,
MSI/MSI-X and while suspended PME#).
Note that currently no offical virtio device ID is assigned for
this protocol, as a consequence this patch requires defining it
in the Kconfig, with a default that makes the driver refuse to
work at all.
Finally, in order to add support for MSI/MSI-X interrupts, some
small changes are needed in the UML IRQ code, it needs to have
more interrupts, changing NR_IRQS from 64 to 128 if this driver
is enabled, but not actually use them for anything so that the
generic IRQ domain/MSI infrastructure can allocate IRQ numbers.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2021-03-05 12:19:58 +00:00
|
|
|
select GENERIC_PCI_IOMAP
|
|
|
|
|
select GENERIC_IOMAP
|
|
|
|
|
select NO_GENERIC_PCI_IOPORT_MAP
|
|
|
|
|
|
2021-03-05 12:19:51 +00:00
|
|
|
config NO_IOPORT_MAP
|
2024-04-03 12:43:00 +00:00
|
|
|
def_bool !UML_IOMEM_EMULATION
|
2018-07-31 11:39:27 +00:00
|
|
|
|
|
|
|
|
config ISA
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config SBUS
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config LOCKDEP_SUPPORT
|
|
|
|
|
bool
|
|
|
|
|
default y
|
|
|
|
|
|
|
|
|
|
config STACKTRACE_SUPPORT
|
|
|
|
|
bool
|
|
|
|
|
default y
|
|
|
|
|
select STACKTRACE
|
|
|
|
|
|
|
|
|
|
config GENERIC_CALIBRATE_DELAY
|
|
|
|
|
bool
|
|
|
|
|
default y
|
|
|
|
|
|
|
|
|
|
config HZ
|
|
|
|
|
int
|
|
|
|
|
default 100
|
|
|
|
|
|
|
|
|
|
config NR_CPUS
|
|
|
|
|
int
|
|
|
|
|
range 1 1
|
|
|
|
|
default 1
|
|
|
|
|
|
2021-03-12 15:16:07 +00:00
|
|
|
config ARCH_HAS_CACHE_LINE_SIZE
|
|
|
|
|
def_bool y
|
|
|
|
|
|
2018-07-31 11:39:26 +00:00
|
|
|
source "arch/$(HEADER_ARCH)/um/Kconfig"
|
2018-07-31 11:39:27 +00:00
|
|
|
|
2020-07-19 21:02:22 +00:00
|
|
|
config MAY_HAVE_RUNTIME_DEPS
|
2022-05-25 12:50:00 +00:00
|
|
|
bool
|
2020-01-24 22:14:01 +00:00
|
|
|
|
2018-07-31 11:39:27 +00:00
|
|
|
config STATIC_LINK
|
|
|
|
|
bool "Force a static link"
|
2020-07-19 21:02:22 +00:00
|
|
|
depends on CC_CAN_LINK_STATIC_NO_RUNTIME_DEPS || !MAY_HAVE_RUNTIME_DEPS
|
2018-07-31 11:39:27 +00:00
|
|
|
help
|
|
|
|
|
This option gives you the ability to force a static link of UML.
|
|
|
|
|
Normally, UML is linked as a shared binary. This is inconvenient for
|
|
|
|
|
use in a chroot jail. So, if you intend to run UML inside a chroot,
|
|
|
|
|
you probably want to say Y here.
|
|
|
|
|
Additionally, this option enables using higher memory spaces (up to
|
|
|
|
|
2.75G) for UML.
|
|
|
|
|
|
2020-01-24 22:14:01 +00:00
|
|
|
NOTE: This option is incompatible with some networking features which
|
|
|
|
|
depend on features that require being dynamically loaded (like NSS).
|
|
|
|
|
|
2018-07-31 11:39:27 +00:00
|
|
|
config LD_SCRIPT_STATIC
|
|
|
|
|
bool
|
|
|
|
|
default y
|
|
|
|
|
depends on STATIC_LINK
|
|
|
|
|
|
|
|
|
|
config LD_SCRIPT_DYN
|
|
|
|
|
bool
|
|
|
|
|
default y
|
|
|
|
|
depends on !LD_SCRIPT_STATIC
|
|
|
|
|
|
2021-03-08 13:02:37 +00:00
|
|
|
config LD_SCRIPT_DYN_RPATH
|
|
|
|
|
bool "set rpath in the binary" if EXPERT
|
|
|
|
|
default y
|
|
|
|
|
depends on LD_SCRIPT_DYN
|
|
|
|
|
help
|
|
|
|
|
Add /lib (and /lib64 for 64-bit) to the linux binary's rpath
|
|
|
|
|
explicitly.
|
|
|
|
|
|
|
|
|
|
You may need to turn this off if compiling for nix systems
|
|
|
|
|
that have their libraries in random /nix directories and
|
|
|
|
|
might otherwise unexpected use libraries from /lib or /lib64
|
|
|
|
|
instead of the desired ones.
|
|
|
|
|
|
2018-07-31 11:39:27 +00:00
|
|
|
config HOSTFS
|
|
|
|
|
tristate "Host filesystem"
|
|
|
|
|
help
|
2019-03-06 21:14:55 +00:00
|
|
|
While the User-Mode Linux port uses its own root file system for
|
|
|
|
|
booting and normal file access, this module lets the UML user
|
|
|
|
|
access files stored on the host. It does not require any
|
|
|
|
|
network connection between the Host and UML. An example use of
|
|
|
|
|
this might be:
|
2018-07-31 11:39:27 +00:00
|
|
|
|
2019-03-06 21:14:55 +00:00
|
|
|
mount none /tmp/fromhost -t hostfs -o /tmp/umlshare
|
2018-07-31 11:39:27 +00:00
|
|
|
|
2019-03-06 21:14:55 +00:00
|
|
|
where /tmp/fromhost is an empty directory inside UML and
|
|
|
|
|
/tmp/umlshare is a directory on the host with files the UML user
|
|
|
|
|
wishes to access.
|
2018-07-31 11:39:27 +00:00
|
|
|
|
2019-03-06 21:14:55 +00:00
|
|
|
For more information, see
|
|
|
|
|
<http://user-mode-linux.sourceforge.net/hostfs.html>.
|
2018-07-31 11:39:27 +00:00
|
|
|
|
2019-03-06 21:14:55 +00:00
|
|
|
If you'd like to be able to work with files stored on the host,
|
|
|
|
|
say Y or M here; otherwise say N.
|
2018-07-31 11:39:27 +00:00
|
|
|
|
|
|
|
|
config MCONSOLE
|
|
|
|
|
bool "Management console"
|
|
|
|
|
depends on PROC_FS
|
|
|
|
|
default y
|
|
|
|
|
help
|
2019-03-06 21:14:55 +00:00
|
|
|
The user mode linux management console is a low-level interface to
|
|
|
|
|
the kernel, somewhat like the i386 SysRq interface. Since there is
|
|
|
|
|
a full-blown operating system running under every user mode linux
|
|
|
|
|
instance, there is much greater flexibility possible than with the
|
|
|
|
|
SysRq mechanism.
|
|
|
|
|
|
|
|
|
|
If you answer 'Y' to this option, to use this feature, you need the
|
|
|
|
|
mconsole client (called uml_mconsole) which is present in CVS in
|
|
|
|
|
2.4.5-9um and later (path /tools/mconsole), and is also in the
|
|
|
|
|
distribution RPM package in 2.4.6 and later.
|
|
|
|
|
|
|
|
|
|
It is safe to say 'Y' here.
|
2018-07-31 11:39:27 +00:00
|
|
|
|
|
|
|
|
config MAGIC_SYSRQ
|
|
|
|
|
bool "Magic SysRq key"
|
|
|
|
|
depends on MCONSOLE
|
|
|
|
|
help
|
|
|
|
|
If you say Y here, you will have some control over the system even
|
|
|
|
|
if the system crashes for example during kernel debugging (e.g., you
|
|
|
|
|
will be able to flush the buffer cache to disk, reboot the system
|
|
|
|
|
immediately or dump some status information). A key for each of the
|
|
|
|
|
possible requests is provided.
|
|
|
|
|
|
|
|
|
|
This is the feature normally accomplished by pressing a key
|
|
|
|
|
while holding SysRq (Alt+PrintScreen).
|
|
|
|
|
|
|
|
|
|
On UML, this is accomplished by sending a "sysrq" command with
|
|
|
|
|
mconsole, followed by the letter for the requested command.
|
|
|
|
|
|
|
|
|
|
The keys are documented in <file:Documentation/admin-guide/sysrq.rst>. Don't say Y
|
|
|
|
|
unless you really know what this hack does.
|
|
|
|
|
|
|
|
|
|
config KERNEL_STACK_ORDER
|
|
|
|
|
int "Kernel stack size order"
|
2019-01-04 15:38:21 +00:00
|
|
|
default 2 if 64BIT
|
|
|
|
|
range 2 10 if 64BIT
|
|
|
|
|
default 1 if !64BIT
|
2018-07-31 11:39:27 +00:00
|
|
|
help
|
|
|
|
|
This option determines the size of UML kernel stacks. They will
|
|
|
|
|
be 1 << order pages. The default is OK unless you're running Valgrind
|
|
|
|
|
on UML, in which case, set this to 3.
|
2019-01-04 15:38:21 +00:00
|
|
|
It is possible to reduce the stack to 1 for 64BIT and 0 for 32BIT on
|
|
|
|
|
older (pre-2017) CPUs. It is not recommended on newer CPUs due to the
|
|
|
|
|
increase in the size of the state which needs to be saved when handling
|
2019-11-20 13:36:54 +00:00
|
|
|
signals.
|
2018-07-31 11:39:27 +00:00
|
|
|
|
|
|
|
|
config MMAPPER
|
|
|
|
|
tristate "iomem emulation driver"
|
|
|
|
|
help
|
|
|
|
|
This driver allows a host file to be used as emulated IO memory inside
|
|
|
|
|
UML.
|
|
|
|
|
|
|
|
|
|
config PGTABLE_LEVELS
|
|
|
|
|
int
|
|
|
|
|
default 3 if 3_LEVEL_PGTABLES
|
|
|
|
|
default 2
|
|
|
|
|
|
2019-05-27 08:34:27 +00:00
|
|
|
config UML_TIME_TRAVEL_SUPPORT
|
|
|
|
|
bool
|
|
|
|
|
prompt "Support time-travel mode (e.g. for test execution)"
|
2019-12-13 09:01:28 +00:00
|
|
|
# inf-cpu mode is incompatible with the benchmarking
|
|
|
|
|
depends on !RAID6_PQ_BENCHMARK
|
um: time-travel: Rewrite as an event scheduler
Instead of tracking all the various timer configurations,
modify the time-travel mode to have an event scheduler and
use a timer event on the scheduler to handle the different
timer configurations.
This doesn't change the function right now, but it prepares
the code for having different kinds of events in the future
(i.e. interrupts coming from other devices that are part of
co-simulation.)
While at it, also move time_travel_sleep() to time.c to
reduce the externally visible API surface.
Also, we really should mark time-travel as incompatible with
SMP, even if UML doesn't support SMP yet.
Finally, I noticed a bug while developing this - if we move
time forward due to consuming time while reading the clock,
we might move across the next event and that would cause us
to go backward in time when we then handle that event. Fix
that by invoking the whole event machine in this case, but
in order to simplify this, make reading the clock only cost
something when interrupts are not disabled. Otherwise, we'd
have to hook into the interrupt delivery machinery etc. and
that's somewhat intrusive.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2020-02-13 13:26:45 +00:00
|
|
|
depends on !SMP
|
2019-05-27 08:34:27 +00:00
|
|
|
help
|
|
|
|
|
Enable this option to support time travel inside the UML instance.
|
|
|
|
|
|
|
|
|
|
After enabling this option, two modes are accessible at runtime
|
|
|
|
|
(selected by the kernel command line), see the kernel's command-
|
|
|
|
|
line help for more details.
|
|
|
|
|
|
|
|
|
|
It is safe to say Y, but you probably don't need this.
|
|
|
|
|
|
UML: add support for KASAN under x86_64
Make KASAN run on User Mode Linux on x86_64.
The UML-specific KASAN initializer uses mmap to map the ~16TB of shadow
memory to the location defined by KASAN_SHADOW_OFFSET. kasan_init()
utilizes constructors to initialize KASAN before main().
The location of the KASAN shadow memory, starting at
KASAN_SHADOW_OFFSET, can be configured using the KASAN_SHADOW_OFFSET
option. The default location of this offset is 0x100000000000, which
keeps it out-of-the-way even on UML setups with more "physical" memory.
For low-memory setups, 0x7fff8000 can be used instead, which fits in an
immediate and is therefore faster, as suggested by Dmitry Vyukov. There
is usually enough free space at this location; however, it is a config
option so that it can be easily changed if needed.
Note that, unlike KASAN on other architectures, vmalloc allocations
still use the shadow memory allocated upfront, rather than allocating
and free-ing it per-vmalloc allocation.
If another architecture chooses to go down the same path, we should
replace the checks for CONFIG_UML with something more generic, such
as:
- A CONFIG_KASAN_NO_SHADOW_ALLOC option, which architectures could set
- or, a way of having architecture-specific versions of these vmalloc
and module shadow memory allocation options.
Also note that, while UML supports both KASAN in inline mode
(CONFIG_KASAN_INLINE) and static linking (CONFIG_STATIC_LINK), it does
not support both at the same time.
Signed-off-by: Patricia Alfonso <trishalfonso@google.com>
Co-developed-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Signed-off-by: David Gow <davidgow@google.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
2022-07-01 09:16:20 +00:00
|
|
|
config KASAN_SHADOW_OFFSET
|
|
|
|
|
hex
|
|
|
|
|
depends on KASAN
|
|
|
|
|
default 0x100000000000
|
|
|
|
|
help
|
|
|
|
|
This is the offset at which the ~16TB of shadow memory is
|
|
|
|
|
mapped and used by KASAN for memory debugging. This can be any
|
|
|
|
|
address that has at least KASAN_SHADOW_SIZE (total address space divided
|
|
|
|
|
by 8) amount of space so that the KASAN shadow memory does not conflict
|
|
|
|
|
with anything. The default is 0x100000000000, which works even if mem is
|
|
|
|
|
set to a large value. On low-memory systems, try 0x7fff8000, as it fits
|
|
|
|
|
into the immediate of most instructions, improving performance.
|
|
|
|
|
|
2018-07-31 11:39:27 +00:00
|
|
|
endmenu
|
|
|
|
|
|
2018-07-31 11:39:28 +00:00
|
|
|
source "arch/um/drivers/Kconfig"
|
2020-12-02 19:58:06 +00:00
|
|
|
|
|
|
|
|
config ARCH_SUSPEND_POSSIBLE
|
|
|
|
|
def_bool y
|
|
|
|
|
|
2023-01-13 16:56:11 +00:00
|
|
|
menu "Power management options"
|
|
|
|
|
|
2020-12-02 19:58:06 +00:00
|
|
|
source "kernel/power/Kconfig"
|
2023-01-13 16:56:11 +00:00
|
|
|
|
|
|
|
|
endmenu
|
