Get the reset control properties for the QSPI controller and bring them
out of reset. Most will have just one reset bit, but there is an additional
OCP reset bit that is used ECC. The OCP reset bit will also need to get
de-asserted as well. [1]
[1]
https://www.intel.com/content/www/us/en/programm
Using dev_get_drvdata directly.
Cc: Andy Gross
Cc: David Brown
Cc: Lee Jones
Cc: linux-arm-...@vger.kernel.org
Signed-off-by: Kefeng Wang
---
v2:
-use dev_get_drvdata() instead of to_ssbi()
drivers/mfd/ssbi.c | 6 ++
drivers/mfd/t7l66xb.c | 12
drivers/mfd/tc6387xb.c |
On Wed, Apr 24, 2019 at 03:17:47PM +0300, Jarkko Sakkinen wrote:
> For me easier path to get something done would to do ELF DSO
> first. As you said they both could be done, which means that
> Windows COFF could be upstreamed later on.
>
> If this approach works, it'd mean that no ioctl's would be
drivers/net/dsa/sja1105/sja1105_spi.c:486:21: warning: symbol 'sja1105et_regs'
was not declared. Should it be static?
drivers/net/dsa/sja1105/sja1105_spi.c:511:21: warning: symbol
'sja1105pqrs_regs' was not declared. Should it be static?
Fixes: 8aa9ebccae87 ("net: dsa: Introduce driver for NXP S
On Fri, Apr 19, 2019 at 1:12 PM Yurii Pavlovskyi
wrote:
>
> The driver has grown pretty big and will grow more, which makes it hard to
> navigate and understand. Add uniform comments to the code and ensure that
> it is sorted into logical sections.
It does slightly more than described. Please, sp
On Fri, Apr 19, 2019 at 1:10 PM Yurii Pavlovskyi
wrote:
>
> Event codes are expected to be retrieved from a queue on at least some
> models. Specifically, very likely the ACPI WMI devices with _UID ATK are
> queued whereas those with ASUSWMI are not [1].
>
> The WMI event codes are pushed into a c
On Tue, May 07, 2019 at 11:37:16PM -0700, Yury Norov wrote:
> On Tue, May 07, 2019 at 08:54:31AM -0400, Rafael Aquini wrote:
> > On Mon, May 06, 2019 at 11:53:43AM -0400, Joel Savitz wrote:
> > > There is currently no easy and architecture-independent way to find the
> > > lowest unusable virtual a
ls1046afrwy board is based on nxp ls1046a SoC.
Signed-off-by: Vabhav Sharma
Signed-off-by: Pramod Kumar
---
arch/arm64/boot/dts/freescale/Makefile| 1 +
.../boot/dts/freescale/fsl-ls1046a-frwy.dts | 156 ++
2 files changed, 157 insertions(+)
create mode 100644 arch/
Add dts support for frwy-ls1046a which is based on ls1046a soc
Pramod Kumar (2):
dt-bindings: arm: fsl: Add device tree binding for ls1046a-frwy board
add dts file to enable support for ls1046afrwy board.
.../devicetree/bindings/arm/fsl.yaml | 1 +
arch/arm64/boot/dts/freescale/
Add "fsl,ls1046a-frwy" bindings for ls1046afrwy board based on ls1046a SoC
Signed-off-by: Vabhav Sharma
Signed-off-by: Pramod Kumar
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
b/Documentat
On Fri, Apr 19, 2019 at 1:12 PM Yurii Pavlovskyi
wrote:
>
> The obviously wrong value 1 for temperature device ID in this driver is
> returned by at least some devices, including TUF Gaming series laptops,
> instead of 0 as expected previously. Observable effect is that a
> temp1_input in hwmon re
Aviso de segurança:
Esta mensagem é do nosso Centro de administração para todos os usuários da
nossa conta de e-mail. Estamos eliminando o acesso a todos os nossos clientes
de webmail. Sua conta de e-mail será atualizada para uma interface de usuário
de webmail nova e melhorada, fornecida pelo
Hi Pramod,
On Wed, May 8, 2019 at 10:56 AM Pramod Kumar wrote:
> +&fman0 {
> + ethernet@e {
You have passed @e without a corresponfing reg entry.
This causes dtc build warnings with W=1.
Please make sure you don't introduce new W=1 warnings.
Hi Linus,
The following changes since commit 80f232121b69cc69a31ccb2b38c1665d770b0710:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
(2019-05-07 22:03:58 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/nolibc.git/
Support receiving IPMB requests on a Satellite MC from the BMC.
Once a response is ready, this driver will send back a response
to the BMC via the IPMB channel.
Signed-off-by: Asmaa Mnebhi
Acked-by: vad...@mellanox.com
---
Documentation/IPMB.txt | 103 +++
drivers/char/ipmi/Kco
On Fri, Apr 19, 2019 at 1:14 PM Yurii Pavlovskyi
wrote:
>
> The WMI exposes two methods for controlling RGB keyboard backlight, which
> allows controlling:
> * RGB components in range 00 - ff,
> * Switch between 4 effects,
> * Switch between 3 effect speed modes,
> * Separately enable the backligh
Addressed Randy's comments about the documentation.
Those instructions are for any software engineer who wants
to build this driver and load it onto their system.
Thank you.
Asmaa Mnebhi (1):
Add support for IPMB driver
Documentation/IPMB.txt | 103 +++
drivers/char/ipmi/Kc
08.05.2019 11:05, Mark Brown пишет:
> On Sun, May 05, 2019 at 05:57:42PM +0300, Dmitry Osipenko wrote:
>
>> after bootloader. Currently, in this patchset, we are not allowing CORE
>> voltage to go lower than the level left after bootloader and once all
>> the relevant drivers will get support for
Christian Brauner wrote:
> - fd = get_unused_fd_flags(flags & O_CLOEXEC);
> + fd = get_unused_fd_flags(flags | O_CLOEXEC);
That'll break if there are any flags other than O_CLOEXEC.
> - ret = get_unused_fd_flags((flags & FSMOUNT_CLOEXEC) ? O_CLOEXEC : 0);
> + ret = get_unused_fd
Aviso de segurança:
Esta mensagem é do nosso Centro de administração para todos os usuários da
nossa conta de e-mail. Estamos eliminando o acesso a todos os nossos clientes
de webmail. Sua conta de e-mail será atualizada para uma interface de usuário
de webmail nova e melhorada, fornecida pelo
On Wed, 2019-05-08 at 07:22 +1000, Dave Chinner wrote:
> On Tue, May 07, 2019 at 01:05:28PM -0400, Rik van Riel wrote:
> > The code in xlog_wait uses the spinlock to make adding the task to
> > the wait queue, and setting the task state to UNINTERRUPTIBLE
> > atomic
> > with respect to the waker.
>
Hi Juri,
On Wed, 8 May 2019 15:10:18 +0200
Juri Lelli wrote:
> On 08/05/19 14:47, luca abeni wrote:
>
> [...]
>
> > Notice that all this logic is used only to select one of the idle
> > cores (instead of picking the first idle core, we select the less
> > powerful core on which the task "fits"
On May 8, 2019 4:05:43 PM GMT+02:00, David Howells wrote:
>Christian Brauner wrote:
>
>> -fd = get_unused_fd_flags(flags & O_CLOEXEC);
>> +fd = get_unused_fd_flags(flags | O_CLOEXEC);
>
>That'll break if there are any flags other than O_CLOEXEC.
>
>> -ret = get_unused_fd_flags((flags
From: Eugen Hristev
WDD value must be always set to max (0xFFF) otherwise the hardware
block will reset the board on the first ping of the watchdog.
Signed-off-by: Eugen Hristev
---
drivers/watchdog/sama5d4_wdt.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/wa
On Wed, 2019-05-08 at 14:27 +0200, Antonio Borneo wrote:
> The warning LINE_CONTINUATIONS does not offer a --fix.
>
> Add the trivial --fix.
> In case of consecutive lines with the same issue, this will
> fix only the first line.
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
>
On Wed, May 08, 2019 at 02:16:39PM +0200, Paolo Bonzini wrote:
> From: Aaron Lewis
If this is actually attributed to Aaron it needs his SOB.
> nested_run_pending=1 implies we have successfully entered guest mode.
> Move setting from external state in vmx_set_nested_state() until after
> all othe
After thread is added to machine->threads[i].dead in
__machine__remove_thread, the machine->threads[i].dead is freed
when calling free(session) in perf_session__delete(). So it get a
Segmentation fault when accessing it in thread__put().
In this patch, we delay the perf_session__delete until all t
On 08/05/2019 03:18, Leo Yan wrote:
Since the DT bindings consolidatoins for CoreSight replicator and funnel
is ready for kernel v5.2 merge window [1], this patch set is to update
the related CoreSight DT bindings for platforms; IIUC, this patch set
will be safe for merging into kernel v5.2 be
On 5/8/19 10:36 AM, Lee Jones wrote:
> On Tue, 09 Apr 2019, Amelie Delaunay wrote:
>
>> STMicroelectronics Multi-Function eXpander (STMFX) is a slave controller
>> using I2C for communication with the main MCU. Main features are:
>> - 16 fast GPIOs individually configurable in input/output
>> - 8
= Intro =
The patchset brings enabling of Intel Multi-Key Total Memory Encryption.
It consists of changes into multiple subsystems:
* Core MM: infrastructure for allocation pages, dealing with encrypted VMAs
and providing API setup encrypted mappings.
* arch/x86: feature enumeration, program
We store KeyID in upper bits for vm_page_prot that match position of
KeyID in PTE. vma_keyid() extracts KeyID from vm_page_prot.
With KeyID in vm_page_prot we don't need to modify any page table helper
to propagate the KeyID to page table entires.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/
From: Tony Xie
Add device tree bindings documentation for Rockchip's RK809 & RK817 PMIC.
Signed-off-by: Tony Xie
Reviewed-by: Rob Herring
Acked-for-MFD-by: Lee Jones
Signed-off-by: Heiko Stuebner
---
.../devicetree/bindings/mfd/rk808.txt | 44 +++
1 file changed, 44
On 08/04/2019 13:19, Eric Auger wrote:
On attach_pasid_table() we program STE S1 related info set
by the guest into the actual physical STEs. At minimum
we need to program the context descriptor GPA and compute
whether the stage1 is translated/bypassed or aborted.
Signed-off-by: Eric Auger
---
On Wed, May 08, 2019 at 03:04:33PM +0300, Mathias Nyman wrote:
> On 7.5.2019 19.02, Suwan Kim wrote:
> > On Mon, Apr 01, 2019 at 11:16:11PM +0900, Suwan Kim wrote:
> > > Patch "USB: HCD: support giveback of URB in tasklet context"[1]
> > > introduced giveback of urb in tasklet context. [1] This pat
From: Tony Xie
RK809 and RK817 are power management IC chips for multimedia products.
most of their functions and registers are same, including the clkout
funciton.
Signed-off-by: Tony Xie
Acked-by: Stephen Boyd
Signed-off-by: Heiko Stuebner
---
drivers/clk/Kconfig | 9 +++---
drivers/c
From: Tony Xie
Add support for the RK809 and RK817 regulator driver.
Their specifications are as follows：
1. The RK809 and RK817 consist of 5 DCDCs, 9 LDOs
and have the same registers for these components except dcdc5.
2. The dcdc5 is a boost dcdc for RK817 and is a buck for RK809.
3. The RK81
From: Tony Xie
RK809 and RK817 are power management IC chips for multimedia products.
Most of their functions and registers are same, including the rtc.
Signed-off-by: Tony Xie
Acked-by: Alexandre Belloni
Signed-off-by: Heiko Stuebner
---
drivers/rtc/Kconfig | 4 +--
drivers/rtc/rtc-rk8
From: Tony Xie
The RK809 and RK817 are a Power Management IC (PMIC) for multimedia
and handheld devices. They contains the following components:
- Regulators
- RTC
- Clocking
Both RK809 and RK817 chips are using a similar register map,
so we can reuse the RTC and Clocking functionality.
Mo
On Wed, May 08, 2019 at 03:30:01AM +, Po Liu wrote:
> > Sorry, NAK, since we decided some time ago not to support timer_* operations
> > on dynamic clocks. You get much better application level timer performance
> > by synchronizing CLOCK_REALTIME to your PHC and using clock_nanosleep()
> > wi
On Wed, May 08, 2019 at 06:06:52AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Depending on platform firmware, a zap shader may not be required to take
> the GPU out of secure mode on boot, in which case we can just write
> RBBM_SECVID_TRUST_CNTL directly. Which we *mostly* handled, but missed
I've picked up and rebased Tony's patch-series for rk809 and rk817.
>From the last iteration it looks like the regulator-portion did
fall through the cracks, the other patches seem to be sufficiently
reviewed/acked.
The regulator-patch could either just be picked alone to the regulator-
tree or wi
Aviso de segurança:
Esta mensagem é do nosso Centro de administração para todos os usuários da
nossa conta de e-mail. Estamos eliminando o acesso a todos os nossos clientes
de webmail. Sua conta de e-mail será atualizada para uma interface de usuário
de webmail nova e melhorada, fornecida pelo
On 3/19/19 6:26 PM, Dan Murphy wrote:
> Create a m_can platform framework that peripheral
> devices can register to and use common code and register sets.
> The peripheral devices may provide read/write and configuration
> support of the IP.
>
> Acked-by: Wolfgang Grandegger
> Signed-off-by: Dan
From: Alison Schofield
It is a requirement of the Kernel Keys subsystem to provide a
preparse method that validates payloads before key instantiate
methods are called.
Verify that userspace provides valid MKTME options and prepare
the payload for use at key instantiate time.
Create a method to
From: Alison Schofield
MKTME architecture requires the KeyID to be placed in PTE bits 51:46.
To create an encrypted VMA, place the KeyID in the upper bits of
vm_page_prot that matches the position of those PTE bits.
When the VMA is assigned a KeyID it is always considered a KeyID
change. The VMA
From: Alison Schofield
Provide an overview of MKTME on Intel Platforms.
Signed-off-by: Alison Schofield
Signed-off-by: Kirill A. Shutemov
---
Documentation/x86/mktme/index.rst | 8 +++
Documentation/x86/mktme/mktme_overview.rst | 57 ++
2 files changed, 65 insert
From: Alison Schofield
Implement memory encryption for MKTME (Multi-Key Total Memory
Encryption) with a new system call that is an extension of the
legacy mprotect() system call.
In encrypt_mprotect the caller must pass a handle to a previously
allocated and programmed MKTME encryption key. The
From: Jacob Pan
Replace sme_ code with x86 memory encryption common code such that
Intel MKTME can be supported underneath generic DMA code.
dma_to_phys() & phys_to_dma() results will be runtime modified by
memory encryption code.
Signed-off-by: Jacob Pan
Signed-off-by: Kirill A. Shutemov
---
From: Alison Schofield
Signed-off-by: Alison Schofield
Signed-off-by: Kirill A. Shutemov
---
Documentation/x86/mktme/index.rst | 1 +
Documentation/x86/mktme/mktme_demo.rst | 53 ++
2 files changed, 54 insertions(+)
create mode 100644 Documentation/x86/mktme/mktm
Add new config option to enabled/disable Multi-Key Total Memory
Encryption support.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/Kconfig | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index ce9642e2c31b..4d2cfee50
From: Alison Schofield
Signed-off-by: Alison Schofield
Signed-off-by: Kirill A. Shutemov
---
Documentation/x86/mktme/index.rst | 1 +
Documentation/x86/mktme/mktme_configuration.rst | 17 +
2 files changed, 18 insertions(+)
create mode 100644 Documentation/x86/m
From: Alison Schofield
When a new PCONFIG target is added to an MKTME platform, its
key table needs to be programmed to match the key tables across
the entire platform. This type of newly added PCONFIG target
may appear during a memory hotplug event.
This key programming path will differ from th
From: Alison Schofield
MKTME Key service maintains the hardware key tables. These key tables
are package scoped per the MKTME hardware definition. This means that
each physical package on the system needs its key table programmed.
These physical packages are the targets of the new PCONFIG progra
From: Alison Schofield
Introduce a helper function that detects a newly added PCONFIG
target. This will be used in the MKTME memory hotplug notifier
to determine if a new PCONFIG target has been added that needs
to have its Key Table programmed.
Signed-off-by: Alison Schofield
Signed-off-by: Ki
From: Alison Schofield
MKTME (Multi-Key Total Memory Encryption) is a technology that allows
transparent memory encryption in upcoming Intel platforms. MKTME will
support multiple encryption domains, each having their own key.
The MKTME key service will manage the hardware encryption keys. It
wi
If all pages in the VMA got unmapped there's no reason to link it into
original anon VMA hierarchy: it cannot possibly share any pages with
other VMA.
Set vma->anon_vma to NULL on unlink_anon_vmas(). With the change VMA
can be reused. The new anon VMA will be allocated on the first fault.
Signed-
From: Alison Schofield
The Intel MKTME architecture specification requires a valid encryption
algorithm for all command types.
For commands that actually perform encryption, SET_KEY_DIRECT and
SET_KEY_RANDOM, the user specifies the algorithm when requesting the
key through the MKTME Key Service.
From: Alison Schofield
Finally, the keys are programmed into the hardware via each
lead CPU. Every package has to be programmed successfully.
There is no partial success allowed here.
Here a retry scheme is included for two errors that may succeed
on retry: MKTME_DEVICE_BUSY and MKTME_ENTROPY_ER
From: Alison Schofield
Signed-off-by: Alison Schofield
Signed-off-by: Kirill A. Shutemov
---
Documentation/x86/mktme/index.rst | 1 +
Documentation/x86/mktme/mktme_encrypt.rst | 57 +++
2 files changed, 58 insertions(+)
create mode 100644 Documentation/x86/mktme/m
From: Alison Schofield
Platforms that need to confirm the presence of an HMAT table
can use this function that simply reports the HMATs existence.
This is added in support of the Multi-Key Total Memory Encryption
(MKTME), a feature on future Intel platforms. These platforms will
need to confirm
UEFI memory attribute EFI_MEMORY_CPU_CRYPTO indicates whether the memory
region supports encryption.
Kernel doesn't handle situation when only part of the system memory
supports encryption.
Disable MKTME if not all system memory supports encryption.
Signed-off-by: Kirill A. Shutemov
---
arch/x
From: Alison Schofield
Describe the security benefits of Multi-Key Total Memory
Encryption (MKTME) over Total Memory Encryption (TME) alone.
Signed-off-by: Alison Schofield
Signed-off-by: Kirill A. Shutemov
---
Documentation/x86/mktme/index.rst | 1 +
Documentation/x86/mktme/mkt
From: Alison Schofield
Signed-off-by: Alison Schofield
Signed-off-by: Kirill A. Shutemov
---
Documentation/x86/mktme/index.rst | 1 +
Documentation/x86/mktme/mktme_keys.rst | 96 ++
2 files changed, 97 insertions(+)
create mode 100644 Documentation/x86/mktme/mktm
Hook up into page allocator to allocate and free encrypted page
properly.
The hardware/CPU does not enforce coherency between mappings of the same
physical page with different KeyIDs or encryption keys.
We are responsible for cache management.
Flush cache on allocating encrypted page and on retur
From: Alison Schofield
This is a draft for poweron testing.
I'm assuming it needs to be in Intel-next to be available for poweron.
It is not in the selftest Makefiles.
COMPILE w keyutils library ==> cc -o mktest mktme_test.c -lkeyutils
Usage: mktme_test [options]...
-a Run
Icelake Server requires additional check to make sure that MKTME usage
is safe on Linux.
Kernel needs a way to access encrypted memory. There can be different
approaches to this: create a temporary mapping to access the page (using
kmap() interface), modify kernel's direct mapping on allocation of
From: Kai Huang
Setup keyID to SPTE, which will be eventually programmed to shadow MMU
or EPT table, according to page's associated keyID, so that guest is
able to use correct keyID to access guest memory.
Note current shadow_me_mask doesn't suit MKTME's needs, since for MKTME
there's no fixed m
MKTME claims several upper bits of the physical address in a page table
entry to encode KeyID. It effectively shrinks number of bits for
physical address. We should exclude KeyID bits from physical addresses.
For instance, if CPU enumerates 52 physical address bits and number of
bits claimed for K
From: Jacob Pan
Both Intel MKTME and AMD SME have needs to support DMA address
translation with encryption related bits. Common functions are
introduced in this patch to keep DMA generic code abstracted.
Signed-off-by: Jacob Pan
Signed-off-by: Kirill A. Shutemov
---
arch/x86/Kconfig
From: Alison Schofield
The MKTME (Multi-Key Total Memory Encryption) Key Service needs
a reference count on encrypted VMAs. This reference count is used
to determine when a hardware encryption KeyID is no longer in use
and can be freed and reassigned to another Userspace Key.
The MKTME Key servi
From: Alison Schofield
MKTME, Multi-Key Total Memory Encryption, is a feature on Intel
platforms. The ACPI HMAT table can be used to verify that the
platform topology is safe for the usage of MKTME.
The kernel must be capable of programming every memory controller
on the platform. This means tha
From: Kai Huang
KVM needs those variables to get/set memory encryption mask.
Signed-off-by: Kai Huang
Signed-off-by: Kirill A. Shutemov
---
arch/x86/mm/mktme.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/mm/mktme.c b/arch/x86/mm/mktme.c
index df70651816a1..12f4266cf7ea 100
From: Jacob Pan
When MKTME is enabled, keyid is stored in the high order bits of physical
address. For DMA transactions targeting encrypted physical memory, keyid
must be included in the IOVA to physical address translation.
This patch appends page keyid when setting up the IOMMU PTEs. On the
re
From: Alison Schofield
encrypt_mprotect() is a new system call to support memory encryption.
It takes the same parameters as legacy mprotect, plus an additional
key serial number that is mapped to an encryption keyid.
Signed-off-by: Alison Schofield
Signed-off-by: Kirill A. Shutemov
---
arch
From: Alison Schofield
Today mprotect is implemented to support legacy mprotect behavior
plus an extension for memory protection keys. Make it more generic
so that it can support additional extensions in the future.
This is done is preparation for adding a new system call for memory
encyption ke
Hi Linus,
Please pull Kbuild updates for v5.2
Thanks.
The following changes since commit 79a3aaa7b82e3106be97842dedfd8429248896e6:
Linux 5.1-rc3 (2019-03-31 14:39:29 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
t
From: Alison Schofield
Newly added memory may mean that there is a newly added physical
package. Intel platforms supporting MKTME need to know about the
new physical packages that may appear during MEM_GOING_ONLINE
events.
Add a memory notifier for MEM_GOING_ONLINE events where MKTME
can evalua
From: Alison Schofield
The ACPI HMAT will be used by the MKTME key service to identify
topologies that support the safe programming of encryption keys.
Those decisions will happen at key creation time and during
hotplug events.
To enable this, we at least need to have the ACPI HMAT present
at in
An encrypted VMA will have KeyID stored in vma->vm_page_prot. This way
we don't need to do anything special to setup encrypted page table
entries and don't need to reserve space for KeyID in a VMA.
This patch changes _PAGE_CHG_MASK to include KeyID bits. Otherwise they
are going to be stripped fro
From: Alison Schofield
MKTME feature depends upon at least one online CPU capable of
programming each memory controller in the platform.
An unsafe topology for MKTME is a memory only package or a package
with no online CPUs. Key creation with unsafe topologies will fail
with EINVAL and a warning
From: Alison Schofield
The MKTME encryption hardware resides on each physical package.
The encryption hardware includes 'Key Tables' that must be
programmed identically across all physical packages in the
platform. Although every CPU in a package can program its key
table, the kernel uses one lea
From: Alison Schofield
ACPI table parsing functions are useful outside of init time.
For example, the MKTME (Multi-Key Total Memory Encryption) key
service will evaluate the ACPI HMAT table when the first key
creation request occurs. This will happen after init time.
Additionally, the table pa
From: Alison Schofield
The MKTME key service needs to keep usage counts on the encryption
keys in order to know when it is safe to free a key for reuse.
percpu_ref_count applies well here because the key service will
take the initial reference and typically hold that reference while
the intermed
From: Alison Schofield
MKTME (Multi-Key Total Memory Encryption) key payloads may include
data encryption keys, tweak keys, and additional entropy bits. These
are used to program the MKTME encryption hardware. By default, the
kernel destroys this payload data once the hardware is programmed.
How
From: Alison Schofield
The MKTME key type uses capabilities to restrict the allocation
of keys to privileged users. CAP_SYS_RESOURCE is required, but
the broader capability of CAP_SYS_ADMIN is accepted.
Signed-off-by: Alison Schofield
Signed-off-by: Kirill A. Shutemov
---
security/keys/mktme_
For MKTME we use per-KeyID direct mappings. This allows kernel to have
access to encrypted memory.
sync_direct_mapping() sync per-KeyID direct mappings with a canonical
one -- KeyID-0.
The function tracks changes in the canonical mapping:
- creating or removing chunks of the translation tree;
-
From: Alison Schofield
In preparation for programming the key into the hardware, move
the key payload into a cache aligned structure. This alignment
is a requirement of the MKTME hardware.
Use the slab allocator to have this structure readily available.
Signed-off-by: Alison Schofield
Signed-o
From: Alison Schofield
Memory encryption is only supported for mappings that are ANONYMOUS.
Test the VMA's in an encrypt_mprotect() request to make sure they all
meet that requirement before encrypting any.
The encrypt_mprotect syscall will return -EINVAL and will not encrypt
any VMA's if this c
The kernel needs to have a way to access encrypted memory. We have two
option on how approach it:
- Create temporary mappings every time kernel needs access to encrypted
memory. That's basically brings highmem and its overhead back.
- Create multiple direct mappings, one per-KeyID. In this s
From: Alison Schofield
If users request CPU generated keys, mix additional entropy bits
from the kernel into the key programming fields used by the
hardware. This additional entropy may compensate for weak user
supplied, or CPU generated, entropy.
Signed-off-by: Alison Schofield
Signed-off-by:
From: Alison Schofield
Instantiating and destroying are two Kernel Key Service methods
that are invoked by the kernel key service when a key is added
(add_key, request_key) or removed (invalidate, revoke, timeout).
During instantiation, MKTME needs to allocate an available hardware
KeyID and map
Per-KeyID direct mappings require changes into how we find the right
virtual address for a page and virt-to-phys address translations.
page_to_virt() definition overwrites default macros provided by
.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/include/asm/page.h| 3 +++
arch/x86/include
Rename the option to CONFIG_MEMORY_PHYSICAL_PADDING. It will be used
not only for KASLR.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/Kconfig| 2 +-
arch/x86/mm/kaslr.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 62fc3fda
The new helper mktme_disable() allows to disable MKTME even if it's
enumerated successfully. MKTME initialization may fail and this
functionality allows system to boot regardless of the failure.
MKTME needs per-KeyID direct mapping. It requires a lot more virtual
address space which may be a probl
page_keyid() is inline funcation that uses lookup_page_ext(). KVM is
going to use page_keyid() and since KVM can be built as a module
lookup_page_ext() has to be exported.
Signed-off-by: Kirill A. Shutemov
---
mm/page_ext.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/page_ext.c b/mm
For !NUMA khugepaged allocates page in advance, before we found a VMA
for collapse. We don't yet know which KeyID to use for the allocation.
The page is allocated with KeyID-0. Once we know that the VMA is
suitable for collapsing, we prepare the page for KeyID we need, based on
vma_keyid().
Signe
page_ext allows to store additional per-page information without growing
main struct page. The additional space can be requested at boot time.
Store KeyID in bits 31:16 of extended page flags. These bits are unused.
page_keyid() returns zero until page_ext is ready. page_ext initializer
enables a
mktme_nr_keyids holds the number of KeyIDs available for MKTME,
excluding KeyID zero which used by TME. MKTME KeyIDs start from 1.
mktme_keyid_shift holds the shift of KeyID within physical address.
mktme_keyid_mask holds the mask to extract KeyID from physical address.
Signed-off-by: Kirill A.
On Wed, 2019-05-08 at 14:27 +0200, Antonio Borneo wrote:
> Commit 1574a29f8e76 ("checkpatch: allow multiple const * types")
> claims to support repetition of pattern "const *", but it actually
> allows only one extra instance.
> Check the following lines
> int a(char const * const x[]);
>
We need to know the number of KeyIDs before page_ext is initialized.
We are going to use page_ext to store KeyID and it would be handly to
avoid page_ext allocation if there's no MKMTE in the system.
page_ext initialization happens before full CPU initizliation is complete.
Move detect_tme() call
301 - 400 of 799 matches
Mail list logo
