* [PATCH V2] perf/x86: add more Intel uncore IMC PCI IDs for SkyLake
From: kan.liang @ 2016-11-08 18:54 UTC (permalink / raw)
To: peterz, mingo, tglx, linux-kernel
Cc: eranian, benjamin.widawsky, andi, Kan Liang
From: Kan Liang <kan.liang@intel.com>
Several uncore IMC PCI IDs are missed for Intel SkyLake.
Adds the PCI IDs for SkyLake Y, U, H and S platforms.
Rename the ID macros for 0x191f and 0x190c.
The issue has been logged in the kernel org bugzilla.
The bug id is 187301.
https://bugzilla.kernel.org/show_bug.cgi?id=187301
The related datasheets are also attached in the bug entry for permanent reference.
Reported-by: Ben Widawsky <benjamin.widawsky@intel.com>
Tested-by: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: Kan Liang <kan.liang@intel.com>
Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com>
---
Change since V1:
- Refine changelog
arch/x86/events/intel/uncore_snb.c | 32 ++++++++++++++++++++++++++++----
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/arch/x86/events/intel/uncore_snb.c b/arch/x86/events/intel/uncore_snb.c
index 5f845ee..81195cc 100644
--- a/arch/x86/events/intel/uncore_snb.c
+++ b/arch/x86/events/intel/uncore_snb.c
@@ -8,8 +8,12 @@
#define PCI_DEVICE_ID_INTEL_HSW_IMC 0x0c00
#define PCI_DEVICE_ID_INTEL_HSW_U_IMC 0x0a04
#define PCI_DEVICE_ID_INTEL_BDW_IMC 0x1604
-#define PCI_DEVICE_ID_INTEL_SKL_IMC 0x191f
-#define PCI_DEVICE_ID_INTEL_SKL_U_IMC 0x190c
+#define PCI_DEVICE_ID_INTEL_SKL_U_IMC 0x1904
+#define PCI_DEVICE_ID_INTEL_SKL_Y_IMC 0x190c
+#define PCI_DEVICE_ID_INTEL_SKL_HD_IMC 0x1900
+#define PCI_DEVICE_ID_INTEL_SKL_HQ_IMC 0x1910
+#define PCI_DEVICE_ID_INTEL_SKL_SD_IMC 0x190f
+#define PCI_DEVICE_ID_INTEL_SKL_SQ_IMC 0x191f
/* SNB event control */
#define SNB_UNC_CTL_EV_SEL_MASK 0x000000ff
@@ -616,13 +620,29 @@ static const struct pci_device_id bdw_uncore_pci_ids[] = {
static const struct pci_device_id skl_uncore_pci_ids[] = {
{ /* IMC */
- PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SKL_IMC),
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SKL_Y_IMC),
.driver_data = UNCORE_PCI_DEV_DATA(SNB_PCI_UNCORE_IMC, 0),
},
{ /* IMC */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SKL_U_IMC),
.driver_data = UNCORE_PCI_DEV_DATA(SNB_PCI_UNCORE_IMC, 0),
},
+ { /* IMC */
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SKL_HD_IMC),
+ .driver_data = UNCORE_PCI_DEV_DATA(SNB_PCI_UNCORE_IMC, 0),
+ },
+ { /* IMC */
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SKL_HQ_IMC),
+ .driver_data = UNCORE_PCI_DEV_DATA(SNB_PCI_UNCORE_IMC, 0),
+ },
+ { /* IMC */
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SKL_SD_IMC),
+ .driver_data = UNCORE_PCI_DEV_DATA(SNB_PCI_UNCORE_IMC, 0),
+ },
+ { /* IMC */
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SKL_SQ_IMC),
+ .driver_data = UNCORE_PCI_DEV_DATA(SNB_PCI_UNCORE_IMC, 0),
+ },
{ /* end: all zeroes */ },
};
@@ -666,8 +686,12 @@ static const struct imc_uncore_pci_dev desktop_imc_pci_ids[] = {
IMC_DEV(HSW_IMC, &hsw_uncore_pci_driver), /* 4th Gen Core Processor */
IMC_DEV(HSW_U_IMC, &hsw_uncore_pci_driver), /* 4th Gen Core ULT Mobile Processor */
IMC_DEV(BDW_IMC, &bdw_uncore_pci_driver), /* 5th Gen Core U */
- IMC_DEV(SKL_IMC, &skl_uncore_pci_driver), /* 6th Gen Core */
+ IMC_DEV(SKL_Y_IMC, &skl_uncore_pci_driver), /* 6th Gen Core Y */
IMC_DEV(SKL_U_IMC, &skl_uncore_pci_driver), /* 6th Gen Core U */
+ IMC_DEV(SKL_HD_IMC, &skl_uncore_pci_driver), /* 6th Gen Core H Dual Core */
+ IMC_DEV(SKL_HQ_IMC, &skl_uncore_pci_driver), /* 6th Gen Core H Quad Core */
+ IMC_DEV(SKL_SD_IMC, &skl_uncore_pci_driver), /* 6th Gen Core S Dual Core */
+ IMC_DEV(SKL_SQ_IMC, &skl_uncore_pci_driver), /* 6th Gen Core S Quad Core */
{ /* end marker */ }
};
--
2.5.5
^ permalink raw reply related
* Re: [PATCH] kvmtool: README: kernel config to support virtio-blk devices
From: Will Deacon @ 2016-11-08 18:55 UTC (permalink / raw)
To: Xingyou Chen; +Cc: kvm
In-Reply-To: <1478585309.21089.5.camel@gmail.com>
On Tue, Nov 08, 2016 at 02:08:29PM +0800, Xingyou Chen wrote:
> Kernel complains as:
> VFS: Cannot open root device "vda" or unknown-block(0,0): error -6
> when configured with CONFIG_VIRTIO_BLK=y according to README.
> CONFIG_SCSI_VIRTIO=y is also needed to bring guest into disk fs.
>
> Signed-off-by: Xingyou Chen <niatlantice@gmail.com>
>
> diff --git a/README b/README
> index 5501f05..a24b451 100644
> --- a/README
> +++ b/README
> @@ -56,6 +56,7 @@ linux-0.2.img.bz2
>
> - For virtio-blk devices (--disk, -d):
> CONFIG_VIRTIO_BLK=y
> + CONFIG_SCSI_VIRTIO=y
>
> - For virtio-net devices ([--network, -n] virtio):
> CONFIG_VIRTIO_NET=y
I don't know how you generated this, but please use git. It's missing
a cut between the commit log and the diff, as well as a diffstat.
Will
^ permalink raw reply
* [PATCH v3 3/3] ARM: dmaengine: sun6i: share the dma driver with sun50i
From: Maxime Ripard @ 2016-11-08 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107182840.GA3711@arx12>
On Tue, Nov 08, 2016 at 02:28:40AM +0800, Hao Zhang wrote:
> According to the datasheet, the dma of A64 support 8/16/32/64 bits
> so, we can add the condition of device compatible in convert_buswidth
> function and other place to determine the device whether is for A64,
> and then accept the 8 bytes bus width to it.
>
> Signed-off-by: Hao Zhang <hao5781286@gmail.com>
> ---
> drivers/dma/sun6i-dma.c | 43 +++++++++++++++++++++++++++++++++----------
> 1 file changed, 33 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index 8346199..8a95a1a 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -247,13 +247,17 @@ static inline s8 convert_burst(u32 maxburst)
> }
> }
>
> -static inline s8 convert_buswidth(enum dma_slave_buswidth addr_width)
> +static inline s8 convert_buswidth(enum dma_slave_buswidth addr_width,
> + struct sun6i_dma_dev *sdev)
> {
> - if ((addr_width < DMA_SLAVE_BUSWIDTH_1_BYTE) ||
> - (addr_width > DMA_SLAVE_BUSWIDTH_4_BYTES))
> + if (((addr_width >= DMA_SLAVE_BUSWIDTH_1_BYTE) &&
> + (addr_width <= DMA_SLAVE_BUSWIDTH_4_BYTES)) ||
> + ((addr_width == DMA_SLAVE_BUSWIDTH_8_BYTES) &&
> + (of_device_is_compatible(sdev->slave.dev->of_node,
> + "allwinner,sun50i-a64-dma"))))
> + return addr_width >> 1;
> + else
Just like for the burst (https://lkml.org/lkml/2016/10/4/367) I think
this should be taken care of in the the framework's
dmaengine_slave_config function.
This is quite easy to do in the width case, since you just have to
test whether what has been set in the dma_device has support for the
burst give in the configuration.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161108/df9a830d/attachment.sig>
^ permalink raw reply
* [U-Boot] [PATCH 3/4] image: Add crypto_algo struct for RSA info
From: aduda @ 2016-11-08 18:53 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20161108185329.56774-1-aduda@meraki.com>
From: Andrew Duda <aduda@meraki.com>
Cut down on the repetition of algorithm information by defining separate
checksum and crypto structs. image_sig_algos are now simply pairs of
unique checksum and crypto algos.
Signed-off-by: Andrew Duda <aduda@meraki.com>
Signed-off-by: aduda <aduda@meraki.com>
---
common/image-sig.c | 46 +++++++++++++++++++++++-----------------------
include/image.h | 9 +++++++--
lib/rsa/rsa-verify.c | 19 +++++++++++--------
tools/image-host.c | 9 +++++----
4 files changed, 46 insertions(+), 37 deletions(-)
diff --git a/common/image-sig.c b/common/image-sig.c
index 008d2c5..8b4314d 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -36,7 +36,6 @@ struct checksum_algo checksum_algos[] = {
SHA1_SUM_LEN,
SHA1_DER_LEN,
sha1_der_prefix,
- RSA2048_BYTES,
#if IMAGE_ENABLE_SIGN
EVP_sha1,
#endif
@@ -47,22 +46,28 @@ struct checksum_algo checksum_algos[] = {
SHA256_SUM_LEN,
SHA256_DER_LEN,
sha256_der_prefix,
- RSA2048_BYTES,
#if IMAGE_ENABLE_SIGN
EVP_sha256,
#endif
hash_calculate,
+ }
+
+};
+
+struct crypto_algo crypto_algos[] = {
+ {
+ "rsa2048",
+ RSA2048_BYTES,
+ rsa_sign,
+ rsa_add_verify_data,
+ rsa_verify,
},
{
- "sha256",
- SHA256_SUM_LEN,
- SHA256_DER_LEN,
- sha256_der_prefix,
+ "rsa4096",
RSA4096_BYTES,
-#if IMAGE_ENABLE_SIGN
- EVP_sha256,
-#endif
- hash_calculate,
+ rsa_sign,
+ rsa_add_verify_data,
+ rsa_verify,
}
};
@@ -70,24 +75,18 @@ struct checksum_algo checksum_algos[] = {
struct image_sig_algo image_sig_algos[] = {
{
"sha1,rsa2048",
- rsa_sign,
- rsa_add_verify_data,
- rsa_verify,
+ &crypto_algos[0],
&checksum_algos[0],
},
{
"sha256,rsa2048",
- rsa_sign,
- rsa_add_verify_data,
- rsa_verify,
+ &crypto_algos[0],
&checksum_algos[1],
},
{
"sha256,rsa4096",
- rsa_sign,
- rsa_add_verify_data,
- rsa_verify,
- &checksum_algos[2],
+ &crypto_algos[1],
+ &checksum_algos[1],
}
};
@@ -197,7 +196,8 @@ int fit_image_check_sig(const void *fit, int noffset, const void *data,
region.data = data;
region.size = size;
- if (info.algo->verify(&info, ®ion, 1, fit_value, fit_value_len)) {
+ if (info.algo->crypto->verify(&info, ®ion, 1, fit_value,
+ fit_value_len)) {
*err_msgp = "Verification failed";
return -1;
}
@@ -378,8 +378,8 @@ int fit_config_check_sig(const void *fit, int noffset, int required_keynode,
struct image_region region[count];
fit_region_make_list(fit, fdt_regions, count, region);
- if (info.algo->verify(&info, region, count, fit_value,
- fit_value_len)) {
+ if (info.algo->crypto->verify(&info, region, count, fit_value,
+ fit_value_len)) {
*err_msgp = "Verification failed";
return -1;
}
diff --git a/include/image.h b/include/image.h
index de73a07..c3c9866 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1072,7 +1072,6 @@ struct checksum_algo {
const int checksum_len;
const int der_len;
const uint8_t *der_prefix;
- const int key_len;
#if IMAGE_ENABLE_SIGN
const EVP_MD *(*calculate_sign)(void);
#endif
@@ -1081,8 +1080,9 @@ struct checksum_algo {
int region_count, uint8_t *checksum);
};
-struct image_sig_algo {
+struct crypto_algo {
const char *name; /* Name of algorithm */
+ const int key_len;
/**
* sign() - calculate and return signature for given input data
@@ -1131,7 +1131,12 @@ struct image_sig_algo {
int (*verify)(struct image_sign_info *info,
const struct image_region region[], int region_count,
uint8_t *sig, uint sig_len);
+};
+struct image_sig_algo {
+ const char *name;
+ /* pointer to cryptosystem algorithm */
+ struct crypto_algo *crypto;
/* pointer to checksum algorithm */
struct checksum_algo *checksum;
};
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index ee8988d..61dc4c2 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -68,14 +68,14 @@ static int rsa_verify_padding(const uint8_t *msg, const int pad_len,
* @sig: Signature
* @sig_len: Number of bytes in signature
* @hash: Pointer to the expected hash
- * @algo: Checksum algo structure having information on RSA padding etc.
+ * @key_len: Number of bytes in rsa key
+ * @algo: Checksum algo structure having information on DER encoding etc.
* @return 0 if verified, -ve on error
*/
static int rsa_verify_key(struct key_prop *prop, const uint8_t *sig,
const uint32_t sig_len, const uint8_t *hash,
- struct checksum_algo *algo)
+ const uint32_t key_len, struct checksum_algo *algo)
{
- const uint8_t *padding;
int pad_len;
int ret;
#if !defined(USE_HOSTCC)
@@ -117,7 +117,7 @@ static int rsa_verify_key(struct key_prop *prop, const uint8_t *sig,
return ret;
}
- pad_len = algo->key_len - algo->checksum_len;
+ pad_len = key_len - algo->checksum_len;
/* Check pkcs1.5 padding bytes. */
ret = rsa_verify_padding(buf, pad_len, algo);
@@ -183,7 +183,9 @@ static int rsa_verify_with_keynode(struct image_sign_info *info,
return -EFAULT;
}
- ret = rsa_verify_key(&prop, sig, sig_len, hash, info->algo->checksum);
+ ret = rsa_verify_key(&prop, sig, sig_len, hash,
+ info->algo->crypto->key_len,
+ info->algo->checksum);
return ret;
}
@@ -194,7 +196,7 @@ int rsa_verify(struct image_sign_info *info,
{
const void *blob = info->fdt_blob;
/* Reserve memory for maximum checksum-length */
- uint8_t hash[info->algo->checksum->key_len];
+ uint8_t hash[info->algo->crypto->key_len];
int ndepth, noffset;
int sig_node, node;
char name[100];
@@ -205,9 +207,10 @@ int rsa_verify(struct image_sign_info *info,
* rsa-signature-length
*/
if (info->algo->checksum->checksum_len >
- info->algo->checksum->key_len) {
+ info->algo->crypto->key_len) {
debug("%s: invlaid checksum-algorithm %s for %s\n",
- __func__, info->algo->checksum->name, info->algo->name);
+ __func__, info->algo->checksum->name,
+ info->algo->crypto->name);
return -EINVAL;
}
diff --git a/tools/image-host.c b/tools/image-host.c
index 1104695..dac85b4 100644
--- a/tools/image-host.c
+++ b/tools/image-host.c
@@ -213,7 +213,7 @@ static int fit_image_process_sig(const char *keydir, void *keydest,
node_name = fit_get_name(fit, noffset, NULL);
region.data = data;
region.size = size;
- ret = info.algo->sign(&info, ®ion, 1, &value, &value_len);
+ ret = info.algo->crypto->sign(&info, ®ion, 1, &value, &value_len);
if (ret) {
printf("Failed to sign '%s' signature node in '%s' image node: %d\n",
node_name, image_name, ret);
@@ -239,7 +239,7 @@ static int fit_image_process_sig(const char *keydir, void *keydest,
info.keyname = fdt_getprop(fit, noffset, "key-name-hint", NULL);
if (keydest)
- ret = info.algo->add_verify_data(&info, keydest);
+ ret = info.algo->crypto->add_verify_data(&info, keydest);
else
return -1;
@@ -588,7 +588,8 @@ static int fit_config_process_sig(const char *keydir, void *keydest,
require_keys ? "conf" : NULL))
return -1;
- ret = info.algo->sign(&info, region, region_count, &value, &value_len);
+ ret = info.algo->crypto->sign(&info, region, region_count, &value,
+ &value_len);
free(region);
if (ret) {
printf("Failed to sign '%s' signature node in '%s' conf node\n",
@@ -617,7 +618,7 @@ static int fit_config_process_sig(const char *keydir, void *keydest,
/* Write the public key into the supplied FDT file */
if (keydest) {
- ret = info.algo->add_verify_data(&info, keydest);
+ ret = info.algo->crypto->add_verify_data(&info, keydest);
if (ret == -ENOSPC)
return -ENOSPC;
if (ret) {
--
2.10.2
^ permalink raw reply related
* [U-Boot] [PATCH 4/4] image: Combine image_sig_algo with image_sign_info
From: aduda @ 2016-11-08 18:53 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20161108185329.56774-1-aduda@meraki.com>
From: Andrew Duda <aduda@meraki.com>
Remove the need to explicitly add SHA/RSA pairings. Invalid SHA/RSA
pairings will still fail on verify operations when the hash length is
longer than the key length.
Follow the same naming scheme "checksum,crytpo" without explicitly
defining the string.
Indirectly adds support for "sha1,rsa4096" signing/verification.
Signed-off-by: Andrew Duda <aduda@meraki.com>
Signed-off-by: aduda <aduda@meraki.com>
---
common/image-sig.c | 57 ++++++++++++++++++++++++++++------------------------
include/image.h | 24 ++++++++++++----------
lib/rsa/rsa-sign.c | 4 ++--
lib/rsa/rsa-verify.c | 14 ++++++-------
tools/image-host.c | 16 ++++++++-------
5 files changed, 61 insertions(+), 54 deletions(-)
diff --git a/common/image-sig.c b/common/image-sig.c
index 8b4314d..455f2b9 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -72,32 +72,36 @@ struct crypto_algo crypto_algos[] = {
};
-struct image_sig_algo image_sig_algos[] = {
- {
- "sha1,rsa2048",
- &crypto_algos[0],
- &checksum_algos[0],
- },
- {
- "sha256,rsa2048",
- &crypto_algos[0],
- &checksum_algos[1],
- },
- {
- "sha256,rsa4096",
- &crypto_algos[1],
- &checksum_algos[1],
+struct checksum_algo *image_get_checksum_algo(const char *full_name)
+{
+ int i;
+ const char *name;
+
+ for (i = 0; i < ARRAY_SIZE(checksum_algos); i++) {
+ name = checksum_algos[i].name;
+ /* Make sure names match and next char is a comma */
+ if (!strncmp(name, full_name, strlen(name)) &&
+ full_name[strlen(name)] == ',')
+ return &checksum_algos[i];
}
-};
+ return NULL;
+}
-struct image_sig_algo *image_get_sig_algo(const char *name)
+struct crypto_algo *image_get_crypto_algo(const char *full_name)
{
int i;
+ const char *name;
+
+ /* Move name to after the comma */
+ name = strchr(full_name, ',');
+ if (!name)
+ return NULL;
+ name += 1;
- for (i = 0; i < ARRAY_SIZE(image_sig_algos); i++) {
- if (!strcmp(image_sig_algos[i].name, name))
- return &image_sig_algos[i];
+ for (i = 0; i < ARRAY_SIZE(crypto_algos); i++) {
+ if (!strcmp(crypto_algos[i].name, name))
+ return &crypto_algos[i];
}
return NULL;
@@ -161,12 +165,14 @@ static int fit_image_setup_verify(struct image_sign_info *info,
info->keyname = fdt_getprop(fit, noffset, "key-name-hint", NULL);
info->fit = (void *)fit;
info->node_offset = noffset;
- info->algo = image_get_sig_algo(algo_name);
+ info->name = algo_name;
+ info->checksum = image_get_checksum_algo(algo_name);
+ info->crypto = image_get_crypto_algo(algo_name);
info->fdt_blob = gd_fdt_blob();
info->required_keynode = required_keynode;
printf("%s:%s", algo_name, info->keyname);
- if (!info->algo) {
+ if (!info->checksum || !info->crypto) {
*err_msgp = "Unknown signature algorithm";
return -1;
}
@@ -196,8 +202,7 @@ int fit_image_check_sig(const void *fit, int noffset, const void *data,
region.data = data;
region.size = size;
- if (info.algo->crypto->verify(&info, ®ion, 1, fit_value,
- fit_value_len)) {
+ if (info.crypto->verify(&info, ®ion, 1, fit_value, fit_value_len)) {
*err_msgp = "Verification failed";
return -1;
}
@@ -378,8 +383,8 @@ int fit_config_check_sig(const void *fit, int noffset, int required_keynode,
struct image_region region[count];
fit_region_make_list(fit, fdt_regions, count, region);
- if (info.algo->crypto->verify(&info, region, count, fit_value,
- fit_value_len)) {
+ if (info.crypto->verify(&info, region, count, fit_value,
+ fit_value_len)) {
*err_msgp = "Verification failed";
return -1;
}
diff --git a/include/image.h b/include/image.h
index c3c9866..8131595 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1049,7 +1049,9 @@ struct image_sign_info {
const char *keyname; /* Name of key to use */
void *fit; /* Pointer to FIT blob */
int node_offset; /* Offset of signature node */
- struct image_sig_algo *algo; /* Algorithm information */
+ const char *name; /* Algorithm name */
+ struct checksum_algo *checksum; /* Checksum algorithm information */
+ struct crypto_algo *crypto; /* Crypto algorithm information */
const void *fdt_blob; /* FDT containing public keys */
int required_keynode; /* Node offset of key to use: -1=any */
const char *require_keys; /* Value for 'required' property */
@@ -1133,21 +1135,21 @@ struct crypto_algo {
uint8_t *sig, uint sig_len);
};
-struct image_sig_algo {
- const char *name;
- /* pointer to cryptosystem algorithm */
- struct crypto_algo *crypto;
- /* pointer to checksum algorithm */
- struct checksum_algo *checksum;
-};
+/**
+ * image_get_checksum_algo() - Look up a checksum algorithm
+ *
+ * @param full_name Name of algorithm in the form "checksum,crypto"
+ * @return pointer to algorithm information, or NULL if not found
+ */
+struct checksum_algo *image_get_checksum_algo(const char *full_name);
/**
- * image_get_sig_algo() - Look up a signature algortihm
+ * image_get_crypto_algo() - Look up a cryptosystem algorithm
*
- * @param name Name of algorithm
+ * @param full_name Name of algorithm in the form "checksum,crypto"
* @return pointer to algorithm information, or NULL if not found
*/
-struct image_sig_algo *image_get_sig_algo(const char *name);
+struct crypto_algo *image_get_crypto_algo(const char *full_name);
/**
* fit_image_verify_required_sigs() - Verify signatures marked as 'required'
diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
index c26f741..9a09280 100644
--- a/lib/rsa/rsa-sign.c
+++ b/lib/rsa/rsa-sign.c
@@ -244,7 +244,7 @@ int rsa_sign(struct image_sign_info *info,
ret = rsa_get_priv_key(info->keydir, info->keyname, &rsa);
if (ret)
goto err_priv;
- ret = rsa_sign_with_key(rsa, info->algo->checksum, region,
+ ret = rsa_sign_with_key(rsa, info->checksum, region,
region_count, sigp, sig_len);
if (ret)
goto err_sign;
@@ -508,7 +508,7 @@ int rsa_add_verify_data(struct image_sign_info *info, void *keydest)
}
if (!ret) {
ret = fdt_setprop_string(keydest, node, FIT_ALGO_PROP,
- info->algo->name);
+ info->name);
}
if (!ret && info->require_keys) {
ret = fdt_setprop_string(keydest, node, "required",
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index 61dc4c2..0d548f8 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -184,8 +184,7 @@ static int rsa_verify_with_keynode(struct image_sign_info *info,
}
ret = rsa_verify_key(&prop, sig, sig_len, hash,
- info->algo->crypto->key_len,
- info->algo->checksum);
+ info->crypto->key_len, info->checksum);
return ret;
}
@@ -196,7 +195,7 @@ int rsa_verify(struct image_sign_info *info,
{
const void *blob = info->fdt_blob;
/* Reserve memory for maximum checksum-length */
- uint8_t hash[info->algo->crypto->key_len];
+ uint8_t hash[info->crypto->key_len];
int ndepth, noffset;
int sig_node, node;
char name[100];
@@ -206,11 +205,10 @@ int rsa_verify(struct image_sign_info *info,
* Verify that the checksum-length does not exceed the
* rsa-signature-length
*/
- if (info->algo->checksum->checksum_len >
- info->algo->crypto->key_len) {
+ if (info->checksum->checksum_len >
+ info->crypto->key_len) {
debug("%s: invlaid checksum-algorithm %s for %s\n",
- __func__, info->algo->checksum->name,
- info->algo->crypto->name);
+ __func__, info->checksum->name, info->crypto->name);
return -EINVAL;
}
@@ -221,7 +219,7 @@ int rsa_verify(struct image_sign_info *info,
}
/* Calculate checksum with checksum-algorithm */
- ret = info->algo->checksum->calculate(info->algo->checksum->name,
+ ret = info->checksum->calculate(info->checksum->name,
region, region_count, hash);
if (ret < 0) {
debug("%s: Error in checksum calculation\n", __func__);
diff --git a/tools/image-host.c b/tools/image-host.c
index dac85b4..c1a0122 100644
--- a/tools/image-host.c
+++ b/tools/image-host.c
@@ -166,9 +166,11 @@ static int fit_image_setup_sig(struct image_sign_info *info,
info->keyname = fdt_getprop(fit, noffset, "key-name-hint", NULL);
info->fit = fit;
info->node_offset = noffset;
- info->algo = image_get_sig_algo(algo_name);
+ info->name = algo_name;
+ info->checksum = image_get_checksum_algo(algo_name);
+ info->crypto = image_get_crypto_algo(algo_name);
info->require_keys = require_keys;
- if (!info->algo) {
+ if (!info->checksum || !info->crypto) {
printf("Unsupported signature algorithm (%s) for '%s' signature node in '%s' image node\n",
algo_name, node_name, image_name);
return -1;
@@ -213,7 +215,7 @@ static int fit_image_process_sig(const char *keydir, void *keydest,
node_name = fit_get_name(fit, noffset, NULL);
region.data = data;
region.size = size;
- ret = info.algo->crypto->sign(&info, ®ion, 1, &value, &value_len);
+ ret = info.crypto->sign(&info, ®ion, 1, &value, &value_len);
if (ret) {
printf("Failed to sign '%s' signature node in '%s' image node: %d\n",
node_name, image_name, ret);
@@ -239,7 +241,7 @@ static int fit_image_process_sig(const char *keydir, void *keydest,
info.keyname = fdt_getprop(fit, noffset, "key-name-hint", NULL);
if (keydest)
- ret = info.algo->crypto->add_verify_data(&info, keydest);
+ ret = info.crypto->add_verify_data(&info, keydest);
else
return -1;
@@ -588,8 +590,8 @@ static int fit_config_process_sig(const char *keydir, void *keydest,
require_keys ? "conf" : NULL))
return -1;
- ret = info.algo->crypto->sign(&info, region, region_count, &value,
- &value_len);
+ ret = info.crypto->sign(&info, region, region_count, &value,
+ &value_len);
free(region);
if (ret) {
printf("Failed to sign '%s' signature node in '%s' conf node\n",
@@ -618,7 +620,7 @@ static int fit_config_process_sig(const char *keydir, void *keydest,
/* Write the public key into the supplied FDT file */
if (keydest) {
- ret = info.algo->crypto->add_verify_data(&info, keydest);
+ ret = info.crypto->add_verify_data(&info, keydest);
if (ret == -ENOSPC)
return -ENOSPC;
if (ret) {
--
2.10.2
^ permalink raw reply related
* [U-Boot] [PATCH 2/4] rsa: Verify RSA padding programatically
From: aduda @ 2016-11-08 18:53 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20161108185329.56774-1-aduda@meraki.com>
From: Andrew Duda <aduda@meraki.com>
Padding verification was done against static SHA/RSA pair arrays which
take up a lot of static memory, are mostly 0xff, and cannot be reused
for additional SHA/RSA pairings. The padding can be easily computed
according to PKCS#1v2.1 as:
EM = 0x00 || 0x01 || PS || 0x00 || T
where PS is (emLen - tLen - 3) octets of 0xff and T is DER encoding
of the hash.
Store DER prefix in checksum_algo and create rsa_verify_padding
function to handle verification of a message for any SHA/RSA pairing.
Signed-off-by: Andrew Duda <aduda@meraki.com>
Signed-off-by: aduda <aduda@meraki.com>
---
common/image-sig.c | 9 ++--
include/image.h | 3 +-
include/u-boot/rsa-checksum.h | 4 --
include/u-boot/sha1.h | 3 ++
include/u-boot/sha256.h | 3 ++
lib/rsa/rsa-checksum.c | 121 ------------------------------------------
lib/rsa/rsa-verify.c | 38 ++++++++++++-
lib/sha1.c | 5 ++
lib/sha256.c | 6 +++
9 files changed, 61 insertions(+), 131 deletions(-)
diff --git a/common/image-sig.c b/common/image-sig.c
index 28f7a20..008d2c5 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -34,32 +34,35 @@ struct checksum_algo checksum_algos[] = {
{
"sha1",
SHA1_SUM_LEN,
+ SHA1_DER_LEN,
+ sha1_der_prefix,
RSA2048_BYTES,
#if IMAGE_ENABLE_SIGN
EVP_sha1,
#endif
hash_calculate,
- padding_sha1_rsa2048,
},
{
"sha256",
SHA256_SUM_LEN,
+ SHA256_DER_LEN,
+ sha256_der_prefix,
RSA2048_BYTES,
#if IMAGE_ENABLE_SIGN
EVP_sha256,
#endif
hash_calculate,
- padding_sha256_rsa2048,
},
{
"sha256",
SHA256_SUM_LEN,
+ SHA256_DER_LEN,
+ sha256_der_prefix,
RSA4096_BYTES,
#if IMAGE_ENABLE_SIGN
EVP_sha256,
#endif
hash_calculate,
- padding_sha256_rsa4096,
}
};
diff --git a/include/image.h b/include/image.h
index bfe10a0..de73a07 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1070,6 +1070,8 @@ struct image_region {
struct checksum_algo {
const char *name;
const int checksum_len;
+ const int der_len;
+ const uint8_t *der_prefix;
const int key_len;
#if IMAGE_ENABLE_SIGN
const EVP_MD *(*calculate_sign)(void);
@@ -1077,7 +1079,6 @@ struct checksum_algo {
int (*calculate)(const char *name,
const struct image_region region[],
int region_count, uint8_t *checksum);
- const uint8_t *rsa_padding;
};
struct image_sig_algo {
diff --git a/include/u-boot/rsa-checksum.h b/include/u-boot/rsa-checksum.h
index 3c69d85..c240720 100644
--- a/include/u-boot/rsa-checksum.h
+++ b/include/u-boot/rsa-checksum.h
@@ -12,10 +12,6 @@
#include <u-boot/sha1.h>
#include <u-boot/sha256.h>
-extern const uint8_t padding_sha256_rsa4096[];
-extern const uint8_t padding_sha256_rsa2048[];
-extern const uint8_t padding_sha1_rsa2048[];
-
/**
* hash_calculate() - Calculate hash over the data
*
diff --git a/include/u-boot/sha1.h b/include/u-boot/sha1.h
index b0d9ce9..2634a29 100644
--- a/include/u-boot/sha1.h
+++ b/include/u-boot/sha1.h
@@ -21,6 +21,9 @@ extern "C" {
#define SHA1_SUM_POS -0x20
#define SHA1_SUM_LEN 20
+#define SHA1_DER_LEN 15
+
+extern const uint8_t sha1_der_prefix[];
/**
* \brief SHA-1 context structure
diff --git a/include/u-boot/sha256.h b/include/u-boot/sha256.h
index beadab3..9aa1251 100644
--- a/include/u-boot/sha256.h
+++ b/include/u-boot/sha256.h
@@ -2,6 +2,9 @@
#define _SHA256_H
#define SHA256_SUM_LEN 32
+#define SHA256_DER_LEN 19
+
+extern const uint8_t sha256_der_prefix[];
/* Reset watchdog each time we process this many bytes */
#define CHUNKSZ_SHA256 (64 * 1024)
diff --git a/lib/rsa/rsa-checksum.c b/lib/rsa/rsa-checksum.c
index db183ff..2bf28e2 100644
--- a/lib/rsa/rsa-checksum.c
+++ b/lib/rsa/rsa-checksum.c
@@ -13,130 +13,9 @@
#include <hash.h>
#else
#include "fdt_host.h"
-#include <u-boot/sha1.h>
-#include <u-boot/sha256.h>
#endif
#include <u-boot/rsa.h>
-/* PKCS 1.5 paddings as described in the RSA PKCS#1 v2.1 standard. */
-
-const uint8_t padding_sha256_rsa2048[RSA2048_BYTES - SHA256_SUM_LEN] = {
-0x00, 0x01, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x30, 0x31, 0x30,
-0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05,
-0x00, 0x04, 0x20
-};
-
-const uint8_t padding_sha1_rsa2048[RSA2048_BYTES - SHA1_SUM_LEN] = {
- 0x00, 0x01, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0x00, 0x30, 0x21, 0x30,
- 0x09, 0x06, 0x05, 0x2b, 0x0e, 0x03, 0x02, 0x1a,
- 0x05, 0x00, 0x04, 0x14
-};
-
-const uint8_t padding_sha256_rsa4096[RSA4096_BYTES - SHA256_SUM_LEN] = {
- 0x00, 0x01, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0x00, 0x30, 0x31, 0x30,
- 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65,
- 0x03, 0x04, 0x02, 0x01, 0x05, 0x00, 0x04, 0x20
-};
-
int hash_calculate(const char *name,
const struct image_region region[],
int region_count, uint8_t *checksum)
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index 5418f59..ee8988d 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -25,6 +25,40 @@
#define RSA_DEFAULT_PUBEXP 65537
/**
+ * rsa_verify_padding() - Verify RSA message padding is valid
+ *
+ * Verify a RSA message's padding is consistent with PKCS1.5
+ * padding as described in the RSA PKCS#1 v2.1 standard.
+ *
+ * @msg: Padded message
+ * @pad_len: Number of expected padding bytes
+ * @algo: Checksum algo structure having information on DER encoding etc.
+ * @return 0 on success, != 0 on failure
+ */
+static int rsa_verify_padding(const uint8_t *msg, const int pad_len,
+ struct checksum_algo *algo)
+{
+ int ff_len;
+ int ret;
+
+ /* first byte must be 0x00 */
+ ret = *msg++;
+ /* second byte must be 0x01 */
+ ret |= *msg++ ^ 0x01;
+ /* next ff_len bytes must be 0xff */
+ ff_len = pad_len - algo->der_len - 3;
+ ret |= *msg ^ 0xff;
+ ret |= memcmp(msg, msg+1, ff_len-1);
+ msg += ff_len;
+ /* next byte must be 0x00 */
+ ret |= *msg++;
+ /* next der_len bytes must match der_prefix */
+ ret |= memcmp(msg, algo->der_prefix, algo->der_len);
+
+ return ret;
+}
+
+/**
* rsa_verify_key() - Verify a signature against some data using RSA Key
*
* Verify a RSA PKCS1.5 signature against an expected hash using
@@ -83,11 +117,11 @@ static int rsa_verify_key(struct key_prop *prop, const uint8_t *sig,
return ret;
}
- padding = algo->rsa_padding;
pad_len = algo->key_len - algo->checksum_len;
/* Check pkcs1.5 padding bytes. */
- if (memcmp(buf, padding, pad_len)) {
+ ret = rsa_verify_padding(buf, pad_len, algo);
+ if (ret) {
debug("In RSAVerify(): Padding check failed!\n");
return -EINVAL;
}
diff --git a/lib/sha1.c b/lib/sha1.c
index 72c5dea..f54bb5b 100644
--- a/lib/sha1.c
+++ b/lib/sha1.c
@@ -26,6 +26,11 @@
#include <watchdog.h>
#include <u-boot/sha1.h>
+const uint8_t sha1_der_prefix[SHA1_DER_LEN] = {
+ 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0e,
+ 0x03, 0x02, 0x1a, 0x05, 0x00, 0x04, 0x14
+};
+
/*
* 32-bit integer manipulation macros (big endian)
*/
diff --git a/lib/sha256.c b/lib/sha256.c
index bb338ba..7f5a361 100644
--- a/lib/sha256.c
+++ b/lib/sha256.c
@@ -15,6 +15,12 @@
#include <watchdog.h>
#include <u-boot/sha256.h>
+const uint8_t sha256_der_prefix[SHA256_DER_LEN] = {
+ 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
+ 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05,
+ 0x00, 0x04, 0x20
+};
+
/*
* 32-bit integer manipulation macros (big endian)
*/
--
2.10.2
^ permalink raw reply related
* [U-Boot] [PATCH 1/4] rsa: cosmetic: rename pad_len to key_len
From: aduda @ 2016-11-08 18:53 UTC (permalink / raw)
To: u-boot
From: Andrew Duda <aduda@meraki.com>
checksum_algo's pad_len field isn't actually used to store the length of
the padding but the total length of the RSA key (msg_len + pad_len)
Signed-off-by: Andrew Duda <aduda@meraki.com>
Signed-off-by: aduda <aduda@meraki.com>
---
include/image.h | 2 +-
lib/rsa/rsa-verify.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/image.h b/include/image.h
index 2b1296c..bfe10a0 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1070,7 +1070,7 @@ struct image_region {
struct checksum_algo {
const char *name;
const int checksum_len;
- const int pad_len;
+ const int key_len;
#if IMAGE_ENABLE_SIGN
const EVP_MD *(*calculate_sign)(void);
#endif
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index 442b769..5418f59 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -84,7 +84,7 @@ static int rsa_verify_key(struct key_prop *prop, const uint8_t *sig,
}
padding = algo->rsa_padding;
- pad_len = algo->pad_len - algo->checksum_len;
+ pad_len = algo->key_len - algo->checksum_len;
/* Check pkcs1.5 padding bytes. */
if (memcmp(buf, padding, pad_len)) {
@@ -160,7 +160,7 @@ int rsa_verify(struct image_sign_info *info,
{
const void *blob = info->fdt_blob;
/* Reserve memory for maximum checksum-length */
- uint8_t hash[info->algo->checksum->pad_len];
+ uint8_t hash[info->algo->checksum->key_len];
int ndepth, noffset;
int sig_node, node;
char name[100];
@@ -171,7 +171,7 @@ int rsa_verify(struct image_sign_info *info,
* rsa-signature-length
*/
if (info->algo->checksum->checksum_len >
- info->algo->checksum->pad_len) {
+ info->algo->checksum->key_len) {
debug("%s: invlaid checksum-algorithm %s for %s\n",
__func__, info->algo->checksum->name, info->algo->name);
return -EINVAL;
--
2.10.2
^ permalink raw reply related
* [xen-unstable baseline-only test] 68011: regressions - FAIL
From: Platform Team regression test user @ 2016-11-08 18:52 UTC (permalink / raw)
To: xen-devel, osstest-admin
This run is configured for baseline tests only.
flight 68011 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68011/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pair 9 xen-boot/src_host fail REGR. vs. 68002
test-amd64-amd64-qemuu-nested-amd 6 xen-boot fail REGR. vs. 68002
test-amd64-amd64-xl-qemuu-debianhvm-amd64 20 leak-check/check fail REGR. vs. 68002
Regressions which are regarded as allowable (not blocking):
test-xtf-amd64-amd64-5 10 xtf-fep fail like 68002
test-xtf-amd64-amd64-1 10 xtf-fep fail like 68002
test-xtf-amd64-amd64-2 10 xtf-fep fail like 68002
test-xtf-amd64-amd64-3 10 xtf-fep fail like 68002
test-xtf-amd64-amd64-4 10 xtf-fep fail like 68002
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 68002
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 68002
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 9 windows-install fail like 68002
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail like 68002
Tests which did not succeed, but are not blocking:
test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a
test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a
build-i386-rumprun 6 xen-build fail never pass
build-amd64-rumprun 6 xen-build fail never pass
test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt 12 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass
test-armhf-armhf-libvirt 14 guest-saverestore fail never pass
test-armhf-armhf-xl-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 13 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-xsm 14 guest-saverestore fail never pass
test-armhf-armhf-xl 12 migrate-support-check fail never pass
test-armhf-armhf-xl-midway 12 migrate-support-check fail never pass
test-armhf-armhf-xl-midway 13 saverestore-support-check fail never pass
test-armhf-armhf-xl 13 saverestore-support-check fail never pass
test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass
test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass
test-amd64-i386-libvirt 12 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 12 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 13 saverestore-support-check fail never pass
test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-raw 11 migrate-support-check fail never pass
test-armhf-armhf-libvirt-raw 13 guest-saverestore fail never pass
test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail never pass
test-armhf-armhf-libvirt-qcow2 13 guest-saverestore fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 11 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 12 saverestore-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass
version targeted for testing:
xen 8a35a95615b1a64c98c30195f343bc2c58054d9d
baseline version:
xen 3ebe9a1a826e8d569bef6045777cc01a5699933d
Last test of basis 68002 2016-11-05 12:44:12 Z 3 days
Testing same since 68011 2016-11-08 04:50:39 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Daniel De Graaf <dgdegra@tycho.nsa.gov>
Jan Beulich <jbeulich@suse.com>
Wei Liu <wei.liu2@citrix.com>
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64-xtf pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumprun fail
build-i386-rumprun fail
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm fail
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-armhf-armhf-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvh-amd fail
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumprun-amd64 blocked
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumprun-i386 blocked
test-amd64-amd64-qemuu-nested-intel fail
test-amd64-amd64-xl-pvh-intel fail
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt pass
test-armhf-armhf-xl-midway pass
test-amd64-amd64-migrupgrade pass
test-amd64-i386-migrupgrade pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair fail
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-armhf-armhf-libvirt-qcow2 fail
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw fail
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
test-amd64-amd64-xl-qemut-winxpsp3 pass
test-amd64-i386-xl-qemut-winxpsp3 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3 pass
------------------------------------------------------------
sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images
Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Push not applicable.
------------------------------------------------------------
commit 8a35a95615b1a64c98c30195f343bc2c58054d9d
Author: Jan Beulich <jbeulich@suse.com>
Date: Mon Nov 7 14:08:30 2016 +0100
x86/shutdown: add fall-through comment
Coverity ID: 1362037
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
commit 7b2842a414204842b0fb5b2c95d457bc6071f994
Author: Jan Beulich <jbeulich@suse.com>
Date: Mon Nov 7 14:08:05 2016 +0100
IOMMU: replace ASSERT()s checking for NULL
Avoid NULL derefs on non-debug builds.
Coverity ID: 1055650
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
commit 4d86f9c099850d674dfb0f6877c76eb40eeaffc7
Author: Jan Beulich <jbeulich@suse.com>
Date: Mon Nov 7 14:07:11 2016 +0100
x86/traps: replace ASSERT() checking array bounds
Avoid out of bounds accesses on non-debug builds.
Coverity ID: 1055744
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
commit 8ad651705cbd0ad192398c1513d12c02b3197fa1
Author: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri Nov 4 11:35:20 2016 -0400
xsm: add missing permissions discovered in testing
Add two missing allow rules:
1. Device model domain construction uses getvcpucontext, discovered by
Andrew Cooper while chasing an unrelated issue.
2. When a domain is destroyed with a device passthrough active, the
calls to remove_{irq,ioport,iomem} can be made by the hypervisor itself
(which results in an XSM check with the source xen_t). It does not make
sense to deny these permissions; no domain should be using xen_t, and
forbidding the hypervisor from performing cleanup is not useful.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
(qemu changes not included)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH 3/3] multipathd: Add 'sysfs' prioritizer
From: Xose Vazquez Perez @ 2016-11-08 18:52 UTC (permalink / raw)
To: Hannes Reinecke; +Cc: dm-devel
In-Reply-To: <1468565337-5178-4-git-send-email-hare@suse.de>
On 07/15/2016 08:48 AM, Hannes Reinecke wrote:
> Recent kernels have an 'access_state' attribute which allows
> us to read the asymmetric access state directly from sysfs.
Hi Hannes,
with this patch it's impossible to select/autodetect ALUA.
sysfs always takes precedence over alua.
"detect_prio no" was added to overrides section, to make
it work again.
SLES 12-SP2
Thank you.
> ---
> libmultipath/discovery.c | 33 +++++++++++++++++++++
> libmultipath/discovery.h | 2 ++
> libmultipath/prio.h | 1 +
> libmultipath/prioritizers/Makefile | 3 +-
> libmultipath/prioritizers/sysfs.c | 61 ++++++++++++++++++++++++++++++++++++++
> libmultipath/propsel.c | 6 +++-
> multipath/multipath.conf.5 | 19 ++++++++++--
> 7 files changed, 120 insertions(+), 5 deletions(-)
> create mode 100644 libmultipath/prioritizers/sysfs.c
>
[ ...]
> diff --git a/libmultipath/propsel.c b/libmultipath/propsel.c
> index beb0798..0caf269 100644
> --- a/libmultipath/propsel.c
> +++ b/libmultipath/propsel.c
> @@ -375,6 +375,8 @@ detect_prio(struct config *conf, struct path * pp)
> struct prio *p = &pp->prio;
> int tpgs = 0;
> unsigned int timeout = conf->checker_timeout;
> + char buff[512];
> + char *default_prio = PRIO_ALUA;
>
> if ((tpgs = get_target_port_group_support(pp->fd, timeout)) <= 0)
> return;
> @@ -384,7 +386,9 @@ detect_prio(struct config *conf, struct path * pp)
> return;
> if (get_asymmetric_access_state(pp->fd, ret, timeout) < 0)
> return;
> - prio_get(conf->multipath_dir, p, PRIO_ALUA, DEFAULT_PRIO_ARGS);
> + if (sysfs_get_asymmetric_access_state(pp, buff, 512) >= 0)
> + default_prio = PRIO_SYSFS;
> + prio_get(conf->multipath_dir, p, default_prio, DEFAULT_PRIO_ARGS);
> }
^ permalink raw reply
* Re: [RFC v3 1/6] Track the active utilisation
From: Juri Lelli @ 2016-11-08 18:53 UTC (permalink / raw)
To: Luca Abeni
Cc: linux-kernel, Peter Zijlstra, Ingo Molnar, Claudio Scordino,
Steven Rostedt
In-Reply-To: <20161108191730.29c54a98@utopia>
On 08/11/16 19:17, Luca Abeni wrote:
> Hi Juri,
>
> On Tue, 8 Nov 2016 17:56:35 +0000
> Juri Lelli <juri.lelli@arm.com> wrote:
> [...]
> > > > > static void switched_to_dl(struct rq *rq, struct task_struct
> > > > > *p) {
> > > > > + add_running_bw(&p->dl, &rq->dl);
> > > > >
> > > > > /* If p is not queued we will update its parameters at
> > > > > next wakeup. */ if (!task_on_rq_queued(p))
> > > >
> > > > Don't we also need to remove bw in task_dead_dl()?
> > > I think task_dead_dl() is invoked after invoking dequeue_task_dl(),
> > > which takes care of this... Or am I wrong? (I think I explicitly
> > > tested this, and modifications to task_dead_dl() turned out to be
> > > unneeded)
> > >
> >
> > Mmm. You explicitly check that TASK_ON_RQ_MIGRATING or DEQUEUE_SLEEP
> > (which btw can be actually put together with an or condition), so I
> > don't think that any of those turn out to be true when the task dies.
> I might be very wrong here, but I think do_exit() just does something
> like
> tsk->state = TASK_DEAD;
> and then invokes schedule(), and __schedule() does
> if (!preempt && prev->state) {
> if (unlikely(signal_pending_state(prev->state, prev))) {
> prev->state = TASK_RUNNING;
> } else {
> deactivate_task(rq, prev, DEQUEUE_SLEEP);
> [...]
> so dequeue_task_dl() will see DEQUEUE_SLEEP... Or am I misunderstanding
> what you are saying?
>
> > Also, AFAIU, do_exit() works on current and the TASK_DEAD case is
> > handled in finish_task_switch(), so I don't think we are taking care
> > of the "task is dying" condition.
> Ok, so I am missing something... The state is set to TASK_DEAD, and
> then schedule() is called... So, __schedule() sees the dying task as
> "prev" and invokes deactivate_task() with the DEQUEUE_SLEEP flag...
> After that, finish_task_switch() calls task_dead_dl(). Is this wrong?
> If not, why aren't we taking care of the "task is dying" condition?
>
No, I think you are right. But, semantically this cleanup goes in
task_dead_dl(), IMHO. It's most probably moot if it complicates things,
but it might be helpful to differentiate the case between a task that is
actually going to sleep (and for which we want to activate the timer)
and a task that is dying (and for which we want to release bw
immediately). So, it actually matters for next patch, not here. But,
maybe we want to do things clean from start?
>
> > Peter, does what I'm saying make any sense? :)
> >
> > I still have to set up things here to test these patches (sorry, I was
> > travelling), but could you try to create some tasks and that kill them
> > from another shell to see if the accounting deviates or not? Or did
> > you already do this test?
> I think this is one of the tests I tried...
> I have to check if I changed this code after the test (but I do not
> think I did). Anyway, tomorrow I'll write a script for automating this
> test, and I'll leave it running for some hours.
>
OK, thanks. As said I think that you actually handle the case already,
but I'll try to setup testing as well soon.
Thanks,
- Juri
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v11 05/22] vfio iommu: Added pin and unpin callback functions to vfio_iommu_driver_ops
From: Kirti Wankhede @ 2016-11-08 18:47 UTC (permalink / raw)
To: Alex Williamson
Cc: pbonzini, kraxel, cjia, qemu-devel, kvm, kevin.tian, jike.song,
bjsdjshi, linux-kernel
In-Reply-To: <20161108093952.58ced4d7@t450s.home>
On 11/8/2016 10:09 PM, Alex Williamson wrote:
> On Tue, 8 Nov 2016 19:25:35 +0530
> Kirti Wankhede <kwankhede@nvidia.com> wrote:
>
...
>>>> -
>>>> + int (*pin_pages)(void *iommu_data, unsigned long *user_pfn,
>>>> + int npage, int prot,
>>>> + unsigned long *phys_pfn);
>>>> + int (*unpin_pages)(void *iommu_data,
>>>
>>> Are we changing from long to int here simply because of the absurdity
>>> in passing in more than a 2^31 entry array, that would already consume
>>> more than 16GB itself?
>>>
>>
>> These are on demand pin/unpin request, will that request go beyond 16GB
>> limit? For Nvidia vGPU solution, pin request will not go beyond this limit.
>
> 16G is simply the size of the user_pfn or phys_pfn arrays at a maximal
> int32_t npage value, the interface actually allows mapping up to 8TB
> per call, but at that point we have 16GB of input, 16GB of output, and
> 80GB of vfio_pfns created. So I don't really have a problem changing
> form long to int given lack of scalability in the API in general, but
> it does make me second guess the API itself. Thanks,
>
Changing to 'long', in future we might enhance this API without changing
it signature.
Thanks,
Kirti
^ permalink raw reply
* [PATCH lttng-tools] Fix: test cases now rely on explicit workloads
From: Francis Deslauriers @ 2016-11-08 18:49 UTC (permalink / raw)
To: lttng-dev; +Cc: jgalar
Run a process explicitly in the tracing session to generate the enabled events
rather than relying on the events generated by the lttng CLI.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
---
tests/regression/kernel/test_all_events | 6 ++++++
tests/regression/kernel/test_event_basic | 14 ++++++++++++--
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/tests/regression/kernel/test_all_events b/tests/regression/kernel/test_all_events
index 50002f4..713c717 100755
--- a/tests/regression/kernel/test_all_events
+++ b/tests/regression/kernel/test_all_events
@@ -21,6 +21,8 @@ CURDIR=$(dirname $0)/
TESTDIR=$CURDIR/../..
NUM_TESTS=8
+TESTCMD="/bin/true"
+
source $TESTDIR/utils/utils.sh
function test_all_event()
@@ -33,6 +35,10 @@ function test_all_event()
lttng_enable_kernel_event $SESSION_NAME
start_lttng_tracing_ok
+
+ # Running a process and waiting for its completion forces the triggering of a
+ # sched_switch event
+ eval ${TESTCMD}
stop_lttng_tracing_ok
validate_trace "sched_switch" $TRACE_PATH
diff --git a/tests/regression/kernel/test_event_basic b/tests/regression/kernel/test_event_basic
index aeca02b..1a10a2c 100755
--- a/tests/regression/kernel/test_event_basic
+++ b/tests/regression/kernel/test_event_basic
@@ -21,6 +21,8 @@ CURDIR=$(dirname $0)/
TESTDIR=$CURDIR/../..
NUM_TESTS=20
+TESTCMD="/bin/true"
+
source $TESTDIR/utils/utils.sh
function test_event_basic()
@@ -32,14 +34,18 @@ function test_event_basic()
lttng_enable_kernel_event $SESSION_NAME "sched_switch"
lttng_enable_kernel_event $SESSION_NAME "sched_process_exit"
- lttng_enable_kernel_event $SESSION_NAME "sched_process_free"
+ lttng_enable_kernel_event $SESSION_NAME "sched_process_fork"
start_lttng_tracing_ok
+
+ # Running a process and waiting for its completion forces the triggering of
+ # fork, sched_switch and exit events
+ eval ${TESTCMD}
stop_lttng_tracing_ok
validate_trace "sched_switch" $TRACE_PATH
validate_trace "sched_process_exit" $TRACE_PATH
- validate_trace "sched_process_free" $TRACE_PATH
+ validate_trace "sched_process_fork" $TRACE_PATH
destroy_lttng_session_ok $SESSION_NAME
@@ -57,6 +63,10 @@ function test_enable_after_start()
start_lttng_tracing_ok
lttng_enable_kernel_event $SESSION_NAME "sched_process_exit"
+
+ # Running a process and waiting for its completion forces the triggering of
+ # sched_switch and exit events
+ eval ${TESTCMD}
stop_lttng_tracing_ok
validate_trace "sched_switch" $TRACE_PATH
--
2.7.4
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
^ permalink raw reply related
* Re: Announcing btrfs-dedupe
From: Mark Fasheh @ 2016-11-08 18:49 UTC (permalink / raw)
To: Christoph Anton Mitterer; +Cc: dsterba, James Pharaoh, linux-btrfs
In-Reply-To: <1478572812.28957.4.camel@scientia.net>
On Mon, Nov 7, 2016 at 6:40 PM, Christoph Anton Mitterer
<calestyo@scientia.net> wrote:
> On Mon, 2016-11-07 at 15:02 +0100, David Sterba wrote:
>> I think adding a whole-file dedup mode to duperemove would be better
>> (from user's POV) than writing a whole new tool
>
> What would IMO be really good from a user's POV was, if one of the
> tools, deemed to be the "best", would be added to the btrfs-progs and
> simply become "the official" one.
Yeah there's two problems, one being that the extent-same ioctl (and
duperemove) is cross-file system now so I. The other one James touches
on, which is that there's a non trivial amount of complexity in
duperemove so shoving it in btrfs progs just means we're going to have
parallel development streams solving some different problems.
That's not to say that every dedupe tool has to be complex - we have
xfs_io to run the ioctl and I don't think it'd be a bad idea if
btrfs-progs had a simple interface to it too.
--Mark
--
"When the going gets weird, the weird turn pro."
Hunter S. Thompson
^ permalink raw reply
* Re: [PATCH lttng-tools] Fix: test case can not rely on sched_process_free, use _fork instead
From: Francis Deslauriers @ 2016-11-08 18:47 UTC (permalink / raw)
To: lttng-dev@lists.lttng.org; +Cc: jgalar
In-Reply-To: <1478621125-16836-1-git-send-email-francis.deslauriers@efficios.com>
[-- Attachment #1.1: Type: text/plain, Size: 1591 bytes --]
Please omit this patch. I am preparing a more generic one.
Thank you,
--
Francis Deslauriers
Software developer
EfficiOS inc.
2016-11-08 11:05 GMT-05:00 Francis Deslauriers <
francis.deslauriers@efficios.com>:
> sched_process_free may not be called during the tracing session if there
> is very little activity on the machine the test is run on. We change
> this validate to sched_process_fork since we are sure there will be
> atleast one generated by the final lttng stop.
>
> Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
> ---
> tests/regression/kernel/test_event_basic | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tests/regression/kernel/test_event_basic
> b/tests/regression/kernel/test_event_basic
> index aeca02b..584bfc8 100755
> --- a/tests/regression/kernel/test_event_basic
> +++ b/tests/regression/kernel/test_event_basic
> @@ -32,14 +32,14 @@ function test_event_basic()
>
> lttng_enable_kernel_event $SESSION_NAME "sched_switch"
> lttng_enable_kernel_event $SESSION_NAME "sched_process_exit"
> - lttng_enable_kernel_event $SESSION_NAME "sched_process_free"
> + lttng_enable_kernel_event $SESSION_NAME "sched_process_fork"
>
> start_lttng_tracing_ok
> stop_lttng_tracing_ok
>
> validate_trace "sched_switch" $TRACE_PATH
> validate_trace "sched_process_exit" $TRACE_PATH
> - validate_trace "sched_process_free" $TRACE_PATH
> + validate_trace "sched_process_fork" $TRACE_PATH
>
> destroy_lttng_session_ok $SESSION_NAME
>
> --
> 2.7.4
>
>
[-- Attachment #1.2: Type: text/html, Size: 2570 bytes --]
[-- Attachment #2: Type: text/plain, Size: 156 bytes --]
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
^ permalink raw reply
* Re: [PATCH v3 2/3] ARM64: dts: sun6i: add dma node for a64.
From: Maxime Ripard @ 2016-11-08 18:47 UTC (permalink / raw)
To: Hao Zhang
Cc: wens, robh+dt, mark.rutland, catalin.marinas, will.deacon,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20161107182247.GA3669@arx12>
[-- Attachment #1: Type: text/plain, Size: 776 bytes --]
Hi,
On Tue, Nov 08, 2016 at 02:22:47AM +0800, Hao Zhang wrote:
> This adds the dma node for sun50i a64.
>
> Signed-off-by: Hao Zhang <hao5781286@gmail.com>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index e3c3d7d8..855ae2c 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -227,6 +227,15 @@
> };
> };
>
> + dma: dma-controller@01c02000 {
Please order the nodes by base adress, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v3 4/4] posix-timers: make it configurable
From: John Stultz @ 2016-11-08 18:48 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Michal Marek, Richard Cochran, Paul Bolle, Thomas Gleixner,
Josh Triplett, Edward Cree, netdev, linux-kbuild, lkml
In-Reply-To: <alpine.LFD.2.20.1611081311420.11818@knanqh.ubzr>
On Tue, Nov 8, 2016 at 10:19 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Tue, 8 Nov 2016, John Stultz wrote:
>
>> One spot of concern is that the
>> tools/testing/selftests/timers/posix_timers.c test hangs testing
>> virtual itimers. Looking through the code I'm not seeing where an
>> error case is missed.
>>
>> The strace looks like:
>> ...
>> write(1, "Testing posix timers. False nega"..., 66Testing posix
>> timers. False negative may happen on CPU execution
>> ) = 66
>> write(1, "based timers if other threads ru"..., 48based timers if
>> other threads run on the CPU...
>> ) = 48
>> write(1, "Check itimer virtual... ", 24Check itimer virtual... ) = 24
>> rt_sigaction(SIGVTALRM, {0x400a80, [VTALRM], SA_RESTORER|SA_RESTART,
>> 0x7fb73306ccb0}, {SIG_DFL, [], 0}, 8) = 0
>> gettimeofday({1478710402, 937476}, NULL) = 0
>> setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={2, 0}}, NULL) = 0
>> <Hang>
>>
>>
>> Where as with posix timers enabled:
>> ...
>> write(1, "Testing posix timers. False nega"..., 138Testing posix
>> timers. False negative may happen on CPU execution
>> based timers if other threads run on the CPU...
>> Check itimer virtual... ) = 138
>> rt_sigaction(SIGVTALRM, {0x400a80, [VTALRM], SA_RESTORER|SA_RESTART,
>> 0x7f231ba8ccb0}, {SIG_DFL, [], 0}, 8) = 0
>> gettimeofday({1478626751, 904856}, NULL) = 0
>> setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={2, 0}}, NULL) = 0
>> --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_KERNEL} ---
>> rt_sigreturn() = 0
>
> I'll have a look.
>
>> So I suspect you were a little too aggressive with the #ifdefs around
>> the itimers/signal code, or we need to make sure we return an error on
>> the setitimer ITIMER_VIRTUAL case as well.
>
> Well, it seemed to me that with POSIX_TIMERS=n, all the code that would
> set up that signal is gone, so there was no point keeping the code to
> deliver it.
>
> Now... would it make more sense to remove itimer support as well when
> POSIX_TIMERS=n? The same reasoning would apply.
Yes, returning an error with itimers seems needed if the signal bits
are missing.
Though I do worry that since getitimer/setitimer are older obsolete
interfaces which the posix timers api is supposed to replace, folks
might be surprised to see it removed when setting POSIX_TIMERS=n. So
some additional notes in the kconfig description may be needed.
thanks
-john
^ permalink raw reply
* Re: [PATCH v11 05/22] vfio iommu: Added pin and unpin callback functions to vfio_iommu_driver_ops
From: Kirti Wankhede @ 2016-11-08 18:47 UTC (permalink / raw)
To: Alex Williamson
Cc: pbonzini, kraxel, cjia, qemu-devel, kvm, kevin.tian, jike.song,
bjsdjshi, linux-kernel
In-Reply-To: <20161108093952.58ced4d7@t450s.home>
On 11/8/2016 10:09 PM, Alex Williamson wrote:
> On Tue, 8 Nov 2016 19:25:35 +0530
> Kirti Wankhede <kwankhede@nvidia.com> wrote:
>
...
>>>> -
>>>> + int (*pin_pages)(void *iommu_data, unsigned long *user_pfn,
>>>> + int npage, int prot,
>>>> + unsigned long *phys_pfn);
>>>> + int (*unpin_pages)(void *iommu_data,
>>>
>>> Are we changing from long to int here simply because of the absurdity
>>> in passing in more than a 2^31 entry array, that would already consume
>>> more than 16GB itself?
>>>
>>
>> These are on demand pin/unpin request, will that request go beyond 16GB
>> limit? For Nvidia vGPU solution, pin request will not go beyond this limit.
>
> 16G is simply the size of the user_pfn or phys_pfn arrays at a maximal
> int32_t npage value, the interface actually allows mapping up to 8TB
> per call, but at that point we have 16GB of input, 16GB of output, and
> 80GB of vfio_pfns created. So I don't really have a problem changing
> form long to int given lack of scalability in the API in general, but
> it does make me second guess the API itself. Thanks,
>
Changing to 'long', in future we might enhance this API without changing
it signature.
Thanks,
Kirti
^ permalink raw reply
* Re: [PATCH v3 2/3] ARM64: dts: sun6i: add dma node for a64.
From: Maxime Ripard @ 2016-11-08 18:47 UTC (permalink / raw)
To: Hao Zhang
Cc: mark.rutland, devicetree, catalin.marinas, will.deacon,
linux-kernel, wens, robh+dt, linux-arm-kernel
In-Reply-To: <20161107182247.GA3669@arx12>
[-- Attachment #1.1: Type: text/plain, Size: 776 bytes --]
Hi,
On Tue, Nov 08, 2016 at 02:22:47AM +0800, Hao Zhang wrote:
> This adds the dma node for sun50i a64.
>
> Signed-off-by: Hao Zhang <hao5781286@gmail.com>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index e3c3d7d8..855ae2c 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -227,6 +227,15 @@
> };
> };
>
> + dma: dma-controller@01c02000 {
Please order the nodes by base adress, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 2/3] ARM64: dts: sun6i: add dma node for a64.
From: Maxime Ripard @ 2016-11-08 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107182247.GA3669@arx12>
Hi,
On Tue, Nov 08, 2016 at 02:22:47AM +0800, Hao Zhang wrote:
> This adds the dma node for sun50i a64.
>
> Signed-off-by: Hao Zhang <hao5781286@gmail.com>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index e3c3d7d8..855ae2c 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -227,6 +227,15 @@
> };
> };
>
> + dma: dma-controller at 01c02000 {
Please order the nodes by base adress, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161108/cd8a7e91/attachment.sig>
^ permalink raw reply
* Re: [PATCH libdrm] xf86drm: Parse the separate files to retrieve the vendor/device info
From: Emil Velikov @ 2016-11-08 18:47 UTC (permalink / raw)
To: Mauro Santos; +Cc: Michel Dänzer, ML dri-devel
In-Reply-To: <c459f28d-7966-0926-f685-27008869ec3b@gmail.com>
On 8 November 2016 at 18:36, Mauro Santos <registo.mailling@gmail.com> wrote:
> On 08-11-2016 18:08, Mauro Santos wrote:
>> On 08-11-2016 17:13, Emil Velikov wrote:
>>> On 8 November 2016 at 16:57, Mauro Santos <registo.mailling@gmail.com> wrote:
>>>> On 08-11-2016 15:57, Emil Velikov wrote:
>>>>> On 8 November 2016 at 15:27, Mauro Santos <registo.mailling@gmail.com> wrote:
>>>>>> On 08-11-2016 15:00, Emil Velikov wrote:
>>>>>>> On 8 November 2016 at 13:38, Mauro Santos <registo.mailling@gmail.com> wrote:
>>>>>>>> On 08-11-2016 11:06, Emil Velikov wrote:
>>>>>>>>> On 1 November 2016 at 18:47, Mauro Santos <registo.mailling@gmail.com> wrote:
>>>>>>>>>> On 01-11-2016 18:13, Emil Velikov wrote:
>>>>>>>>>>> From: Emil Velikov <emil.velikov@collabora.com>
>>>>>>>>>>>
>>>>>>>>>>> Parsing config sysfs file wakes up the device. The latter of which may
>>>>>>>>>>> be slow and isn't required to begin with.
>>>>>>>>>>>
>>>>>>>>>>> Reading through config is/was required since the revision is not
>>>>>>>>>>> available by other means, although with a kernel patch in the way we can
>>>>>>>>>>> 'cheat' temporarily.
>>>>>>>>>>>
>>>>>>>>>>> That should be fine, since no open-source project has ever used the
>>>>>>>>>>> value.
>>>>>>>>>>>
>>>>>>>>>>> Cc: Michel Dänzer <michel.daenzer@amd.com>
>>>>>>>>>>> Cc: Mauro Santos <registo.mailling@gmail.com>
>>>>>>>>>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98502
>>>>>>>>>>> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
>>>>>>>>>>> ---
>>>>>>>>>>> Mauro can you apply this against libdrm and rebuild it. You do _not_
>>>>>>>>>>> need to rebuild mesa afterwords.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> ---
>>>>>>>>>>> xf86drm.c | 50 +++++++++++++++++++++++++++++++++++---------------
>>>>>>>>>>> 1 file changed, 35 insertions(+), 15 deletions(-)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/xf86drm.c b/xf86drm.c
>>>>>>>>>>> index 52add5e..5a5100c 100644
>>>>>>>>>>> --- a/xf86drm.c
>>>>>>>>>>> +++ b/xf86drm.c
>>>>>>>>>>> @@ -2950,25 +2950,45 @@ static int drmParsePciDeviceInfo(const char *d_name,
>>>>>>>>>>> drmPciDeviceInfoPtr device)
>>>>>>>>>>> {
>>>>>>>>>>> #ifdef __linux__
>>>>>>>>>>> +#define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
>>>>>>>>>>> + static const char *attrs[] = {
>>>>>>>>>>> + "revision", /* XXX: make sure it's always first, see note below */
>>>>>>>>>>> + "vendor",
>>>>>>>>>>> + "device",
>>>>>>>>>>> + "subsystem_vendor",
>>>>>>>>>>> + "subsystem_device",
>>>>>>>>>>> + };
>>>>>>>>>>> char path[PATH_MAX + 1];
>>>>>>>>>>> - unsigned char config[64];
>>>>>>>>>>> - int fd, ret;
>>>>>>>>>>> + unsigned int data[ARRAY_SIZE(attrs)];
>>>>>>>>>>> + FILE *fp;
>>>>>>>>>>> + int ret;
>>>>>>>>>>>
>>>>>>>>>>> - snprintf(path, PATH_MAX, "/sys/class/drm/%s/device/config", d_name);
>>>>>>>>>>> - fd = open(path, O_RDONLY);
>>>>>>>>>>> - if (fd < 0)
>>>>>>>>>>> - return -errno;
>>>>>>>>>>> + for (unsigned i = 0; i < ARRAY_SIZE(attrs); i++) {
>>>>>>>>>>> + snprintf(path, PATH_MAX, "/sys/class/drm/%s/device/%s",
>>>>>>>>>>> + d_name, attrs[i]);
>>>>>>>>>>> + fp = fopen(path, "r");
>>>>>>>>>>> + if (!fp) {
>>>>>>>>>>> + /* Note: First we check the revision, since older kernels
>>>>>>>>>>> + * may not have it. Default to zero in such cases. */
>>>>>>>>>>> + if (i == 0) {
>>>>>>>>>>> + data[i] = 0;
>>>>>>>>>>> + continue;
>>>>>>>>>>> + }
>>>>>>>>>>> + return -errno;
>>>>>>>>>>> + }
>>>>>>>>>>>
>>>>>>>>>>> - ret = read(fd, config, sizeof(config));
>>>>>>>>>>> - close(fd);
>>>>>>>>>>> - if (ret < 0)
>>>>>>>>>>> - return -errno;
>>>>>>>>>>> + ret = fscanf(fp, "%x", &data[i]);
>>>>>>>>>>> + fclose(fp);
>>>>>>>>>>> + if (ret != 1)
>>>>>>>>>>> + return -errno;
>>>>>>>>>>> +
>>>>>>>>>>> + }
>>>>>>>>>>>
>>>>>>>>>>> - device->vendor_id = config[0] | (config[1] << 8);
>>>>>>>>>>> - device->device_id = config[2] | (config[3] << 8);
>>>>>>>>>>> - device->revision_id = config[8];
>>>>>>>>>>> - device->subvendor_id = config[44] | (config[45] << 8);
>>>>>>>>>>> - device->subdevice_id = config[46] | (config[47] << 8);
>>>>>>>>>>> + device->revision_id = data[0] & 0xff;
>>>>>>>>>>> + device->vendor_id = data[1] & 0xffff;
>>>>>>>>>>> + device->device_id = data[2] & 0xffff;
>>>>>>>>>>> + device->subvendor_id = data[3] & 0xffff;
>>>>>>>>>>> + device->subdevice_id = data[4] & 0xffff;
>>>>>>>>>>>
>>>>>>>>>>> return 0;
>>>>>>>>>>> #else
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I have applied this against libdrm 2.4.71 and I don't see any delays
>>>>>>>>>> when starting firefox/chromium/thunderbird/glxgears.
>>>>>>>>>>
>>>>>>>>>> There is also no indication in dmesg that the dGPU is being
>>>>>>>>>> reinitialized when starting the programs where I've detected the problem.
>>>>>>>>>>
>>>>>>>>> Thanks Mauro. Can you give this a try alongside the kernel fix [1] ?
>>>>>>>>> I'd love to get the latter merged soon(ish).
>>>>>>>>> Independent of the kernel side, I might need to go another way for
>>>>>>>>> libdrm/mesa so I'll CC you on future patches.
>>>>>>>>>
>>>>>>>>> Your help is greatly appreciated !
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Emil
>>>>>>>>>
>>>>>>>>> [1] http://patchwork.ozlabs.org/patch/689975/
>>>>>>>>>
>>>>>>>>
>>>>>>>> I have applied the patch on top of kernel 4.8.6 and I'm using the libdrm
>>>>>>>> with the patch you sent me previously.
>>>>>>>>
>>>>>>>> With this patch things still seem work fine, I don't see any of the
>>>>>>>> problems I've seen before, but I don't know how to confirm that the
>>>>>>>> value from sysfs is now being used by libdrm instead of defaulting to zero.
>>>>>>>>
>>>>>>> Grr my bad. $libdrm_builddir/tests/drmdevice should do it. You might
>>>>>>> need to explicitly build it (cd tests && make drmdevice)
>>>>>>>
>>>>>>
>>>>>> When running drmdevice as my user it still wakes up the dGPU. The
>>>>>> correct device revisions are being reported by I suppose that is not
>>>>>> being read from sysfs.
>>>>>>
>>>>> Based on the output you're spot on - doesn't seem like the revision
>>>>> sysfs gets used. Most likely drmdevice is linked/using the pre-patch
>>>>> (system/local?) libdrm.so ?
>>>>>
>>>>
>>>> I've been using the patched libdrm.so ever since you sent me the patch
>>>> for libdrm and I've recompiled libdrm today to get drmdevice so both the
>>>> system's and in-tree libdrm.so should have the patch. Arch's PKGBUILD
>>>> does have a non default --enable-udev configure parameter, could that
>>>> make any difference?
>>>>
>>> The --enable-udev does not make any difference.
>>>
>>> The rest does not make sense - the exact same functions are used by
>>> drmdevice and mesa, yet it two different results are produced :-\
>>> Or something very funny is happening and reading the device/vendor
>>> file does _not_ wake the device, while the revision one does.
>>>
>>
>> If I do 'cat revision' for the dGPU it does not wake up the device so I
>> guess we can scratch that.
>>
>>> Can you pull out the kernel patch and check drmdevice/dmesg with
>>> patched libdrm ?
>>>
>>
>> Same behavior as before, both versions of drmdevice wake up the dGPU.
>> Could it be that some other lib called by drmdevice and not called by
>> other programs is doing something to wake up the dGPU?
>>
>>> Thanks
>>> Emil
>>>
>>
>>
>
> Well, I _think_ I might have found the problem and it's not with libdrm
> if I'm correct.
>
> I was now thinking and trying to check if drmdevice might be trying to
> read some other information that would wake up the dGPU, and it does.
>
> If you check the mixed output of drmdevice/dmesg I have posted(?) before
> you can see that it wakes up the device when this message is shown:
> Opening device 0 node /dev/dri/card1
>
> Note the path is /dev/dri/card1. I've tried a 'cat /dev/dri/card1' and
> sure enough the dGPU woke up, so I'd say libdrm and the kernel patch are
> working just fine as they don't touch anything in /dev but only in /sys.
>
> The initial output without the kernel patch says:
> device[0]
> available_nodes 0007
> nodes
> nodes[0] /dev/dri/card1
> nodes[1] /dev/dri/controlD65
> nodes[2] /dev/dri/renderD129
> bustype 0000
> businfo
> pci
> domain 0000
> bus 03
> dev 00
> func 0
> deviceinfo
> pci
> vendor_id 1002
> device_id 6600
> subvendor_id 17aa
> subdevice_id 5049
> revision_id 00
>
>
> If you recheck what I have posted previously after applying the kernel
> patch it says revision_id 81, so I'd say it's working and we've been
> following a red herring all along.
>
> I suppose I have unintentionally misled you, I'm sorry for that.
>
Grr how did I miss the dead obvious - open($node) _does_ wake the device.
There's nothing to apologise for and thanks for the help !
-Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: net/sctp: null-ptr-deref in sctp_inet_listen
From: Andrey Konovalov @ 2016-11-08 18:46 UTC (permalink / raw)
To: Xin Long
Cc: Vlad Yasevich, Neil Horman, David S. Miller, linux-sctp, netdev,
LKML, Dmitry Vyukov, Alexander Potapenko, Kostya Serebryany,
Eric Dumazet, syzkaller, Marcelo Ricardo Leitner
In-Reply-To: <CADvbK_eyG3pLMOws5wAOpvDUPUB2SknOCV5z6TLfJoKfj+Q27A@mail.gmail.com>
Hi Xin,
Your patch seems to be fixing the issue.
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Thanks!
On Tue, Nov 8, 2016 at 11:06 AM, Xin Long <lucien.xin@gmail.com> wrote:
> On Tue, Nov 8, 2016 at 5:44 AM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> Hi,
>>
>> I've got the following error report while running the syzkaller fuzzer:
>>
>> kasan: CONFIG_KASAN_INLINE enabled
>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>> general protection fault: 0000 [#1] SMP KASAN
>> Modules linked in:
>> CPU: 1 PID: 3851 Comm: a.out Not tainted 4.9.0-rc4+ #354
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> task: ffff880065f1d800 task.stack: ffff880063840000
>> RIP: 0010:[<ffffffff8394151b>] [<ffffffff8394151b>]
>> sctp_inet_listen+0x29b/0x790 net/sctp/socket.c:6870
>> RSP: 0018:ffff880063847dd0 EFLAGS: 00010202
>> RAX: dffffc0000000000 RBX: 1ffff1000c708fbd RCX: 0000000000000000
>> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002
>> RBP: ffff880063847e70 R08: dffffc0000000000 R09: dffffc0000000000
>> R10: 0000000000000002 R11: 0000000000000002 R12: ffff88006b350800
>> R13: 0000000000000000 R14: 1ffff1000d66a1a5 R15: 0000000000000000
>> FS: 00007fd1f0f3d7c0(0000) GS:ffff88006cd00000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 0000000020000000 CR3: 0000000064af9000 CR4: 00000000000006e0
>> Stack:
>> ffff880063847de0 ffff880066165900 ffff88006b350d20 0000000041b58ab3
>> ffffffff847ff589 ffffffff83941280 dffffc0000000000 0000000000000000
>> ffff880069b9f740 0000000000000000 ffff880063847e38 ffffffff819f04ef
>> Call Trace:
>> [< inline >] SYSC_listen net/socket.c:1396
>> [<ffffffff82b73cf6>] SyS_listen+0x206/0x250 net/socket.c:1382
>> [<ffffffff83fc1501>] entry_SYSCALL_64_fastpath+0x1f/0xc2
>> arch/x86/entry/entry_64.S:209
>> Code: 00 0f 85 f4 04 00 00 4d 8b ac 24 28 05 00 00 49 b8 00 00 00 00
>> 00 fc ff df 49 8d 7d 02 48 89 fe 49 89 fa 48 c1 ee 03 41 83 e2 07 <46>
>> 0f b6 0c 06 41 83 c2 01 45 38 ca 7c 09 45 84 c9 0f 85 87 04
>> RIP [<ffffffff8394151b>] sctp_inet_listen+0x29b/0x790 net/sctp/socket.c:6870
>> RSP <ffff880063847dd0>
>> ---[ end trace f2b501fc22999b37 ]---
>>
>> A reproducer is attached.
>>
>> On commit bc33b0ca11e3df467777a4fa7639ba488c9d4911 (Nov 5).
>>
> This is a shutdown injection issue.
> sctp_shutdown need a sk->state check, just like tcp_shutdown:
>
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -4287,7 +4287,8 @@ static void sctp_shutdown(struct sock *sk, int how)
> if (!sctp_style(sk, TCP))
> return;
>
> - if (how & SEND_SHUTDOWN) {
> + if (how & SEND_SHUTDOWN &&
> + (1 << sk->sk_state) & (SCTP_SS_ESTABLISHED | SCTP_SS_CLOSING)) {
> sk->sk_state = SCTP_SS_CLOSING;
> ep = sctp_sk(sk)->ep;
> if (!list_empty(&ep->asocs)) {
^ permalink raw reply
* Re: net/sctp: null-ptr-deref in sctp_inet_listen
From: Andrey Konovalov @ 2016-11-08 18:46 UTC (permalink / raw)
To: Xin Long
Cc: Vlad Yasevich, Neil Horman, David S. Miller, linux-sctp, netdev,
LKML, Dmitry Vyukov, Alexander Potapenko, Kostya Serebryany,
Eric Dumazet, syzkaller, Marcelo Ricardo Leitner
In-Reply-To: <CADvbK_eyG3pLMOws5wAOpvDUPUB2SknOCV5z6TLfJoKfj+Q27A@mail.gmail.com>
Hi Xin,
Your patch seems to be fixing the issue.
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Thanks!
On Tue, Nov 8, 2016 at 11:06 AM, Xin Long <lucien.xin@gmail.com> wrote:
> On Tue, Nov 8, 2016 at 5:44 AM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> Hi,
>>
>> I've got the following error report while running the syzkaller fuzzer:
>>
>> kasan: CONFIG_KASAN_INLINE enabled
>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>> general protection fault: 0000 [#1] SMP KASAN
>> Modules linked in:
>> CPU: 1 PID: 3851 Comm: a.out Not tainted 4.9.0-rc4+ #354
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> task: ffff880065f1d800 task.stack: ffff880063840000
>> RIP: 0010:[<ffffffff8394151b>] [<ffffffff8394151b>]
>> sctp_inet_listen+0x29b/0x790 net/sctp/socket.c:6870
>> RSP: 0018:ffff880063847dd0 EFLAGS: 00010202
>> RAX: dffffc0000000000 RBX: 1ffff1000c708fbd RCX: 0000000000000000
>> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002
>> RBP: ffff880063847e70 R08: dffffc0000000000 R09: dffffc0000000000
>> R10: 0000000000000002 R11: 0000000000000002 R12: ffff88006b350800
>> R13: 0000000000000000 R14: 1ffff1000d66a1a5 R15: 0000000000000000
>> FS: 00007fd1f0f3d7c0(0000) GS:ffff88006cd00000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 0000000020000000 CR3: 0000000064af9000 CR4: 00000000000006e0
>> Stack:
>> ffff880063847de0 ffff880066165900 ffff88006b350d20 0000000041b58ab3
>> ffffffff847ff589 ffffffff83941280 dffffc0000000000 0000000000000000
>> ffff880069b9f740 0000000000000000 ffff880063847e38 ffffffff819f04ef
>> Call Trace:
>> [< inline >] SYSC_listen net/socket.c:1396
>> [<ffffffff82b73cf6>] SyS_listen+0x206/0x250 net/socket.c:1382
>> [<ffffffff83fc1501>] entry_SYSCALL_64_fastpath+0x1f/0xc2
>> arch/x86/entry/entry_64.S:209
>> Code: 00 0f 85 f4 04 00 00 4d 8b ac 24 28 05 00 00 49 b8 00 00 00 00
>> 00 fc ff df 49 8d 7d 02 48 89 fe 49 89 fa 48 c1 ee 03 41 83 e2 07 <46>
>> 0f b6 0c 06 41 83 c2 01 45 38 ca 7c 09 45 84 c9 0f 85 87 04
>> RIP [<ffffffff8394151b>] sctp_inet_listen+0x29b/0x790 net/sctp/socket.c:6870
>> RSP <ffff880063847dd0>
>> ---[ end trace f2b501fc22999b37 ]---
>>
>> A reproducer is attached.
>>
>> On commit bc33b0ca11e3df467777a4fa7639ba488c9d4911 (Nov 5).
>>
> This is a shutdown injection issue.
> sctp_shutdown need a sk->state check, just like tcp_shutdown:
>
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -4287,7 +4287,8 @@ static void sctp_shutdown(struct sock *sk, int how)
> if (!sctp_style(sk, TCP))
> return;
>
> - if (how & SEND_SHUTDOWN) {
> + if (how & SEND_SHUTDOWN &&
> + (1 << sk->sk_state) & (SCTP_SS_ESTABLISHED | SCTP_SS_CLOSING)) {
> sk->sk_state = SCTP_SS_CLOSING;
> ep = sctp_sk(sk)->ep;
> if (!list_empty(&ep->asocs)) {
^ permalink raw reply
* [PATCH 1/2] clk: sunxi-ng: Fix CPUX clock for the A23/A33
From: Maxime Ripard @ 2016-11-08 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107173135.Ux5KXCv5@smtp1h.mail.yandex.net>
On Mon, Nov 07, 2016 at 05:36:03PM +0800, Icenowy Zheng wrote:
> > And your commit log should explain why it is an issue. Yours is even
> > wrong here, we could definitely change the rate of these clocks
> > already. The only thing that was not allowed was to change the rate of
> > its parents, which is what this patch fixes.
> >
> > > Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> > > ---
> > > Patch 4.9-rc too.
> >
> > I don't see why it should be part of 4.9. No one uses that code in 4.9.
>
> It can be triggered by a modified dt in 4.9, by add operating points.
Still, there's no reason to fix something that is not used by anyone,
it can definitely wait until the next release. Linus also said that he
didn't want patches like that last week.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161108/fed056dc/attachment.sig>
^ permalink raw reply
* Re: [PATCH 1/2] clk: sunxi-ng: Fix CPUX clock for the A23/A33
From: Maxime Ripard @ 2016-11-08 18:45 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Michael Turquette, linux-kernel, linux-clk, Jorik Jonker,
Stephen Boyd, Quentin Schulz, linux-arm-kernel, linux-sunxi,
Chen-Yu Tsai
In-Reply-To: <20161107173135.Ux5KXCv5@smtp1h.mail.yandex.net>
[-- Attachment #1: Type: text/plain, Size: 897 bytes --]
On Mon, Nov 07, 2016 at 05:36:03PM +0800, Icenowy Zheng wrote:
> > And your commit log should explain why it is an issue. Yours is even
> > wrong here, we could definitely change the rate of these clocks
> > already. The only thing that was not allowed was to change the rate of
> > its parents, which is what this patch fixes.
> >
> > > Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> > > ---
> > > Patch 4.9-rc too.
> >
> > I don't see why it should be part of 4.9. No one uses that code in 4.9.
>
> It can be triggered by a modified dt in 4.9, by add operating points.
Still, there's no reason to fix something that is not used by anyone,
it can definitely wait until the next release. Linus also said that he
didn't want patches like that last week.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the kspp tree with Linus' tree
From: Kees Cook @ 2016-11-08 18:44 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Linux-Next, LKML, Emese Revfy
In-Reply-To: <20161108133130.24c065f8@canb.auug.org.au>
On Mon, Nov 7, 2016 at 7:31 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Kees,
>
> FIXME: Add owner of second tree to To:
> Add author(s)/SOB of conflicting commits.
>
> Today's linux-next merge of the kspp tree got a conflict in:
>
> mm/page_alloc.c
> scripts/gcc-plugins/latent_entropy_plugin.c
>
> between commits:
>
> 38addce8b600 ("gcc-plugins: Add latent_entropy plugin")
> 0766f788eb72 ("latent_entropy: Mark functions with __latent_entropy")
> 58bea4144d23 ("latent_entropy: Fix wrong gcc code generation with 64 bit variables")
>
> from Linus' tree and commits:
>
> 2a5448668a3c ("gcc-plugins: Add latent_entropy plugin")
> 09dd109d8241 ("latent_entropy: Mark functions with __latent_entropy")
>
> from the kspp tree.
>
> I fixed it up (I used the version from Linus' tree) and can carry the
> fix as necessary. This is now fixed as far as linux-next is concerned,
> but any non trivial conflicts should be mentioned to your upstream
> maintainer when your tree is submitted for merging. You may also want
> to consider cooperating with the maintainer of the conflicting tree to
> minimise any particularly complex conflicts.
>
> Kees, maybe you could clean up the kspp tree.
Oh, I wonder how that got out of sync. I've updated the kspp tree.
Thanks!
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.