Date   

[PATCH 4.4.y-cip 04/23] PM / OPP: Introduce dev_pm_opp_get_max_transition_latency()

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Viresh Kumar <viresh.kumar@linaro.org>

commit 2174344765f472895c076d703c9cdc58215e1393 upstream.

In few use cases (like: cpufreq), it is desired to get the maximum
latency for changing OPPs. Add support for that.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
---
drivers/base/power/opp/core.c | 17 +++++++++++++++++
include/linux/pm_opp.h | 6 ++++++
2 files changed, 23 insertions(+)

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.=
c
index 09165fbef84ed..d51ddcebcca00 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -289,6 +289,23 @@ unsigned long dev_pm_opp_get_max_volt_latency(struct=
device *dev)
}
EXPORT_SYMBOL_GPL(dev_pm_opp_get_max_volt_latency);
=20
+/**
+ * dev_pm_opp_get_max_transition_latency() - Get max transition latency =
in
+ * nanoseconds
+ * @dev: device for which we do this operation
+ *
+ * Return: This function returns the max transition latency, in nanoseco=
nds, to
+ * switch from one OPP to other.
+ *
+ * Locking: This function takes rcu_read_lock().
+ */
+unsigned long dev_pm_opp_get_max_transition_latency(struct device *dev)
+{
+ return dev_pm_opp_get_max_volt_latency(dev) +
+ dev_pm_opp_get_max_clock_latency(dev);
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_get_max_transition_latency);
+
/**
* dev_pm_opp_get_suspend_opp() - Get suspend opp
* @dev: device for which we do this operation
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 5daa43058ac10..59da3d9e11ea3 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -35,6 +35,7 @@ bool dev_pm_opp_is_turbo(struct dev_pm_opp *opp);
int dev_pm_opp_get_opp_count(struct device *dev);
unsigned long dev_pm_opp_get_max_clock_latency(struct device *dev);
unsigned long dev_pm_opp_get_max_volt_latency(struct device *dev);
+unsigned long dev_pm_opp_get_max_transition_latency(struct device *dev);
struct dev_pm_opp *dev_pm_opp_get_suspend_opp(struct device *dev);
=20
struct dev_pm_opp *dev_pm_opp_find_freq_exact(struct device *dev,
@@ -94,6 +95,11 @@ static inline unsigned long dev_pm_opp_get_max_volt_la=
tency(struct device *dev)
return 0;
}
=20
+static inline unsigned long dev_pm_opp_get_max_transition_latency(struct=
device *dev)
+{
+ return 0;
+}
+
static inline struct dev_pm_opp *dev_pm_opp_get_suspend_opp(struct devic=
e *dev)
{
return NULL;
--=20
2.27.0


[PATCH 4.4.y-cip 01/23] PM / OPP: get/put regulators from OPP core

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Viresh Kumar <viresh.kumar@linaro.org>

commit 9f8ea969d5cfdd4353d2adb004e8e2286b984369 upstream.

This allows the OPP core to request/free the regulator resource,
attached to a device OPP. The regulator device is fetched using the name
provided by the driver, while calling: dev_pm_opp_set_regulator().

This will work for both OPP-v1 and v2 bindings.

This is a preliminary step for moving the OPP switching logic into the
OPP core.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
---
drivers/base/power/opp/core.c | 111 ++++++++++++++++++++++++++++++++++
drivers/base/power/opp/opp.h | 4 ++
include/linux/pm_opp.h | 9 +++
3 files changed, 124 insertions(+)

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.=
c
index 1e0a2ddf73323..efdfcee48cac7 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -19,6 +19,7 @@
#include <linux/device.h>
#include <linux/of.h>
#include <linux/export.h>
+#include <linux/regulator/consumer.h>
=20
#include "opp.h"
=20
@@ -565,6 +566,9 @@ static void _remove_device_opp(struct device_opp *dev=
_opp)
if (dev_opp->prop_name)
return;
=20
+ if (!IS_ERR_OR_NULL(dev_opp->regulator))
+ return;
+
list_dev =3D list_first_entry(&dev_opp->dev_list, struct device_list_op=
p,
node);
=20
@@ -1091,6 +1095,113 @@ unlock:
}
EXPORT_SYMBOL_GPL(dev_pm_opp_put_prop_name);
=20
+/**
+ * dev_pm_opp_set_regulator() - Set regulator name for the device
+ * @dev: Device for which regulator name is being set.
+ * @name: Name of the regulator.
+ *
+ * In order to support OPP switching, OPP layer needs to know the name o=
f the
+ * device's regulator, as the core would be required to switch voltages =
as well.
+ *
+ * This must be called before any OPPs are initialized for the device.
+ *
+ * Locking: The internal device_opp and opp structures are RCU protected=
.
+ * Hence this function internally uses RCU updater strategy with mutex l=
ocks
+ * to keep the integrity of the internal data structures. Callers should=
ensure
+ * that this function is *NOT* called under RCU protection or in context=
s where
+ * mutex cannot be locked.
+ */
+int dev_pm_opp_set_regulator(struct device *dev, const char *name)
+{
+ struct device_opp *dev_opp;
+ struct regulator *reg;
+ int ret;
+
+ mutex_lock(&dev_opp_list_lock);
+
+ dev_opp =3D _add_device_opp(dev);
+ if (!dev_opp) {
+ ret =3D -ENOMEM;
+ goto unlock;
+ }
+
+ /* This should be called before OPPs are initialized */
+ if (WARN_ON(!list_empty(&dev_opp->opp_list))) {
+ ret =3D -EBUSY;
+ goto err;
+ }
+
+ /* Already have a regulator set */
+ if (WARN_ON(!IS_ERR_OR_NULL(dev_opp->regulator))) {
+ ret =3D -EBUSY;
+ goto err;
+ }
+ /* Allocate the regulator */
+ reg =3D regulator_get_optional(dev, name);
+ if (IS_ERR(reg)) {
+ ret =3D PTR_ERR(reg);
+ if (ret !=3D -EPROBE_DEFER)
+ dev_err(dev, "%s: no regulator (%s) found: %d\n",
+ __func__, name, ret);
+ goto err;
+ }
+
+ dev_opp->regulator =3D reg;
+
+ mutex_unlock(&dev_opp_list_lock);
+ return 0;
+
+err:
+ _remove_device_opp(dev_opp);
+unlock:
+ mutex_unlock(&dev_opp_list_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_set_regulator);
+
+/**
+ * dev_pm_opp_put_regulator() - Releases resources blocked for regulator
+ * @dev: Device for which regulator was set.
+ *
+ * Locking: The internal device_opp and opp structures are RCU protected=
.
+ * Hence this function internally uses RCU updater strategy with mutex l=
ocks
+ * to keep the integrity of the internal data structures. Callers should=
ensure
+ * that this function is *NOT* called under RCU protection or in context=
s where
+ * mutex cannot be locked.
+ */
+void dev_pm_opp_put_regulator(struct device *dev)
+{
+ struct device_opp *dev_opp;
+
+ mutex_lock(&dev_opp_list_lock);
+
+ /* Check for existing list for 'dev' first */
+ dev_opp =3D _find_device_opp(dev);
+ if (IS_ERR(dev_opp)) {
+ dev_err(dev, "Failed to find dev_opp: %ld\n", PTR_ERR(dev_opp));
+ goto unlock;
+ }
+
+ if (IS_ERR_OR_NULL(dev_opp->regulator)) {
+ dev_err(dev, "%s: Doesn't have regulator set\n", __func__);
+ goto unlock;
+ }
+
+ /* Make sure there are no concurrent readers while updating dev_opp */
+ WARN_ON(!list_empty(&dev_opp->opp_list));
+
+ regulator_put(dev_opp->regulator);
+ dev_opp->regulator =3D ERR_PTR(-EINVAL);
+
+ /* Try freeing device_opp if this was the last blocking resource */
+ _remove_device_opp(dev_opp);
+
+unlock:
+ mutex_unlock(&dev_opp_list_lock);
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_put_regulator);
+
static bool _opp_is_supported(struct device *dev, struct device_opp *dev=
_opp,
struct device_node *np)
{
diff --git a/drivers/base/power/opp/opp.h b/drivers/base/power/opp/opp.h
index 690638ef36ee5..416293b7da237 100644
--- a/drivers/base/power/opp/opp.h
+++ b/drivers/base/power/opp/opp.h
@@ -22,6 +22,8 @@
#include <linux/rculist.h>
#include <linux/rcupdate.h>
=20
+struct regulator;
+
/* Lock to allow exclusive modification to the device and opp lists */
extern struct mutex dev_opp_list_lock;
=20
@@ -132,6 +134,7 @@ struct device_list_opp {
* @supported_hw: Array of version number to support.
* @supported_hw_count: Number of elements in supported_hw array.
* @prop_name: A name to postfix to many DT properties, while parsing th=
em.
+ * @regulator: Supply regulator
* @dentry: debugfs dentry pointer of the real device directory (not lin=
ks).
* @dentry_name: Name of the real dentry.
*
@@ -159,6 +162,7 @@ struct device_opp {
unsigned int *supported_hw;
unsigned int supported_hw_count;
const char *prop_name;
+ struct regulator *regulator;
=20
#ifdef CONFIG_DEBUG_FS
struct dentry *dentry;
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 95403d2ccaf56..c70a18ac9c8a7 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -60,6 +60,8 @@ int dev_pm_opp_set_supported_hw(struct device *dev, con=
st u32 *versions,
void dev_pm_opp_put_supported_hw(struct device *dev);
int dev_pm_opp_set_prop_name(struct device *dev, const char *name);
void dev_pm_opp_put_prop_name(struct device *dev);
+int dev_pm_opp_set_regulator(struct device *dev, const char *name);
+void dev_pm_opp_put_regulator(struct device *dev);
#else
static inline unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *op=
p)
{
@@ -151,6 +153,13 @@ static inline int dev_pm_opp_set_prop_name(struct de=
vice *dev, const char *name)
=20
static inline void dev_pm_opp_put_prop_name(struct device *dev) {}
=20
+static inline int dev_pm_opp_set_regulator(struct device *dev, const cha=
r *name)
+{
+ return -EINVAL;
+}
+
+static inline void dev_pm_opp_put_regulator(struct device *dev) {}
+
#endif /* CONFIG_PM_OPP */
=20
#if defined(CONFIG_PM_OPP) && defined(CONFIG_OF)
--=20
2.27.0


[PATCH 4.4.y-cip 03/23] PM / OPP: Introduce dev_pm_opp_get_max_volt_latency()

Chen-Yu Tsai (Moxa) <wens@...>
 

From: Viresh Kumar <viresh.kumar@linaro.org>

commit 655c9df961751ce21466f6e97e8033932c27a675 upstream.

In few use cases (like: cpufreq), it is desired to get the maximum
voltage latency for changing OPPs. Add support for that.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Chen-Yu Tsai (Moxa) <wens@csie.org>
---
drivers/base/power/opp/core.c | 59 +++++++++++++++++++++++++++++++++++
include/linux/pm_opp.h | 6 ++++
2 files changed, 65 insertions(+)

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.=
c
index 48ec88befffc9..09165fbef84ed 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -230,6 +230,65 @@ unsigned long dev_pm_opp_get_max_clock_latency(struc=
t device *dev)
}
EXPORT_SYMBOL_GPL(dev_pm_opp_get_max_clock_latency);
=20
+/**
+ * dev_pm_opp_get_max_volt_latency() - Get max voltage latency in nanose=
conds
+ * @dev: device for which we do this operation
+ *
+ * Return: This function returns the max voltage latency in nanoseconds.
+ *
+ * Locking: This function takes rcu_read_lock().
+ */
+unsigned long dev_pm_opp_get_max_volt_latency(struct device *dev)
+{
+ struct device_opp *dev_opp;
+ struct dev_pm_opp *opp;
+ struct regulator *reg;
+ unsigned long latency_ns =3D 0;
+ unsigned long min_uV =3D ~0, max_uV =3D 0;
+ int ret;
+
+ rcu_read_lock();
+
+ dev_opp =3D _find_device_opp(dev);
+ if (IS_ERR(dev_opp)) {
+ rcu_read_unlock();
+ return 0;
+ }
+
+ reg =3D dev_opp->regulator;
+ if (IS_ERR_OR_NULL(reg)) {
+ /* Regulator may not be required for device */
+ if (reg)
+ dev_err(dev, "%s: Invalid regulator (%ld)\n", __func__,
+ PTR_ERR(reg));
+ rcu_read_unlock();
+ return 0;
+ }
+
+ list_for_each_entry_rcu(opp, &dev_opp->opp_list, node) {
+ if (!opp->available)
+ continue;
+
+ if (opp->u_volt_min < min_uV)
+ min_uV =3D opp->u_volt_min;
+ if (opp->u_volt_max > max_uV)
+ max_uV =3D opp->u_volt_max;
+ }
+
+ rcu_read_unlock();
+
+ /*
+ * The caller needs to ensure that dev_opp (and hence the regulator)
+ * isn't freed, while we are executing this routine.
+ */
+ ret =3D regulator_set_voltage_time(reg, min_uV, max_uV);
+ if (ret > 0)
+ latency_ns =3D ret * 1000;
+
+ return latency_ns;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_get_max_volt_latency);
+
/**
* dev_pm_opp_get_suspend_opp() - Get suspend opp
* @dev: device for which we do this operation
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index c70a18ac9c8a7..5daa43058ac10 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -34,6 +34,7 @@ bool dev_pm_opp_is_turbo(struct dev_pm_opp *opp);
=20
int dev_pm_opp_get_opp_count(struct device *dev);
unsigned long dev_pm_opp_get_max_clock_latency(struct device *dev);
+unsigned long dev_pm_opp_get_max_volt_latency(struct device *dev);
struct dev_pm_opp *dev_pm_opp_get_suspend_opp(struct device *dev);
=20
struct dev_pm_opp *dev_pm_opp_find_freq_exact(struct device *dev,
@@ -88,6 +89,11 @@ static inline unsigned long dev_pm_opp_get_max_clock_l=
atency(struct device *dev)
return 0;
}
=20
+static inline unsigned long dev_pm_opp_get_max_volt_latency(struct devic=
e *dev)
+{
+ return 0;
+}
+
static inline struct dev_pm_opp *dev_pm_opp_get_suspend_opp(struct devic=
e *dev)
{
return NULL;
--=20
2.27.0


Vagrant 2.2.8, 2.2.9 issue

Mohammed Billoo <mab@...>
 

All,

Just wanted to document an issue as well as a/my workaround when using vagrant 2.2.8/2.2.9. After installing vagrant 2.0.2 using apt-get in Ubuntu 18.04, it complained that I had a too new version of VirtualBox. Not wanting to downgrade VirtualBox because I have other VMs that I use for other work, I decided to install from source. I went with the tagged version 2.2.9 and ran into the following issue (which also exists for 2.2.8):


I installed from the master branch and didn't have the issue. 

Just documenting this in case anyone else has the same issue.
--
Mohammed A Billoo
Founder
MAB Labs, LLC
201-338-2022

--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com


Re: Working on HTTPS connection

Akihiro Suzuki
 

Hi Quirin,

Thank you for the information.
I've added the information to the following issue.
https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-tasks/-/issues/8

Thanks,
Suzuki

-----Original Message-----
From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Quirin Gylstorff
Sent: Thursday, July 2, 2020 5:25 PM
To: cip-dev@lists.cip-project.org; mab@mab-labs.com
Subject: Re: [cip-dev] Working on HTTPS connection



On 6/29/20 6:57 PM, Mohammed Billoo wrote:
Hello!

I joined the mailing list from the recommendation on the IRC channel
(after viewing the CIP talk at ELC). I'd like to work on the following
issue:
https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-tasks/-/issues/8

I've written applications + drivers for u-boot, have worked on SSL
(albeit for Amazon FreeRTOS), and have HW handy to hit the ground
running (I have a DE1-SoC).

Is there any update on this task that should I be aware of?
Hi,

if you add the following elements to the swupdate build config. HTTPS
works more or less. I did not test it in all configurations, only for a
short demo. And some of the options may not be necessary.

...
CONFIG_CURL=y
CONFIG_CURL_SSL=y
CONFIG_SSL_IMPL_OPENSSL=y
CONFIG_DOWNLOAD=y
CONFIG_DOWNLOAD_SSL=y
CONFIG_CHANNEL_CURL=y
CONFIG_CHANNEL_CURL_SSL=y
CONFIG_SURICATTA=y
CONFIG_SURICATTA_STATE_CHOICE_NONE=y
CONFIG_SURICATTA_HAWKBIT=y
CONFIG_SURICATTA_SSL=y
CONFIG_HASH_VERIFY=y
CONFIG_JSON=y
...

Quirin

Looking forward to contributing to this project!

--
Mohammed A Billoo
Founder
MAB Labs, LLC
www.mab-labs.com <http://www.mab-labs.com>
201-338-2022

--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com
--
Quirin


v4.19-rt status

Pavel Machek
 

Hi!

Newest 4.19-rt kernel is currently v4.19.127-rt54. That's not good
match for us, as -cip kernels are v4.19.128-cip28 and v4.19.130-cip29.

I could do kernel based on v4.19.127-rt54 and v4.19.124-cip27, but I
believe it makes more sense to wait for newer v4.19-rt release.

Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Re: CIP IRC weekly meeting today

masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
 

Hi, Chris-san,

 

Sure, then see you at the CIP mini summit!

 

Best regards,

--

M. Kudo

 

From: cip-dev@... <cip-dev@...> On Behalf Of Chris Paterson
Sent: Thursday, July 2, 2020 5:44 PM
To: cip-dev@...
Subject: Re: [cip-dev] CIP IRC weekly meeting today

 

Hello Kudo-san,

Please accept my apologies; I can't babe the meeting this week.

Kind regards, Chris


From: cip-dev@... <cip-dev@...> on behalf of masashi.kudo@... via lists.cip-project.org <masashi.kudo=cybertrust.co.jp@...>
Sent: Wednesday, July 1, 2020 11:53:32 PM
To: cip-dev@... <cip-dev@...>
Subject: [cip-dev] CIP IRC weekly meeting today

 

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=7&day=2&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest  USEast  UK      DE      TW      JP
02:00   05:00   10:00   11:00   17:00   18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/06/cip.2020-06-25-09.00.log.html

Agenda:

* Action item
  1. Combine root filesystem with kselftest binary - iwamatsu
  2. Post LTP results to KernelCI - patersonc
  3. Issues to be fixed for swupdate "copyright correction and salsa CI testing" - iwamatsu

* Kernel maintenance updates
* Kernel testing
* Software update
* CIP Security
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.


Re: CIP IRC weekly meeting today

Chris Paterson
 

Hello Kudo-san,

Please accept my apologies; I can't babe the meeting this week.

Kind regards, Chris


From: cip-dev@... <cip-dev@...> on behalf of masashi.kudo@... via lists.cip-project.org <masashi.kudo=cybertrust.co.jp@...>
Sent: Wednesday, July 1, 2020 11:53:32 PM
To: cip-dev@... <cip-dev@...>
Subject: [cip-dev] CIP IRC weekly meeting today
 
Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=7&day=2&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest  USEast  UK      DE      TW      JP
02:00   05:00   10:00   11:00   17:00   18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/06/cip.2020-06-25-09.00.log.html

Agenda:

* Action item
  1. Combine root filesystem with kselftest binary - iwamatsu
  2. Post LTP results to KernelCI - patersonc
  3. Issues to be fixed for swupdate "copyright correction and salsa CI testing" - iwamatsu

* Kernel maintenance updates
* Kernel testing
* Software update
* CIP Security
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.


Re: Working on HTTPS connection

Quirin Gylstorff
 

On 6/29/20 6:57 PM, Mohammed Billoo wrote:
Hello!
I joined the mailing list from the recommendation on the IRC channel (after viewing the CIP talk at ELC). I'd like to work on the following issue: https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-tasks/-/issues/8
I've written applications + drivers for u-boot, have worked on SSL (albeit for Amazon FreeRTOS), and have HW handy to hit the ground running (I have a DE1-SoC).
Is there any update on this task that should I be aware of?
Hi,

if you add the following elements to the swupdate build config. HTTPS works more or less. I did not test it in all configurations, only for a short demo. And some of the options may not be necessary.

...
CONFIG_CURL=y
CONFIG_CURL_SSL=y
CONFIG_SSL_IMPL_OPENSSL=y
CONFIG_DOWNLOAD=y
CONFIG_DOWNLOAD_SSL=y
CONFIG_CHANNEL_CURL=y
CONFIG_CHANNEL_CURL_SSL=y
CONFIG_SURICATTA=y
CONFIG_SURICATTA_STATE_CHOICE_NONE=y
CONFIG_SURICATTA_HAWKBIT=y
CONFIG_SURICATTA_SSL=y
CONFIG_HASH_VERIFY=y
CONFIG_JSON=y
...

Quirin

Looking forward to contributing to this project!
--
Mohammed A Billoo
Founder
MAB Labs, LLC
www.mab-labs.com <http://www.mab-labs.com>
201-338-2022
--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com
--
Quirin


Re: Setting up SWUpdate

Akihiro Suzuki
 

Hi Mohammed,

 

If you work on this issue, you will be able to learn about our software update mechanism well, I think.

Can I assign you to work on this issue?

 

Thanks,

Suzuki

 

From: Mohammed Billoo <mab@...>
Sent: Wednesday, July 1, 2020 8:57 PM
To: suzuki akihiro(
鈴木 章浩SWCACT) <akihiro27.suzuki@...>
Cc: cip-dev@...
Subject: Re: [cip-dev] Setting up SWUpdate

 

Suzuki,

 

I can look into this issue as well (when my BBB comes in). It's focused enough that I can learn enough about SWUpdate and how it fits into CIP.

 

Let me know what you think.

 

Mohammed

 

On Wed, Jul 1, 2020 at 5:40 AM <akihiro27.suzuki@...> wrote:

Hi Mohammed,

 

> NOTE: Now I have a problem with the demo. Ill make the issue about it in cip-sw-updates-tasks repository later.

Ive made the issue about it: https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-tasks/-/issues/14

It might be better to wait for trying cip-sw-updates-demo until the issue is resolved.

 

Thanks,
Suzuki

 

From: suzuki akihiro(鈴木 章浩SWCACT)
Sent: Wednesday, July 1, 2020 2:09 PM
To: Mohammed Billoo <mab@...>
Cc: cip-dev@...
Subject: RE: [cip-dev] Setting up SWUpdate

 

Hi Mohammed,

 

> Should I be using the instructions outlined in https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-demo to run a basic update of the CIP image on a BBB from hawkBit? Can the update process be verified using hawkbit and/or the BBB?

Yes, you can verify a basic update process via README.md in cip-sw-updates-demo repository.

It uses BBB and hawkBit.

Please let me know if you have a problem about the instructions written in the README.md.

NOTE: Now I have a problem with the demo. Ill make the issue about it in cip-sw-updates-tasks repository later.

 

> Also, there looks to be a patchset to bring in swupdate to cip-core (https://patchwork.kernel.org/project/cip-dev/list/?series=309741). Should I wait for this patchset to be approved?

The patchset is for x86 with UEFI to provide updatable secure boot for UEFI.

It uses EFI Boot Guard (https://github.com/siemens/efibootguard) instead of u-boot.

It will be able to cover the main use cases for software update on devices.

Although cip-sw-updates-demo repository doesnt include the demo for x86 with UEFI at the moment,

you can try basic update features using BBB.

 

Thanks,

Suzuki

 

From: cip-dev@... <cip-dev@...> On Behalf Of Mohammed Billoo
Sent: Wednesday, July 1, 2020 7:49 AM
To: cip-dev@...
Subject: [cip-dev] Setting up SWUpdate

 

Hello,

 

Should I be using the instructions outlined in https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-demo to run a basic update of the CIP image on a BBB from hawkBit? Can the update process be verified using hawkbit and/or the BBB?

 

Also, there looks to be a patchset to bring in swupdate to cip-core (https://patchwork.kernel.org/project/cip-dev/list/?series=309741). Should I wait for this patchset to be approved?

 

--

Mohammed A Billoo

Founder

MAB Labs, LLC

201-338-2022


--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com



--

Mohammed A Billoo

Founder

MAB Labs, LLC

201-338-2022


CIP IRC weekly meeting today

masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
 

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=7&day=2&hour=9&min=0&sec=0&p1=224&p2=179&p3=136&p4=37&p5=241&p6=248

USWest USEast UK DE TW JP
02:00 05:00 10:00 11:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last meeting minutes:
https://irclogs.baserock.org/meetings/cip/2020/06/cip.2020-06-25-09.00.log.html

Agenda:

* Action item
1. Combine root filesystem with kselftest binary - iwamatsu
2. Post LTP results to KernelCI - patersonc
3. Issues to be fixed for swupdate "copyright correction and salsa CI testing" - iwamatsu

* Kernel maintenance updates
* Kernel testing
* Software update
* CIP Security
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.


Building generic initramfs for the various testing

Zoran
 

Hello list,

Long time no see... ;-)

Just for the sake of Reality: the generic initramfs building from the:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipsystembuildhowto

Does not work (for me, at least) anymore.

Here is the new minimalistic script, since I needed it (and reworked
it, to be much more efficient):
https://github.com/ZoranStojsavljevic/BBB_Workshop_Examples/blob/master/Generic_Initrd_Porting_Guide/initramfs/create_initramfs.sh

Enjoy!
Zoran Stojsavljevic


Re: Setting up SWUpdate

Mohammed Billoo <mab@...>
 

Suzuki,

I can look into this issue as well (when my BBB comes in). It's focused enough that I can learn enough about SWUpdate and how it fits into CIP.

Let me know what you think.

Mohammed


On Wed, Jul 1, 2020 at 5:40 AM <akihiro27.suzuki@...> wrote:

Hi Mohammed,

 

> NOTE: Now I have a problem with the demo. Ill make the issue about it in cip-sw-updates-tasks repository later.

I’ve made the issue about it: https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-tasks/-/issues/14

It might be better to wait for trying cip-sw-updates-demo until the issue is resolved.

 

Thanks,
Suzuki

 

From: suzuki akihiro(鈴木 章浩SWCACT)
Sent: Wednesday, July 1, 2020 2:09 PM
To: Mohammed Billoo <mab@...>
Cc: cip-dev@...
Subject: RE: [cip-dev] Setting up SWUpdate

 

Hi Mohammed,

 

> Should I be using the instructions outlined in https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-demo to run a basic update of the CIP image on a BBB from hawkBit? Can the update process be verified using hawkbit and/or the BBB?

Yes, you can verify a basic update process via README.md in cip-sw-updates-demo repository.

It uses BBB and hawkBit.

Please let me know if you have a problem about the instructions written in the README.md.

NOTE: Now I have a problem with the demo. Ill make the issue about it in cip-sw-updates-tasks repository later.

 

> Also, there looks to be a patchset to bring in swupdate to cip-core (https://patchwork.kernel.org/project/cip-dev/list/?series=309741). Should I wait for this patchset to be approved?

The patchset is for x86 with UEFI to provide updatable secure boot for UEFI.

It uses EFI Boot Guard (https://github.com/siemens/efibootguard) instead of u-boot.

It will be able to cover the main use cases for software update on devices.

Although cip-sw-updates-demo repository doesnt include the demo for x86 with UEFI at the moment,

you can try basic update features using BBB.

 

Thanks,

Suzuki

 

From: cip-dev@... <cip-dev@...> On Behalf Of Mohammed Billoo
Sent: Wednesday, July 1, 2020 7:49 AM
To: cip-dev@...
Subject: [cip-dev] Setting up SWUpdate

 

Hello,

 

Should I be using the instructions outlined in https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-demo to run a basic update of the CIP image on a BBB from hawkBit? Can the update process be verified using hawkbit and/or the BBB?

 

Also, there looks to be a patchset to bring in swupdate to cip-core (https://patchwork.kernel.org/project/cip-dev/list/?series=309741). Should I wait for this patchset to be approved?

 

--

Mohammed A Billoo

Founder

MAB Labs, LLC

201-338-2022


--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com



--
Mohammed A Billoo
Founder
MAB Labs, LLC
201-338-2022

--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com


Re: Setting up SWUpdate

Akihiro Suzuki
 

Hi Mohammed,

 

> NOTE: Now I have a problem with the demo. Ill make the issue about it in cip-sw-updates-tasks repository later.

I’ve made the issue about it: https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-tasks/-/issues/14

It might be better to wait for trying cip-sw-updates-demo until the issue is resolved.

 

Thanks,
Suzuki

 

From: suzuki akihiro(鈴木 章浩SWCACT)
Sent: Wednesday, July 1, 2020 2:09 PM
To: Mohammed Billoo <mab@...>
Cc: cip-dev@...
Subject: RE: [cip-dev] Setting up SWUpdate

 

Hi Mohammed,

 

> Should I be using the instructions outlined in https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-demo to run a basic update of the CIP image on a BBB from hawkBit? Can the update process be verified using hawkbit and/or the BBB?

Yes, you can verify a basic update process via README.md in cip-sw-updates-demo repository.

It uses BBB and hawkBit.

Please let me know if you have a problem about the instructions written in the README.md.

NOTE: Now I have a problem with the demo. Ill make the issue about it in cip-sw-updates-tasks repository later.

 

> Also, there looks to be a patchset to bring in swupdate to cip-core (https://patchwork.kernel.org/project/cip-dev/list/?series=309741). Should I wait for this patchset to be approved?

The patchset is for x86 with UEFI to provide updatable secure boot for UEFI.

It uses EFI Boot Guard (https://github.com/siemens/efibootguard) instead of u-boot.

It will be able to cover the main use cases for software update on devices.

Although cip-sw-updates-demo repository doesnt include the demo for x86 with UEFI at the moment,

you can try basic update features using BBB.

 

Thanks,

Suzuki

 

From: cip-dev@... <cip-dev@...> On Behalf Of Mohammed Billoo
Sent: Wednesday, July 1, 2020 7:49 AM
To: cip-dev@...
Subject: [cip-dev] Setting up SWUpdate

 

Hello,

 

Should I be using the instructions outlined in https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-demo to run a basic update of the CIP image on a BBB from hawkBit? Can the update process be verified using hawkbit and/or the BBB?

 

Also, there looks to be a patchset to bring in swupdate to cip-core (https://patchwork.kernel.org/project/cip-dev/list/?series=309741). Should I wait for this patchset to be approved?

 

--

Mohammed A Billoo

Founder

MAB Labs, LLC

201-338-2022


--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com


Re: Setting up SWUpdate

Akihiro Suzuki
 

Hi Mohammed,

 

> Should I be using the instructions outlined in https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-demo to run a basic update of the CIP image on a BBB from hawkBit? Can the update process be verified using hawkbit and/or the BBB?

Yes, you can verify a basic update process via README.md in cip-sw-updates-demo repository.

It uses BBB and hawkBit.

Please let me know if you have a problem about the instructions written in the README.md.

NOTE: Now I have a problem with the demo. I’ll make the issue about it in cip-sw-updates-tasks repository later.

 

> Also, there looks to be a patchset to bring in swupdate to cip-core (https://patchwork.kernel.org/project/cip-dev/list/?series=309741). Should I wait for this patchset to be approved?

The patchset is for x86 with UEFI to provide updatable secure boot for UEFI.

It uses EFI Boot Guard (https://github.com/siemens/efibootguard) instead of u-boot.

It will be able to cover the main use cases for software update on devices.

Although cip-sw-updates-demo repository doesn’t include the demo for x86 with UEFI at the moment,

you can try basic update features using BBB.

 

Thanks,

Suzuki

 

From: cip-dev@... <cip-dev@...> On Behalf Of Mohammed Billoo
Sent: Wednesday, July 1, 2020 7:49 AM
To: cip-dev@...
Subject: [cip-dev] Setting up SWUpdate

 

Hello,

 

Should I be using the instructions outlined in https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-demo to run a basic update of the CIP image on a BBB from hawkBit? Can the update process be verified using hawkbit and/or the BBB?

 

Also, there looks to be a patchset to bring in swupdate to cip-core (https://patchwork.kernel.org/project/cip-dev/list/?series=309741). Should I wait for this patchset to be approved?

 

--

Mohammed A Billoo

Founder

MAB Labs, LLC

201-338-2022


--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com


Setting up SWUpdate

Mohammed Billoo <mab@...>
 

Hello,

Should I be using the instructions outlined in https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-demo to run a basic update of the CIP image on a BBB from hawkBit? Can the update process be verified using hawkbit and/or the BBB?

Also, there looks to be a patchset to bring in swupdate to cip-core (https://patchwork.kernel.org/project/cip-dev/list/?series=309741). Should I wait for this patchset to be approved?

--
Mohammed A Billoo
Founder
MAB Labs, LLC
201-338-2022

--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com


Re: Working on HTTPS connection

masashi.kudo@cybertrust.co.jp <masashi.kudo@...>
 

Hi, Mohammed-san,

 

No worries. Meeting minutes will be produced at every meeting.

So, you can check them out to see what is going on afterwards.

 

FYI, last meeting minutes are the following:

https://irclogs.baserock.org/meetings/cip/2020/06/cip.2020-06-25-09.00.log.html

 

Best regards,

--

M. Kudo

From: cip-dev@... <cip-dev@...> On Behalf Of Mohammed Billoo
Sent: Tuesday, June 30, 2020 8:16 PM
To: akihiro27.suzuki@...
Cc: cip-dev@...
Subject: Re: [cip-dev] Working on HTTPS connection

 

Suzuki, M. Kudo:

Thank you for getting back to me. I'll order the BBB, and start navigating the codebase until it arrives. I will try my best to make the meetings on Thursday, but it may be difficult since I'm in NYC and it will be 5AM. Is it OK if I post updates to the IRC channel when I'm up in the morning (in case I can't make it to the meeting) ?

 

Best,

Mohammed

 

On Tue, Jun 30, 2020 at 3:40 AM <akihiro27.suzuki@...> wrote:

Hi Mohammed,

 

Thank you very much for your offer!

Im Akihiro Suzuki, a chair of SW Updates WG.

 

Currently, we are using BeagleBone Black (BBB) for developing our initial software update mechanism.

Of course we plan to port it to other reference hardware, but it is not done at the moment.

So, could you prepare BBB for the development?

 

Even if you cant prepare it, you may work on the task you are interested in because it is not a hardware-specific.

The task aims to connect between client (SWUpdate) and server (hawkBit) via HTTPS.

 

Best regards,

Suzuki

 

From: cip-dev@... <cip-dev@...> On Behalf Of masashi.kudo@...
Sent: Tuesday, June 30, 2020 7:32 AM
To: cip-dev@...
Subject: Re: [cip-dev] Working on HTTPS connection

 

Hi, Mohammed-san,

 

Thanks very much for watching the talk, and welcome to cip-dev!

 

Regarding SW Update WG, the followings are the their wiki pages.

 

https://wiki.linuxfoundation.org/civilinfrastructureplatform/start#cip_software_updates

https://wiki.linuxfoundation.org/civilinfrastructureplatform/cip-sw-updates

 

Also, SW Update WG reports the latest status at IRC meetings which start at UTC (GMT) 09:00 every Thursday. Notifications of the meetings are sent 6-9 hours before the meetings.

 

Hope it helps.

 

Best regards,

--

M. Kudo

 

From: cip-dev@... <cip-dev@...> On Behalf Of Mohammed Billoo
Sent: Tuesday, June 30, 2020 1:57 AM
To: cip-dev@...
Subject: [cip-dev] Working on HTTPS connection

 

Hello!

 

I joined the mailing list from the recommendation on the IRC channel (after viewing the CIP talk at ELC). I'd like to work on the following issue: https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-tasks/-/issues/8

 

I've written applications + drivers for u-boot, have worked on SSL (albeit for Amazon FreeRTOS), and have HW handy to hit the ground running (I have a DE1-SoC).

 

Is there any update on this task that should I be aware of?

 

Looking forward to contributing to this project!


--

Mohammed A Billoo

Founder

MAB Labs, LLC

201-338-2022


--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com



--

Mohammed A Billoo

Founder

MAB Labs, LLC

201-338-2022


--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com


Re: Working on HTTPS connection

Mohammed Billoo <mab@...>
 

Suzuki, M. Kudo:

Thank you for getting back to me. I'll order the BBB, and start navigating the codebase until it arrives. I will try my best to make the meetings on Thursday, but it may be difficult since I'm in NYC and it will be 5AM. Is it OK if I post updates to the IRC channel when I'm up in the morning (in case I can't make it to the meeting) ?

Best,
Mohammed


On Tue, Jun 30, 2020 at 3:40 AM <akihiro27.suzuki@...> wrote:

Hi Mohammed,

 

Thank you very much for your offer!

I’m Akihiro Suzuki, a chair of SW Updates WG.

 

Currently, we are using BeagleBone Black (BBB) for developing our initial software update mechanism.

Of course we plan to port it to other reference hardware, but it is not done at the moment.

So, could you prepare BBB for the development?

 

Even if you can’t prepare it, you may work on the task you are interested in because it is not a hardware-specific.

The task aims to connect between client (SWUpdate) and server (hawkBit) via HTTPS.

 

Best regards,

Suzuki

 

From: cip-dev@... <cip-dev@...> On Behalf Of masashi.kudo@...
Sent: Tuesday, June 30, 2020 7:32 AM
To: cip-dev@...
Subject: Re: [cip-dev] Working on HTTPS connection

 

Hi, Mohammed-san,

 

Thanks very much for watching the talk, and welcome to cip-dev!

 

Regarding SW Update WG, the followings are the their wiki pages.

 

https://wiki.linuxfoundation.org/civilinfrastructureplatform/start#cip_software_updates

https://wiki.linuxfoundation.org/civilinfrastructureplatform/cip-sw-updates

 

Also, SW Update WG reports the latest status at IRC meetings which start at UTC (GMT) 09:00 every Thursday. Notifications of the meetings are sent 6-9 hours before the meetings.

 

Hope it helps.

 

Best regards,

--

M. Kudo

 

From: cip-dev@... <cip-dev@...> On Behalf Of Mohammed Billoo
Sent: Tuesday, June 30, 2020 1:57 AM
To: cip-dev@...
Subject: [cip-dev] Working on HTTPS connection

 

Hello!

 

I joined the mailing list from the recommendation on the IRC channel (after viewing the CIP talk at ELC). I'd like to work on the following issue: https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-tasks/-/issues/8

 

I've written applications + drivers for u-boot, have worked on SSL (albeit for Amazon FreeRTOS), and have HW handy to hit the ground running (I have a DE1-SoC).

 

Is there any update on this task that should I be aware of?

 

Looking forward to contributing to this project!


--

Mohammed A Billoo

Founder

MAB Labs, LLC

201-338-2022


--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com



--
Mohammed A Billoo
Founder
MAB Labs, LLC
201-338-2022

--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com


Re: [isar-cip-core PATCH 1/6] opt-security.yml: Sample settings to install security

Venkata Pyla
 

On Mon, Jun 29, 2020 at 05:26 PM, Daniel Sangorrin wrote:
-----Original Message-----
From: cip-dev@... [mailto:cip-dev@...] On Behalf Of Jan Kiszka
Sent: Friday, June 26, 2020 7:41 PM
To: cip-dev@...; pyla venkata(TSIP) <Venkata.Pyla@...>
Cc: cip-security@...
Subject: Re: [cip-dev][isar-cip-core PATCH 1/6] opt-security.yml: Sample settings to install security

On 26.06.20 08:44, venkata wrote:
From: Kazuhiro Hayashi
kazuhiro3.hayashi@...<mailto:kazuhiro3.hayashi@...
This line seems to have been mangled. It should be in line with the Signed-off-by.

opt-security.yml: Sample settings to install security packages

Signed-off-by: Kazuhiro Hayashi <kazuhiro3.hayashi@...>
---
SECURITY.md | 52 ++++++++++++++++++++++++++++++++++++++++++++++++
opt-security.yml | 34 +++++++++++++++++++++++++++++++
2 files changed, 86 insertions(+)
create mode 100644 SECURITY.md
create mode 100644 opt-security.yml

diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index
0000000..a8bccc7
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,52 @@
+How to customize images for security features
+=============================================
+
+This is the "temporal" document about how to create and use the CIP
+Core generic profile images for security feature evaluation.
+
+Official manuals
+----------------
+
+* isar-cip-core:
+https://gitlab.com/zuka0828/isar-cip-core/-/blob/master/README.md
+* ISAR User Manual:
+https://github.com/ilbers/isar/blob/master/doc/user_manual.md
+
+Assumed environment
+-------------------
+
+* isar-cip-core: master branch
+* Host: Debian 10 buster amd64
+ * Installed packages: `docker-ce`, `qemu-system`
+ * Users who does the following actions must be in the groups
+`docker` and `kvm`
+
+Create kas file
+---------------
+
+Create a kas file named `opt-security.yml` to add security settings.
That file is added by this patch already.

+
+Add security packages to rootfs
+-------------------------------
+
+Set `IMAGE_PREINSTALL` to the list of packages required to enable the
+security features. This variable can be set through the kas file.
+
+Example:
+
+```
+local_conf_header:
+ security: |
+ IMAGE_PREINSTALL = "openssl"
+```
+
+Build images
+------------
+
+Build images for QEMU x86 64bit machine:
+
+ $ ./kas-docker --isar build
+ kas.yml:board-qemu-amd64.yml:opt-security.yml
+
+Run on QEMU
+-----------
+
+Run the generated images on QEMU (x86 64bit).
+
+ $ ./start-qemu.sh amd64
diff --git a/opt-security.yml b/opt-security.yml new file mode 100644
index 0000000..7c6b39c
--- /dev/null
+++ b/opt-security.yml
@@ -0,0 +1,34 @@
+#
+# KAS configuration for CIP Core generic profile to enable security
+features # # Copyright (c) Toshiba Corporation, 2020 # # Authors:
+# Kazuhiro Hayashi <kazuhiro3.hayashi@...> # #
+SPDX-License-Identifier: MIT #
+
+header:
+ version: 8
+
+local_conf_header:
+ security: |
+ # TODO: Add sudo or sudo-ldap
+ IMAGE_PREINSTALL = "\
+ openssl libssl1.1 \
+ fail2ban \
+ openssh-server openssh-sftp-server openssh-client \
+ syslog-ng-core syslog-ng-mod-journal \
+ aide aide-common \
+ libnftables0 nftables \
+ libpam-pkcs11 \
+ chrony \
+ tpm2-tools \
+ tpm2-abrmd \
+ libtss2-esys0 libtss2-udev \
+ libpam-cracklib \
+ acl \
+ libauparse0 audispd-plugins auditd \
+ uuid-runtime \
+ "
Shouldn't we target for a security image (recipe) instead?

General question: What is this series targeting? Seems patch 2 and 3 are left-overs from the development. Is this an RFC series only?

Jan
It seems that opt-security.yaml was already removed in the security branch:
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/tree/security/iec-evaluation

Venkata-san: could you rebase your patches for the master branch?


For example, instead of sending one patch where you add opt-security.yaml and then another patch where you remove it (which may have happened in your branch, but we don't care), just send the patch that uses core-image-security. That will make things easier to review.
I understood now, i will rebase the patches with master branch and i will resend the patches for review, sorry for the confusion
Also, as we have talked in the meetings, it looks like the security layer at the moment is just adding some packages but don't you need to add configuration files to harden the final file system? For example, you may want to change the configuration of the ssh server so that passwords are not accepted (only ssh keys). And the same for the rest of packages. In that case, you probably want to create a new kas-security.yaml.
Currently we don't have such configuration changes, but most probably in the future may be after discussion with Certification Body we may need to include configurations to fullfill the security requirement, we will keep this point in security WG discussions and get some consensus.
Thanks,
Daniel


Re: Working on HTTPS connection

Akihiro Suzuki
 

Hi Mohammed,

 

Thank you very much for your offer!

I’m Akihiro Suzuki, a chair of SW Updates WG.

 

Currently, we are using BeagleBone Black (BBB) for developing our initial software update mechanism.

Of course we plan to port it to other reference hardware, but it is not done at the moment.

So, could you prepare BBB for the development?

 

Even if you can’t prepare it, you may work on the task you are interested in because it is not a hardware-specific.

The task aims to connect between client (SWUpdate) and server (hawkBit) via HTTPS.

 

Best regards,

Suzuki

 

From: cip-dev@... <cip-dev@...> On Behalf Of masashi.kudo@...
Sent: Tuesday, June 30, 2020 7:32 AM
To: cip-dev@...
Subject: Re: [cip-dev] Working on HTTPS connection

 

Hi, Mohammed-san,

 

Thanks very much for watching the talk, and welcome to cip-dev!

 

Regarding SW Update WG, the followings are the their wiki pages.

 

https://wiki.linuxfoundation.org/civilinfrastructureplatform/start#cip_software_updates

https://wiki.linuxfoundation.org/civilinfrastructureplatform/cip-sw-updates

 

Also, SW Update WG reports the latest status at IRC meetings which start at UTC (GMT) 09:00 every Thursday. Notifications of the meetings are sent 6-9 hours before the meetings.

 

Hope it helps.

 

Best regards,

--

M. Kudo

 

From: cip-dev@... <cip-dev@...> On Behalf Of Mohammed Billoo
Sent: Tuesday, June 30, 2020 1:57 AM
To: cip-dev@...
Subject: [cip-dev] Working on HTTPS connection

 

Hello!

 

I joined the mailing list from the recommendation on the IRC channel (after viewing the CIP talk at ELC). I'd like to work on the following issue: https://gitlab.com/cip-project/cip-sw-updates/cip-sw-updates-tasks/-/issues/8

 

I've written applications + drivers for u-boot, have worked on SSL (albeit for Amazon FreeRTOS), and have HW handy to hit the ground running (I have a DE1-SoC).

 

Is there any update on this task that should I be aware of?

 

Looking forward to contributing to this project!


--

Mohammed A Billoo

Founder

MAB Labs, LLC

201-338-2022


--
Mohammed Billoo
MAB Labs, LLC
www.mab-labs.com

1941 - 1960 of 6828