Le 11/06/2019 à 13:52, Horia Geanta a écrit :
On 6/6/2019 2:31 PM, Christophe Leroy wrote:
commit d84cc9c9524e ("crypto: talitos - fix ECB algs ivsize")
wrongly modified CBC algs ivsize instead of ECB aggs ivsize.
This restore the CBC algs original ivsize of removes ECB's ones.
On 6/11/2019 3:38 PM, Christophe Leroy wrote:
>
>
> Le 11/06/2019 à 13:57, Horia Geanta a écrit :
>> On 6/6/2019 2:31 PM, Christophe Leroy wrote:
>>> Next patch will require struct talitos_edesc to be defined
>>> earlier in talitos.c
>>>
>>> This patch moves it into talitos.h so that it can be
Le 11/06/2019 à 13:57, Horia Geanta a écrit :
On 6/6/2019 2:31 PM, Christophe Leroy wrote:
Next patch will require struct talitos_edesc to be defined
earlier in talitos.c
This patch moves it into talitos.h so that it can be used
from any place in talitos.c
Fixes: 37b5e8897eb5 ("crypto:
Hello POWER developers,
I'm trying to find out if there is an internal kernel API so that a
PCI driver can call it to check if its PCI device is running inside a
POWER9 machine. Alternatively, if that's not available, if it is
running on a machine with powerpc architecture.
I need this
On 6/6/2019 2:31 PM, Christophe Leroy wrote:
> This series is the last set of fixes for the Talitos driver.
>
> We now get a fully clean boot on both SEC1 (SEC1.2 on mpc885) and
> SEC2 (SEC2.2 on mpc8321E) with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
>
I get failures, probably due to patch 1/5:
alg:
On 6/6/2019 2:31 PM, Christophe Leroy wrote:
> Next patch will require struct talitos_edesc to be defined
> earlier in talitos.c
>
> This patch moves it into talitos.h so that it can be used
> from any place in talitos.c
>
> Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for
On 6/6/2019 2:31 PM, Christophe Leroy wrote:
> commit d84cc9c9524e ("crypto: talitos - fix ECB algs ivsize")
> wrongly modified CBC algs ivsize instead of ECB aggs ivsize.
>
> This restore the CBC algs original ivsize of removes ECB's ones.
>
> Signed-off-by: Christophe Leroy
> Fixes:
On Tue 04-06-19 14:43:54, Aneesh Kumar K.V wrote:
> This is needed so that we don't wrongly initialize a namespace
> which doesn't have enough space reserved for holding struct pages
> with the current kernel.
>
> We also increment PFN_MIN_VERSION to make sure that older kernel
> won't initialize
https://bugzilla.kernel.org/show_bug.cgi?id=203839
--- Comment #9 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Christophe Leroy from comment #8)
> Argh !
>
> CONFIG_SMP must (again) be the reason we missed it.
>
> Can you please try the change below ?
Applied your change on top of
On Tue, 2019-06-11 at 09:51 +0200, Christophe Leroy wrote:
>
> Le 11/06/2019 à 09:24, Michael Neuling a écrit :
> > On Tue, 2019-06-11 at 08:48 +0200, Cédric Le Goater wrote:
> > > On 11/06/2019 08:44, Michael Neuling wrote:
> > > > > > 2:
> > > > > > -BEGIN_FTR_SECTION
> > > > > > - /*
Hi Dan,
Any feedback on this?
A change I would like to get done on top of this series is
+ if (__le16_to_cpu(pfn_sb->version_minor) < 3) {
+ /*
+* For a large part we use PAGE_SIZE. But we
+* do have some accounting code using SZ_4K.
+
On Tue, 2019-06-11 at 09:54 +0200, Christoph Hellwig wrote:
> On Tue, Jun 11, 2019 at 04:59:54PM +1000, Benjamin Herrenschmidt
> wrote:
> > Ah stupid me ... it's dma_set_mask that failed, since it has no
> > idea
> > that the calling driver is limited to lowmem.
> >
> > That's also why the
On Tue, 11 Jun 2019 at 07:51, Naoya Horiguchi wrote:
>
> On Wed, May 29, 2019 at 04:31:01PM -0700, Mike Kravetz wrote:
> > On 5/28/19 2:49 AM, Wanpeng Li wrote:
> > > Cc Paolo,
> > > Hi all,
> > > On Wed, 14 Feb 2018 at 06:34, Mike Kravetz
> > > wrote:
> > >>
> > >> On 02/12/2018 06:48 PM,
On Tue, Jun 11, 2019 at 04:59:54PM +1000, Benjamin Herrenschmidt wrote:
> Ah stupid me ... it's dma_set_mask that failed, since it has no idea
> that the calling driver is limited to lowmem.
>
> That's also why the "wrong" patch worked.
>
> So yes, a ZONE_DMA at 30-bits will work, though it's
On Tue, Jun 11, 2019 at 04:58:12PM +1000, Benjamin Herrenschmidt wrote:
> ... which b43legacy doesn't set to the best of my knowledge ...
>
> Which makes me wonder how come it didn't work even with your patches ?
> AFAIK, we have less than 1GB of lowmem unless the config has been
> tweaked
Le 11/06/2019 à 09:24, Michael Neuling a écrit :
On Tue, 2019-06-11 at 08:48 +0200, Cédric Le Goater wrote:
On 11/06/2019 08:44, Michael Neuling wrote:
2:
-BEGIN_FTR_SECTION
- /* POWER9 with disabled DAWR */
+ LOAD_REG_ADDR(r11, dawr_force_enable)
+ lbz r11, 0(r11)
+
https://bugzilla.kernel.org/show_bug.cgi?id=203839
--- Comment #8 from Christophe Leroy (christophe.le...@c-s.fr) ---
Argh !
CONFIG_SMP must (again) be the reason we missed it.
Can you please try the change below ?
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
On Tue, 2019-06-11 at 08:48 +0200, Cédric Le Goater wrote:
> On 11/06/2019 08:44, Michael Neuling wrote:
> > > > 2:
> > > > -BEGIN_FTR_SECTION
> > > > - /* POWER9 with disabled DAWR */
> > > > + LOAD_REG_ADDR(r11, dawr_force_enable)
> > > > + lbz r11, 0(r11)
> > > > +
On Tue, 2019-06-11 at 16:58 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2019-06-11 at 08:08 +0200, Christoph Hellwig wrote:
> > On Tue, Jun 11, 2019 at 03:56:33PM +1000, Benjamin Herrenschmidt
> > wrote:
> > > The reason I think it sort-of-mostly-worked is that to get more
> > > than
> > > 1GB
On 06/11/2019 05:46 AM, Nicholas Piggin wrote:
> Anshuman Khandual's on June 10, 2019 6:53 pm:
>> On 06/10/2019 10:08 AM, Nicholas Piggin wrote:
>>> For platforms that define HAVE_ARCH_HUGE_VMAP, have vmap allow vmalloc to
>>> allocate huge pages and map them.
>>
>> IIUC that extends
On Tue, 2019-06-11 at 08:08 +0200, Christoph Hellwig wrote:
> On Tue, Jun 11, 2019 at 03:56:33PM +1000, Benjamin Herrenschmidt
> wrote:
> > The reason I think it sort-of-mostly-worked is that to get more
> > than
> > 1GB of RAM, those machines use CONFIG_HIGHMEM. And *most* network
> > buffers
On 11/06/2019 08:44, Michael Neuling wrote:
>
>>> 2:
>>> -BEGIN_FTR_SECTION
>>> - /* POWER9 with disabled DAWR */
>>> + LOAD_REG_ADDR(r11, dawr_force_enable)
>>> + lbz r11, 0(r11)
>>> + cmpdi r11, 0
>>> li r3, H_HARDWARE
>>> - blr
>>> -END_FTR_SECTION_IFCLR(CPU_FTR_DAWR)
Le 10/06/2019 à 05:08, Nicholas Piggin a écrit :
Radix can use ioremap_page_range for ioremap, after slab is available.
This makes it possible to enable huge ioremap mapping support.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/book3s/64/radix.h | 3 +++
> > 2:
> > -BEGIN_FTR_SECTION
> > - /* POWER9 with disabled DAWR */
> > + LOAD_REG_ADDR(r11, dawr_force_enable)
> > + lbz r11, 0(r11)
> > + cmpdi r11, 0
> > li r3, H_HARDWARE
> > - blr
> > -END_FTR_SECTION_IFCLR(CPU_FTR_DAWR)
> > + beqlr
>
> Why is this a 'beqlr' ?
It's useful being able to specify a different IMA template on appraise
policy rules, so allow it.
Signed-off-by: Thiago Jung Bauermann
Suggested-by: Mimi Zohar
---
security/integrity/ima/ima_policy.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Define new "d-modsig" template field which holds the digest that is
expected to match the one contained in the modsig, and also new "modsig"
template field which holds the appended file signature.
Add a new "ima-modsig" defined template descriptor with the new fields as
well as the ones from the
If the IMA template contains the "modsig" or "d-modsig" field, then the
modsig should be added to the measurement list when the file is appraised.
And that is what normally happens, but if a measurement rule caused a file
containing a modsig to be measured before a different rule causes it to be
Obtain the modsig and calculate its corresponding hash in
ima_collect_measurement().
Signed-off-by: Thiago Jung Bauermann
---
security/integrity/ima/ima.h | 8 -
security/integrity/ima/ima_api.c | 5 ++-
security/integrity/ima/ima_appraise.c | 2 +-
Implement the appraise_type=imasig|modsig option, allowing IMA to read and
verify modsig signatures.
In case a file has both an xattr signature and an appended modsig, IMA will
only use the appended signature if the key used by the xattr signature
isn't present in the IMA or platform keyring.
Verify xattr signature in a separate function so that the logic in
ima_appraise_measurement() remains clear when it gains the ability to also
verify an appended module signature.
The code in the switch statement is unchanged except for having to
dereference the status and cause variables (since
Introduce the modsig keyword to the IMA policy syntax to specify that
a given hook should expect the file to have the IMA signature appended
to it. Here is how it can be used in a rule:
appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig|modsig
With this rule, IMA will accept either a
This avoids a dependency cycle in soon-to-be-introduced
CONFIG_IMA_APPRAISE_MODSIG: it will select CONFIG_MODULE_SIG_FORMAT
which in turn selects CONFIG_KEYS. Kconfig then complains that
CONFIG_INTEGRITY_SIGNATURE depends on CONFIG_KEYS.
Signed-off-by: Thiago Jung Bauermann
Signed-off-by: Mimi
Designated initializers allow specifying only the members of the struct
that need initialization. Non-mentioned members are initialized to zero.
This makes the code a bit clearer (particularly in ima_add_boot_aggregate)
and also allows adding a new member to the struct without having to update
Even though struct evm_ima_xattr_data includes a fixed-size array to hold a
SHA1 digest, most of the code ignores the array and uses the struct to mean
"type indicator followed by data of unspecified size" and tracks the real
size of what the struct represents in a separate length variable.
The
IMA will need to access the digest of the PKCS7 message (as calculated by
the kernel) before the signature is verified, so introduce
pkcs7_get_digest() for that purpose.
Also, modify pkcs7_digest() to detect when the digest was already
calculated so that it doesn't have to do redundant work.
IMA will need to verify a PKCS#7 signature which has already been parsed.
For this reason, factor out the code which does that from
verify_pkcs7_signature() into a new function which takes a struct
pkcs7_message instead of a data buffer.
Signed-off-by: Thiago Jung Bauermann
Reviewed-by: Mimi
IMA will use the module_signature format for append signatures, so export
the relevant definitions and factor out the code which verifies that the
appended signature trailer is valid.
Also, create a CONFIG_MODULE_SIG_FORMAT option so that IMA can select it
and be able to use mod_check_sig()
Hello,
Nothing big in this version. Noteworthy changes are:
1. Fixes for two bugs in ima_appraise_measurements() which were spotted and
resolved by Mimi Zohar. The changelog points them out.
2. One bugfix in process_measurement() which would cause all files
appraised with modsig to be measured
Le 10/06/2019 à 05:08, Nicholas Piggin a écrit :
__ioremap_at error handling is wonky, it requires caller to clean up
after it. Implement a helper that does the map and error cleanup and
remove the requirement from the caller.
Signed-off-by: Nicholas Piggin
---
This series is a different
On 06/10/2019 08:14 PM, Nicholas Piggin wrote:
> Mark Rutland's on June 11, 2019 12:10 am:
>> Hi,
>>
>> On Mon, Jun 10, 2019 at 02:38:38PM +1000, Nicholas Piggin wrote:
>>> For platforms that define HAVE_ARCH_HUGE_VMAP, have vmap allow vmalloc to
>>> allocate huge pages and map them
>>>
>>>
On Tue, Jun 11, 2019 at 03:56:33PM +1000, Benjamin Herrenschmidt wrote:
> The reason I think it sort-of-mostly-worked is that to get more than
> 1GB of RAM, those machines use CONFIG_HIGHMEM. And *most* network
> buffers aren't allocated in Highmem so you got lucky.
>
> That said, there is
On Mon, Jun 10, 2019 at 11:09:47AM -0500, Larry Finger wrote:
>>> return -EIO;
>>>
>>> For b43legacy, dev->dma_mask is 0xc2656848.
>>> dma_supported(dev, mask) is 0xc08b, mask is 0x3fff, and
>>> the routine returns -EIO.
>>>
>>> For b43,
101 - 142 of 142 matches
Mail list logo
