International Basic Sciences Programmer Letter Attached
International Basic Sciences Programmer Award Letter Attached Mr. F.T Fagebuder International Basic Sciences Programmer.pdf Description: Adobe PDF document
RE: Linux Firmware Signing
-Original Message-
From: Paul Moore [mailto:p...@paul-moore.com]
Sent: Thursday, August 27, 2015 4:57 PM
To: Luis R. Rodriguez
Cc: David Woodhouse; David Howells; Mimi Zohar; Andy Lutomirski; Kees Cook;
Roberts, William C; linux-security-mod...@vger.kernel.org; linux-
ker...@vger.kernel.org; linux-wireless@vger.kernel.org;
james.l.mor...@oracle.com; se...@hallyn.com; Vitaly Kuznetsov; Eric Paris;
seli...@tycho.nsa.gov; Stephen Smalley; Schaufler, Casey; Luis R. Rodriguez;
Dmitry Kasatkin; Greg Kroah-Hartman; Peter Jones; Takashi Iwai; Ming Lei; Joey
Lee; Vojtěch Pavlík; Kyle McMartin; Seth Forshee; Matthew Garrett; Johannes
Berg
Subject: Re: Linux Firmware Signing
On Thu, Aug 27, 2015 at 5:29 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Thu, Aug 27, 2015 at 10:57:23AM -, David Woodhouse wrote:
SELinux uses: security_load_policy(data, len), refer to selinuxfs
sel_load_ops.
Since its write operation on its file_operation is sel_write_load()
and that is as follows:
static ssize_t sel_write_load(struct file *file, const char __user *buf,
size_t count, loff_t *ppos) {
...
}
We should be able to add yet-another LSM hook here to let the kernel /
LSM have access to the inode, is that LSM hook desirable ? But folks,
before you answer note that there's a growing trend here! Its point 1
Kees had made earlier. I was hesitant to go into details as I think
fw signing needs to be baked first but.. since we're reviewing all
these details now it seems logical to go down the rabbit hole further.
Everywhere where we fetch a file from within the kernel either
directly (say firmware load, 802.11 regulatory request) or from
userspace request (SELinux policy load node) we end up having to
sprinkle a new LSM hook. In fact for modules and kexec there were
syscalls added too. There might be a possiblity for sharing some of these
requests / code so some review is in order for it.
Here's my review if we wanted to try sharing things, in consideration
and review of:
* SELinux policy files
* modules
* firmware / system data (consider replacing CRDA)
* kexec
* SELinux policy files:
sel_write_load() is very specific, its part of the selinuxfs and it
just uses copy_from_user() to dump the data from the file onto a
vmalloc'd piece of memory. We don't exactly read arbitrary files from the fs
then.
If we *really* wanted to generalize things further we probably could
but I'm not going to lead any discussion about design over selinuxfs,
I'll let the folks behind it think about that themselves.
While I question the usefulness of a SELinux policy signature in the general
case,
there are some situations where it might make sense, e.g. embedded systems
with no post-build customizations, and I'm not opposed to added a signature to
the policy file for that reason.
Even triggered updates make sense, since you can at least have some form of
trust
of where that binary policy came from.
However, I haven't given any serious thought yet to how we would structure the
new blob format so as to support both signed/unsigned policies as well as
existing policies which predate any PKCS #7 changes.
Huh, not following? Perhaps, I am not following what your laying down here.
Right now there is no signing on the selinux policy file. We should be able
to just use the firmware signing api's as is (I have not looked on linux-next
yet)
to unpack the blob. In the case of falling back to loading an unsigned blob, we
could do it ala kernel
module style. If it fails do to invalid format fall back to attempting to read
it as a straight policy file.
If it fails on signature verification, we could still unpack it and pass it on.
So you would want to
be able to control if the signed unpacking from pkcs7 fails, whether or not its
fatal.
We would also likely want to convey this state, the ability to change this
setting to userspace in a
Controlled fashion via selinuxfs. Ie I would want to know that I can load
modules without valid signatures,
And that my current policy file is in fact invalid or valid.
--
paul moore
www.paul-moore.com
[PATCH 1/3] mac80211: remove last_beacon/ave_beacon debugfs files
From: Johannes Berg johannes.b...@intel.com
These file aren't really useful:
- if per beacon data is required then you need to use
radiotap or similar anyway, debugfs won't help much
- average beacon signal is reported in station info in
nl80211 and can be looked up with iw
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/debugfs_netdev.c | 12
net/mac80211/ieee80211_i.h| 3 ---
net/mac80211/mlme.c | 1 -
3 files changed, 16 deletions(-)
diff --git a/net/mac80211/debugfs_netdev.c b/net/mac80211/debugfs_netdev.c
index 1021e87c051f..1d94419801f8 100644
--- a/net/mac80211/debugfs_netdev.c
+++ b/net/mac80211/debugfs_netdev.c
@@ -114,14 +114,6 @@ static ssize_t ieee80211_if_fmt_##name(
\
return scnprintf(buf, buflen, %pM\n, sdata-field); \
}
-#define IEEE80211_IF_FMT_DEC_DIV_16(name, field) \
-static ssize_t ieee80211_if_fmt_##name(
\
- const struct ieee80211_sub_if_data *sdata, \
- char *buf, int buflen) \
-{ \
- return scnprintf(buf, buflen, %d\n, sdata-field / 16); \
-}
-
#define IEEE80211_IF_FMT_JIFFIES_TO_MS(name, field)\
static ssize_t ieee80211_if_fmt_##name(
\
const struct ieee80211_sub_if_data *sdata, \
@@ -247,8 +239,6 @@ IEEE80211_IF_FILE_R(hw_queues);
/* STA attributes */
IEEE80211_IF_FILE(bssid, u.mgd.bssid, MAC);
IEEE80211_IF_FILE(aid, u.mgd.aid, DEC);
-IEEE80211_IF_FILE(last_beacon, u.mgd.last_beacon_signal, DEC);
-IEEE80211_IF_FILE(ave_beacon, u.mgd.ave_beacon_signal, DEC_DIV_16);
IEEE80211_IF_FILE(beacon_timeout, u.mgd.beacon_timeout, JIFFIES_TO_MS);
static int ieee80211_set_smps(struct ieee80211_sub_if_data *sdata,
@@ -606,8 +596,6 @@ static void add_sta_files(struct ieee80211_sub_if_data
*sdata)
{
DEBUGFS_ADD(bssid);
DEBUGFS_ADD(aid);
- DEBUGFS_ADD(last_beacon);
- DEBUGFS_ADD(ave_beacon);
DEBUGFS_ADD(beacon_timeout);
DEBUGFS_ADD_MODE(smps, 0600);
DEBUGFS_ADD_MODE(tkip_mic_test, 0200);
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 6e52659f923f..e5b2dcbb6606 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -490,9 +490,6 @@ struct ieee80211_if_managed {
s16 p2p_noa_index;
- /* Signal strength from the last Beacon frame in the current BSS. */
- int last_beacon_signal;
-
/*
* Weighted average of the signal strength from Beacon frames in the
* current BSS. This is in units of 1/16 of the signal unit to maintain
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 705ef1d040ed..a56a3274236c 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -3374,7 +3374,6 @@ static void ieee80211_rx_mgmt_beacon(struct
ieee80211_sub_if_data *sdata,
bssid = ifmgd-associated-bssid;
/* Track average RSSI from the Beacon frames of the current AP */
- ifmgd-last_beacon_signal = rx_status-signal;
if (ifmgd-flags IEEE80211_STA_RESET_SIGNAL_AVE) {
ifmgd-flags = ~IEEE80211_STA_RESET_SIGNAL_AVE;
ifmgd-ave_beacon_signal = rx_status-signal * 16;
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] mac80211: use DECLARE_EWMA for ave_beacon_signal
From: Johannes Berg johannes.b...@intel.com
It doesn't seem problematic to change the weight for the average
beacon signal from 3 to 4, so use DECLARE_EWMA. This also makes
the code easier to maintain since bugs like the one fixed in the
previous patch can't happen as easily.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/ieee80211_i.h | 10 +++---
net/mac80211/mlme.c| 20 ++--
net/mac80211/util.c| 2 +-
3 files changed, 10 insertions(+), 22 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index e5b2dcbb6606..904b3bbafd93 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -419,6 +419,8 @@ struct ieee80211_sta_tx_tspec {
bool downgraded;
};
+DECLARE_EWMA(beacon_signal, 16, 4)
+
struct ieee80211_if_managed {
struct timer_list timer;
struct timer_list conn_mon_timer;
@@ -490,13 +492,7 @@ struct ieee80211_if_managed {
s16 p2p_noa_index;
- /*
-* Weighted average of the signal strength from Beacon frames in the
-* current BSS. This is in units of 1/16 of the signal unit to maintain
-* accuracy and to speed up calculations, i.e., the value need to be
-* divided by 16 to get the actual value.
-*/
- int ave_beacon_signal;
+ struct ewma_beacon_signal ave_beacon_signal;
/*
* Number of Beacon frames used in ave_beacon_signal. This can be used
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index b4dd619da21e..cd705e820063 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -82,13 +82,6 @@ MODULE_PARM_DESC(probe_wait_ms,
before disconnecting (reason 4).);
/*
- * Weight given to the latest Beacon frame when calculating average signal
- * strength for Beacon frames received in the current BSS. This must be
- * between 1 and 15.
- */
-#define IEEE80211_SIGNAL_AVE_WEIGHT3
-
-/*
* How many Beacon frames need to have been used in average signal strength
* before starting to indicate signal change events.
*/
@@ -3376,21 +3369,19 @@ static void ieee80211_rx_mgmt_beacon(struct
ieee80211_sub_if_data *sdata,
/* Track average RSSI from the Beacon frames of the current AP */
if (ifmgd-flags IEEE80211_STA_RESET_SIGNAL_AVE) {
ifmgd-flags = ~IEEE80211_STA_RESET_SIGNAL_AVE;
- ifmgd-ave_beacon_signal = rx_status-signal * 16;
+ ewma_beacon_signal_init(ifmgd-ave_beacon_signal);
ifmgd-last_cqm_event_signal = 0;
ifmgd-count_beacon_signal = 1;
ifmgd-last_ave_beacon_signal = 0;
} else {
- ifmgd-ave_beacon_signal =
- (IEEE80211_SIGNAL_AVE_WEIGHT * rx_status-signal * 16 +
-(16 - IEEE80211_SIGNAL_AVE_WEIGHT) *
-ifmgd-ave_beacon_signal) / 16;
ifmgd-count_beacon_signal++;
}
+ ewma_beacon_signal_add(ifmgd-ave_beacon_signal, rx_status-signal);
+
if (ifmgd-rssi_min_thold != ifmgd-rssi_max_thold
ifmgd-count_beacon_signal = IEEE80211_SIGNAL_AVE_MIN_COUNT) {
- int sig = ifmgd-ave_beacon_signal / 16;
+ int sig = ewma_beacon_signal_read(ifmgd-ave_beacon_signal);
int last_sig = ifmgd-last_ave_beacon_signal;
struct ieee80211_event event = {
.type = RSSI_EVENT,
@@ -3417,10 +3408,11 @@ static void ieee80211_rx_mgmt_beacon(struct
ieee80211_sub_if_data *sdata,
if (bss_conf-cqm_rssi_thold
ifmgd-count_beacon_signal = IEEE80211_SIGNAL_AVE_MIN_COUNT
!(sdata-vif.driver_flags IEEE80211_VIF_SUPPORTS_CQM_RSSI)) {
- int sig = ifmgd-ave_beacon_signal / 16;
+ int sig = ewma_beacon_signal_read(ifmgd-ave_beacon_signal);
int last_event = ifmgd-last_cqm_event_signal;
int thold = bss_conf-cqm_rssi_thold;
int hyst = bss_conf-cqm_rssi_hyst;
+
if (sig thold
(last_event == 0 || sig last_event - hyst)) {
ifmgd-last_cqm_event_signal = sig;
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 1104421bc525..e079b556a990 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -2541,7 +2541,7 @@ int ieee80211_ave_rssi(struct ieee80211_vif *vif)
/* non-managed type inferfaces */
return 0;
}
- return ifmgd-ave_beacon_signal / 16;
+ return ewma_beacon_signal_read(ifmgd-ave_beacon_signal);
}
EXPORT_SYMBOL_GPL(ieee80211_ave_rssi);
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] mac80211: fix driver RSSI event calculations
From: Johannes Berg johannes.b...@intel.com
The ifmgd-ave_beacon_signal value cannot be taken as is for
comparisons, it must be divided by since it's represented
like that for better accuracy of the EWMA calculations. This
would lead to invalid driver RSSI events. Fix the used value.
Fixes: 615f7b9bb1f8 (mac80211: add driver RSSI threshold events)
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/mlme.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index a56a3274236c..b4dd619da21e 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -3390,7 +3390,7 @@ static void ieee80211_rx_mgmt_beacon(struct
ieee80211_sub_if_data *sdata,
if (ifmgd-rssi_min_thold != ifmgd-rssi_max_thold
ifmgd-count_beacon_signal = IEEE80211_SIGNAL_AVE_MIN_COUNT) {
- int sig = ifmgd-ave_beacon_signal;
+ int sig = ifmgd-ave_beacon_signal / 16;
int last_sig = ifmgd-last_ave_beacon_signal;
struct ieee80211_event event = {
.type = RSSI_EVENT,
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mac80211: reject software RSSI CQM with beacon filtering
From: Johannes Berg johannes.b...@intel.com When beacon filtering is enabled the mac80211 software implementation for RSSI CQM cannot work as beacons will not be available. Rather than accepting such a configuration without proper effect, reject it. Signed-off-by: Johannes Berg johannes.b...@intel.com --- net/mac80211/cfg.c | 4 1 file changed, 4 insertions(+) diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c index f4ed256c2d8e..a30ec3ce3d25 100644 --- a/net/mac80211/cfg.c +++ b/net/mac80211/cfg.c @@ -2468,6 +2468,10 @@ static int ieee80211_set_cqm_rssi_config(struct wiphy *wiphy, rssi_hyst == bss_conf-cqm_rssi_hyst) return 0; + if (sdata-vif.driver_flags IEEE80211_VIF_BEACON_FILTER + !(sdata-vif.driver_flags IEEE80211_VIF_SUPPORTS_CQM_RSSI)) + return -EOPNOTSUPP; + bss_conf-cqm_rssi_thold = rssi_thold; bss_conf-cqm_rssi_hyst = rssi_hyst; -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CT firmware and linux kernel patches for OpenWRT( ar71xx - Tp-Link 1750AC )
On Wednesday 26 August 2015 18:59:51 s prasad wrote: Does anybody have patches for CT firmware testing using OpenWRT environment. I tried to create patch, however OpenWRT patches supporting only for kernel versions 3.18 and 4.1 at the same time CT Kernels supporting 3.17_dev, 4.0.4 and 4.2.x. Both are miss matching. You have to patch mac80211 and not the kernel. I can give you the patchset I've used with OpenWrt r46435. You should get it in the next minutes via private mail (I don't want to send it over the mailing list due to its size). It is basically the patchset from Ben put on top of compat-wireless 2015-06-22 [1]. You still need extra changes to get VHT working over IBSS (iw will otherwise only use HT). When you only want to test it then you can just hardcode a channel + a channel width in iw's ibss.c. Kind regards, Sven [1] https://dev.cloudtrax.com/git/ath10k-ibss-test.git/shortlog/refs/heads/master-20150824 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ath10k: change beamformee VHT STS capability
On 27 August 2015 at 14:47, Michal Kazior michal.kaz...@tieto.com wrote:
From: Bartosz Markowski bartosz.markow...@tieto.com
All beamformee supporting chips have the ability to support
VHT NDP in up to 4 STSs. Change the published beamformee
STS cap accordingly to 3 as it should be Nsts-1.
This makes it possible to actually make full use
of. e.g. a 4SS MU-MIMO capable AP.
Signed-off-by: Bartosz Markowski bartosz.markow...@tieto.com
Signed-off-by: Michal Kazior michal.kaz...@tieto.com
---
Kalle, please drop this one for now. It looks like we need to discuss
about this a bit more still.
drivers/net/wireless/ath/ath10k/mac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 64674c955d44..54ced30f5364 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4074,7 +4074,7 @@ static int ath10k_mac_set_txbf_conf(struct ath10k_vif
*arvif)
if (ar-vht_cap_info (IEEE80211_VHT_CAP_SU_BEAMFORMEE_CAPABLE |
IEEE80211_VHT_CAP_MU_BEAMFORMEE_CAPABLE))
- value |= SM((ar-num_rf_chains - 1), WMI_TXBF_STS_CAP_OFFSET);
+ value |= SM(3, WMI_TXBF_STS_CAP_OFFSET);
if (ar-vht_cap_info (IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE |
IEEE80211_VHT_CAP_MU_BEAMFORMER_CAPABLE))
@@ -6804,7 +6804,7 @@ static struct ieee80211_sta_vht_cap
ath10k_create_vht_cap(struct ath10k *ar)
if (ar-vht_cap_info (IEEE80211_VHT_CAP_SU_BEAMFORMEE_CAPABLE |
IEEE80211_VHT_CAP_MU_BEAMFORMEE_CAPABLE)) {
- val = ar-num_rf_chains - 1;
+ val = 3;
val = IEEE80211_VHT_CAP_BEAMFORMEE_STS_SHIFT;
val = IEEE80211_VHT_CAP_BEAMFORMEE_STS_MASK;
--
2.1.4
--
Bartosz
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-nfc] [PATCH 1/8] NFC: NCI: Allow connection close with dev down
On Sun, May 24, 2015 at 8:07 PM, Samuel Ortiz sa...@linux.intel.com wrote:
Hi Robert,
On Tue, Mar 31, 2015 at 05:03:42PM +0300, Robert Dolca wrote:
On Thu, Mar 26, 2015 at 2:29 AM, Samuel Ortiz sa...@linux.intel.com wrote:
Hi Robert,
On Tue, Feb 24, 2015 at 12:01:45PM +0200, Robert Dolca wrote:
By calling __nci_request instead of nci_request allows the driver to use
the function while initializing the device (setup stage)
Signed-off-by: Robert Dolca robert.do...@intel.com
---
net/nfc/nci/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index 9575a18..c4dd5d8 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -558,7 +558,7 @@ static void nci_core_conn_close_req(struct nci_dev
*ndev, unsigned long opt)
int nci_core_conn_close(struct nci_dev *ndev, u8 conn_id)
{
- return nci_request(ndev, nci_core_conn_close_req, conn_id,
+ return __nci_request(ndev, nci_core_conn_close_req, conn_id,
msecs_to_jiffies(NCI_CMD_TIMEOUT));
You're fixing your problem by removing the NCI request serialization and
removing the check for your device being UP.
I assume you need to open and close a proprietary connection from your
setup hook ? Then please extend nci_request() to check for both NCI_UP
and NCI_INIT.
You are right, I am opening and closing a connection from the setup
function. The setup is called by nci_open_device. At the beginning of
nci_open_device, req_lock is being acquired and it is release at the
end of the function. That means that when setup is being called
req_lock is acuired. As you said I can modify nci_request to check for
NCI_INIT but it tries to acquire req_lock and it can not succeed.
I see, I thought the issue was only about checking the NCI_* flags.
As a short term solution, I propose you do the following:
a) Export nci_core_conn_create_req, nci_core_conn_close_req and
__nci_request.
b) Call __nci_request() directly from your fdp_nci_close_conn() and
fdp_nci_create_conn() routines.
The long term, scalable fix would be to implement and export an
__nci_send_cmd_sync() routine, that would transparently build an NCI
request and tail it to the ndev req skb queue, and put the caller on a
wait queue. The created request's response callback would then wake the
caller up.
If nci_open_device would use another mutex instead of req_lock this
wouldn't be necessary.
I don't see any reason why nci_open_device should block the send
queue. Of course, in nci_open_device all calls to __nci_request would
have to be replaced with nci_request.
Samuel, would that be an acceptable solution?
Regards,
Robert
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] wireless: mark element IDs 8 and 9 reserved
From: Johannes Berg johannes.b...@intel.com
These were never used in the tree, and are marked as reserved
in the IEEE 802.11 documentation (ANA).
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
include/linux/ieee80211.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index cfa906f28b7a..b9882efb3dfb 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -1745,8 +1745,7 @@ enum ieee80211_eid {
WLAN_EID_TIM = 5,
WLAN_EID_IBSS_PARAMS = 6,
WLAN_EID_COUNTRY = 7,
- WLAN_EID_HP_PARAMS = 8,
- WLAN_EID_HP_TABLE = 9,
+ /* 8, 9 reserved */
WLAN_EID_REQUEST = 10,
WLAN_EID_QBSS_LOAD = 11,
WLAN_EID_EDCA_PARAM_SET = 12,
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] utils/key2pub: use python2 explicitly
On systems that have python3 as the default /usr/bin/python provider, specifying `python` causes the build to fail. From f4607ed246476b3ed58b4ce25cfdc6348a4a6bd1 Mon Sep 17 00:00:00 2001 From: Kylie McClain soma...@exherbo.org Date: Thu, 27 Aug 2015 21:29:48 -0400 Subject: [PATCH] utils/key2pub: use python2 explicitly Signed-off-by: Kylie McClain soma...@exherbo.org --- utils/key2pub.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/utils/key2pub.py b/utils/key2pub.py index 3e84cd2..8bea042 100755 --- a/utils/key2pub.py +++ b/utils/key2pub.py @@ -1,4 +1,4 @@ -#!/usr/bin/env python +#!/usr/bin/env python2 import sys try: -- 2.5.0 -- Kylie McClain, Exherbo Linux developer and Musician https://somasis.com - https://github.com/Somasis -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ath10k: Fix DMA alloc failure for target requested memory chunks
During long hours of stress testing like AP interface up/down along
with continuous ping flood from a station doing connect/disconnect,
it is observed that the system is not able to allocate DMA consistent
memory of size 512KB chunks as requested by firmware in WMI_SERVICE_EVENTID.
With the system memory getting fragmented during the run based on the
size of the memory requested, the failure to return physically continguous
memory of high order can happen. Once the system gets to this situation,
bringing up the wifi interface will fail and a system reboot may be needed
to make it work again. This problem is obseved with QCA99X0.
To fix this issue, allocate the DMA memory requested by firmware during
device probe time and keep it during the life time of the device. WMI service
ready event handler is changed to allocate the memory chunks if it is
not already allocated or if the memory allocated for the previous ready
event is not same as the current requested ones. After this patch the
memory usage when wifi is inactive will be inceased by few 100KB to
3MB based on the target type.
Failure happens with the following stack trace
[29557.488773] kworker/u4:1: page allocation failure: order:8, mode:0xd0
[29557.494297] CPU: 0 PID: 8402 Comm: kworker/u4:1 Not tainted 3.14.43 #7
[29557.500793] Workqueue: ath10k_aux_wq ath10k_wmi_event_service_ready_work
[ath10k_core]
[29557.508602] [c021e9b0] (unwind_backtrace) from [c021ba90]
(show_stack+0x10/0x14)
[29557.516580] [c021ba90] (show_stack) from [c03bdddc]
(dump_stack+0x88/0xcc)
[29557.523612] [c03bdddc] (dump_stack) from [c0290e34]
(warn_alloc_failed+0xdc/0x108)
[29557.531515] [c0290e34] (warn_alloc_failed) from [c0292d88]
(__alloc_pages_nodemask+0x4f0/0x654)
[29557.540485] [c0292d88] (__alloc_pages_nodemask) from [c0222b48]
(__dma_alloc_buffer.isra.20+0x2c/0x104)
[29557.550260] [c0222b48] (__dma_alloc_buffer.isra.20) from [c0222c34]
(__alloc_remap_buffer.isra.23+0x14/0xb8)
[29557.560413] [c0222c34] (__alloc_remap_buffer.isra.23) from [c022305c]
(__dma_alloc+0x224/0x2b8)
[29557.569490] [c022305c] (__dma_alloc) from [c0223208]
(arm_dma_alloc+0x84/0x90)
[29557.577010] [c0223208] (arm_dma_alloc) from [bf5159d0]
(ath10k_wmi_event_service_ready_work+0x2f8/0x420 [ath10k_core])
[29557.588055] [bf5159d0] (ath10k_wmi_event_service_ready_work [ath10k_core])
from [c024260c] (process_one_work+0x20c/0x328)
[29557.599305] [c024260c] (process_one_work) from [c02432d0]
(worker_thread+0x228/0x360)
[29557.607470] [c02432d0] (worker_thread) from [c0247f88]
(kthread+0xd8/0xec)
[29557.614750] [c0247f88] (kthread) from [c0208d18]
(ret_from_fork+0x14/0x3c)
[29557.712751] Normal: 696*4kB (UEMR) 512*8kB (UEMR) 367*16kB (UEMR) 404*32kB
(UEMR) 455*64kB (UEMR) 424*128kB (UEMR) 379*256kB (UMR) 327*512kB (UMR)
1*1024kB (R) 0*2048kB 0*4096kB = 374544kB
Signed-off-by: Vasanthakumar Thiagarajan vthia...@qti.qualcomm.com
---
drivers/net/wireless/ath/ath10k/core.c | 1 +
drivers/net/wireless/ath/ath10k/wmi.c | 76 +++---
drivers/net/wireless/ath/ath10k/wmi.h | 1 +
3 files changed, 72 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index b87b986..6e5aeed 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1714,6 +1714,7 @@ void ath10k_core_destroy(struct ath10k *ar)
destroy_workqueue(ar-workqueue_aux);
ath10k_debug_destroy(ar);
+ ath10k_wmi_free_host_mem(ar);
ath10k_mac_destroy(ar);
}
EXPORT_SYMBOL(ath10k_core_destroy);
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index ce01107..87d9de2 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3917,6 +3917,53 @@ static int ath10k_wmi_alloc_host_mem(struct ath10k *ar,
u32 req_id,
return 0;
}
+static bool
+ath10k_wmi_is_host_mem_allocated(struct ath10k *ar,
+const struct wlan_host_mem_req **mem_reqs,
+u32 num_mem_reqs)
+{
+ u32 req_id, num_units, unit_size, num_unit_info;
+ u32 pool_size;
+ int i, j;
+ bool found;
+
+ if (ar-wmi.num_mem_chunks != num_mem_reqs)
+ return false;
+
+ for (i = 0; i num_mem_reqs; ++i) {
+ req_id = __le32_to_cpu(mem_reqs[i]-req_id);
+ num_units = __le32_to_cpu(mem_reqs[i]-num_units);
+ unit_size = __le32_to_cpu(mem_reqs[i]-unit_size);
+ num_unit_info = __le32_to_cpu(mem_reqs[i]-num_unit_info);
+
+ if (num_unit_info NUM_UNITS_IS_NUM_ACTIVE_PEERS) {
+ if (ar-num_active_peers)
+ num_units = ar-num_active_peers + 1;
+ else
+ num_units = ar-max_num_peers + 1;
+ } else if (num_unit_info NUM_UNITS_IS_NUM_PEERS) {
+
Re: Linux Firmware Signing
On Fri, Aug 28, 2015 at 06:26:05PM -0400, Paul Moore wrote: On Fri, Aug 28, 2015 at 7:20 AM, Roberts, William C william.c.robe...@intel.com wrote: Even triggered updates make sense, since you can at least have some form of trust of where that binary policy came from. It isn't always that simple, see my earlier comments about customization and manipulation by the policy loading tools. If the customization of the data is done in kernel then the kernel can *first* verify the file's signature prior to doing any data modification. If userspace does the modification then the signature stuff won't work unless the tool will have access to the MOK and can sign it pre-flight to the kernel selinuxfs. Huh, not following? Perhaps, I am not following what your laying down here. Right now there is no signing on the selinux policy file. We should be able to just use the firmware signing api's as is (I have not looked on linux-next yet) to unpack the blob. I haven't looked at the existing fw signing hook in any detail to be able to comment on its use as a policy verification hook. As long as we preserve backwards compatibility and don't introduce a new mechanism/API for loading SELinux policy I doubt I would have any objections. You'd just have to implement a permissive model as we are with the fw signing. No radical customizations, except one thing to note is that on the fw signing side of things we're going to have the signature of the file *detached* in separate file. I think what you're alluding to is the issue of where that signature would be stuff in the SELinux policy file and its correct that you'd need to address that. You could just borrow the kernel's model and reader / sucker that strips out the signature. Another possibility would be two files but then I guess you'd need a trigger to annotate both are in place. Luis -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux Firmware Signing
On Thu, Aug 27, 2015 at 07:54:33PM -0400, Mimi Zohar wrote:
On Thu, 2015-08-27 at 23:29 +0200, Luis R. Rodriguez wrote:
On Thu, Aug 27, 2015 at 10:57:23AM -, David Woodhouse wrote:
Luis R. Rodriguez mcg...@suse.com wrote:
PKCS#7: Add an optional authenticated attribute to hold firmware name
https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7id=1448377a369993f864915743cfb34772e730213good
1.3.6.1.4.1.2312.16 Linux kernel
1.3.6.1.4.1.2312.16.2 - PKCS#7/CMS SignerInfo attribute types
1.3.6.1.4.1.2312.16.2.1 - firmwareName
I take it you are referring to this?
Yes.
If we follow this model we'd then need something like:
1.3.6.1.4.1.2312.16.2.2 - seLinuxPolicyName
That should mean each OID that has different file names would need to
be
explicit about and have a similar entry on the registry. I find that
pretty redundant and would like to avoid that if possible.
firmwareName is easy for people to understand - it's the name the kernel
asks for and the filename of the blob. seLinuxPolicyName is, I think, a
lot more tricky since a lot of people don't use SELinux, and most that
do
don't understand it (most people that use it aren't even really aware of
it).
If you can use the firmwareName as the SELinux/LSM key, I would suggest
doing so - even if you dress it up as a path
(/lib/firmware/firmwareName).
In conversation with Mimi last week she was very keen on the model where
we load modules firmware in such a fashion that the kernel has access to
the original inode -- by passing in a fd,
Sure, so let's be specific to ensure what Mimi needs is there. I though
there
was work needed on modules but that seems covered and work then seems only
needed for kexec and SELinux policy files (and a review of other possible
file
consumers in the kernel) for what you describe.
Correct me if I'm wrong:
At last year's LSS linux-integrity status update, I mentioned 6
measurement/appraisal gaps, kernel modules (linux-3.7),
Done.
firmware (linux-3.17),
I'm working on it, but as far as LSMs are concerned the LSM hook
is in place.
kexec,
I'll note kexec has both a kernel and initramfs :) so just keep that
in mind. Technically it should vet for both. It seems we just need
an LSM hook there.
initramfs,
Hm, what code path?
eBPF/seccomp
Same here, where's this?
and policies,
Which ones?
that have
been or need to be addressed. Since then, a new kexec syscall, file
descriptor based, was upstreamed that appraises the image. Until we can
preserve the measurement list across kexec,
I'm sorry I do not follow, can you elaborate on what you mean by this.
Its not clear to me what you mean by the measurement list. Do you mean
all the above items?
it doesn't make sense to
measure the image just to have it thrown away. (skipping initramfs as
that isn't related to LSM hooks
Hrm, it can be, I mean at least for the kexec case its a fd that is passed
as part of the syscall, not sure of the other case you mentioned yet
as I haven't reviewed that code yet.
.) Lastly, measuring/appraising policies
(eg. IMA, SELinux, Smack, iptables/ebtables)
OK for each of these:
how do we load the data? Is that the full list? Note we should
be able to use grammar rules to hunt these down, I just haven't
sat down to write them but if this is important well we should.
or any other files consumed
by the kernel.
:D likewise
I also went ahead and studied
areas where we can share code now as I was looking at this code now, and
also
would like to recap on the idea of possibly just sharing the same LSM hook
for all read this special file from the fs in the kernel cases. Details
below.
Fortnately the LSM hooks uses struct file and with this you can get the
inode
with this:
struct inode *inode = file_inode(file);
For modules we have this LSM hook:
int (*kernel_module_from_file)(struct file *file);
This can be used for finit_module(). Its used as follows, the fd comes from
finit_module() syscall.
SYSCALL_DEFINE3(finit_module, int, fd, const char __user *, uargs, int,
flags)
{
...
err = copy_module_from_fd(fd, info);
if (err)
return err;
...
}
static int copy_module_from_fd(int fd, struct load_info *info)
{
struct fd f = fdget(fd);
...
err = security_kernel_module_from_file(f.file);
if (err)
goto out;
}
For firmware we have this LSM hook:
int (*kernel_fw_from_file)(struct file *file, char *buf, size_t size);
or in the firmware case by doing the fs
Ubuntu 14.04 and the intel 3160 chip monitor mode support
Hi, I am having issues with monitor mode with ubuntu 14.04 and the intel 3160 chip. I am having similar issues with 3.13 and a 7265 chip on a intel NUC Monitor mode says it takes but it captures no packets and help would be appreciated Thanks John Commands that trigger the crash : sudo ifconfig wlan0 down sudo iwconfig wlan0 mode monitor sudo ifconfig wlan0 up Ubuntu 14.04.3 LTS uname -a: Linux 3.13.0-62-generic #102-Ubuntu SMP Tue Aug 11 14:29:36 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux lspci -k : 03:00.0 Network controller: Intel Corporation Wireless 3160 (rev 83) Subsystem: Intel Corporation Dual Band Wireless-AC 3160 Kernel driver in use: iwlwifi dmesg: [ 2481.330395] iwlwifi :03:00.0: L1 Disabled - LTR Enabled [ 2481.330722] iwlwifi :03:00.0: L1 Disabled - LTR Enabled [ 2481.344124] iwlwifi :03:00.0: Microcode SW error detected. Restarting 0x200. [ 2481.344133] iwlwifi :03:00.0: CSR values: [ 2481.344136] iwlwifi :03:00.0: (2nd byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG) [ 2481.344143] iwlwifi :03:00.0:CSR_HW_IF_CONFIG_REG: 0X00c89204 [ 2481.344148] iwlwifi :03:00.0: CSR_INT_COALESCING: 0X8000ff40 [ 2481.344154] iwlwifi :03:00.0: CSR_INT: 0X [ 2481.344160] iwlwifi :03:00.0:CSR_INT_MASK: 0X [ 2481.344165] iwlwifi :03:00.0: CSR_FH_INT_STATUS: 0X [ 2481.344170] iwlwifi :03:00.0: CSR_GPIO_IN: 0X [ 2481.344176] iwlwifi :03:00.0: CSR_RESET: 0X [ 2481.344182] iwlwifi :03:00.0:CSR_GP_CNTRL: 0X080403c5 [ 2481.344187] iwlwifi :03:00.0: CSR_HW_REV: 0X0164 [ 2481.344193] iwlwifi :03:00.0: CSR_EEPROM_REG: 0X [ 2481.344198] iwlwifi :03:00.0: CSR_EEPROM_GP: 0X8000 [ 2481.344204] iwlwifi :03:00.0: CSR_OTP_GP_REG: 0X803a [ 2481.344209] iwlwifi :03:00.0: CSR_GIO_REG: 0X00080044 [ 2481.344215] iwlwifi :03:00.0:CSR_GP_UCODE_REG: 0X [ 2481.344220] iwlwifi :03:00.0: CSR_GP_DRIVER_REG: 0X [ 2481.344225] iwlwifi :03:00.0: CSR_UCODE_DRV_GP1: 0X [ 2481.344231] iwlwifi :03:00.0: CSR_UCODE_DRV_GP2: 0X [ 2481.344236] iwlwifi :03:00.0: CSR_LED_REG: 0X0060 [ 2481.344242] iwlwifi :03:00.0:CSR_DRAM_INT_TBL_REG: 0X881f6fb6 [ 2481.344247] iwlwifi :03:00.0:CSR_GIO_CHICKEN_BITS: 0X27800200 [ 2481.344253] iwlwifi :03:00.0: CSR_ANA_PLL_CFG: 0Xd5d5 [ 2481.344258] iwlwifi :03:00.0: CSR_HW_REV_WA_REG: 0X0001001a [ 2481.344263] iwlwifi :03:00.0:CSR_DBG_HPET_MEM_REG: 0X [ 2481.344267] iwlwifi :03:00.0: FH register values: [ 2481.344281] iwlwifi :03:00.0: FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X21084000 [ 2481.344295] iwlwifi :03:00.0:FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X01f5c740 [ 2481.344309] iwlwifi :03:00.0: FH_RSCSR_CHNL0_WPTR: 0X0018 [ 2481.344323] iwlwifi :03:00.0: FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80801114 [ 2481.344337] iwlwifi :03:00.0: FH_MEM_RSSR_SHARED_CTRL_REG: 0X00fc [ 2481.344351] iwlwifi :03:00.0:FH_MEM_RSSR_RX_STATUS_REG: 0X0703 [ 2481.344365] iwlwifi :03:00.0:FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X [ 2481.344379] iwlwifi :03:00.0:FH_TSSR_TX_STATUS_REG: 0X07ff0001 [ 2481.344394] iwlwifi :03:00.0: FH_TSSR_TX_ERROR_REG: 0X [ 2481.344507] iwlwifi :03:00.0: Start IWL Error Log Dump: [ 2481.344511] iwlwifi :03:00.0: Status: 0x, count: 6 [ 2481.344514] iwlwifi :03:00.0: Loaded firmware version: 22.24.8.0 [ 2481.344518] iwlwifi :03:00.0: 0x0103 | ADVANCED_SYSASSERT [ 2481.344521] iwlwifi :03:00.0: 0x02F0 | uPc [ 2481.344524] iwlwifi :03:00.0: 0x | branchlink1 [ 2481.344527] iwlwifi :03:00.0: 0x0BEA | branchlink2 [ 2481.344529] iwlwifi :03:00.0: 0x00014218 | interruptlink1 [ 2481.344532] iwlwifi :03:00.0: 0x0029E0D2 | interruptlink2 [ 2481.344535] iwlwifi :03:00.0: 0xDEADBEEF | data1 [ 2481.344538] iwlwifi :03:00.0: 0xDEADBEEF | data2 [ 2481.344541] iwlwifi :03:00.0: 0xDEADBEEF | data3 [ 2481.344543] iwlwifi :03:00.0: 0x003FE7E9 | beacon time [ 2481.344546] iwlwifi :03:00.0: 0x1816 | tsf low [ 2481.344549] iwlwifi :03:00.0: 0x | tsf hi [ 2481.344552] iwlwifi :03:00.0: 0x | time gp1 [ 2481.344555] iwlwifi :03:00.0: 0x1816 | time gp2 [ 2481.344557] iwlwifi :03:00.0: 0x | time gp3 [ 2481.344560] iwlwifi :03:00.0: 0x00041618 | uCode version [ 2481.344563] iwlwifi :03:00.0: 0x0164 | hw version [ 2481.344566] iwlwifi :03:00.0: 0x00C89204 | board version [ 2481.344569] iwlwifi :03:00.0:
Re: Linux Firmware Signing
On Fri, Aug 28, 2015 at 11:20:10AM +, Roberts, William C wrote: -Original Message- From: Paul Moore [mailto:p...@paul-moore.com] While I question the usefulness of a SELinux policy signature in the general case, there are some situations where it might make sense, e.g. embedded systems with no post-build customizations, and I'm not opposed to added a signature to the policy file for that reason. Even triggered updates make sense, since you can at least have some form of trust of where that binary policy came from. The problem that Paul describes stems from the requirement of such trust needing post-boot / install / setup keys. It may be possible for an environment to exist where there's a food chain that enables some CA's to easily hand out keys to each install, but that seems impractical. This is why Paul had mentioned the Machine Owner Key (MOK) thing. However, I haven't given any serious thought yet to how we would structure the new blob format so as to support both signed/unsigned policies as well as existing policies which predate any PKCS #7 changes. Huh, not following? Perhaps, I am not following what your laying down here. Right now there is no signing on the selinux policy file. We should be able to just use the firmware signing api's as is (I have not looked on linux-next yet) Nitpick: its the system_verify_data() API, the fw signing stuff will make use of this API as well. to unpack the blob. Nitpick: to verify the data. In the case of falling back to loading an unsigned blob, we could do it ala kernel module style. If it fails do to invalid format fall back to attempting to read it as a straight policy file. If it fails on signature verification, we could still unpack it and pass it on. So you would want to be able to control if the signed unpacking from pkcs7 fails, whether or not its fatal. We would also likely want to convey this state, the ability to change this setting to userspace in a Controlled fashion via selinuxfs. Ie I would want to know that I can load modules without valid signatures, And that my current policy file is in fact invalid or valid. Sure that would work. Its how the module stuff can work in permissive mode. We'd embrace the same practice for permissive fw signing as well. Luis -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux Firmware Signing
On Fri, Aug 28, 2015 at 7:20 AM, Roberts, William C
william.c.robe...@intel.com wrote:
-Original Message-
From: Paul Moore [mailto:p...@paul-moore.com]
Sent: Thursday, August 27, 2015 4:57 PM
To: Luis R. Rodriguez
Cc: David Woodhouse; David Howells; Mimi Zohar; Andy Lutomirski; Kees Cook;
Roberts, William C; linux-security-mod...@vger.kernel.org; linux-
ker...@vger.kernel.org; linux-wireless@vger.kernel.org;
james.l.mor...@oracle.com; se...@hallyn.com; Vitaly Kuznetsov; Eric Paris;
seli...@tycho.nsa.gov; Stephen Smalley; Schaufler, Casey; Luis R. Rodriguez;
Dmitry Kasatkin; Greg Kroah-Hartman; Peter Jones; Takashi Iwai; Ming Lei;
Joey
Lee; Vojtěch Pavlík; Kyle McMartin; Seth Forshee; Matthew Garrett; Johannes
Berg
Subject: Re: Linux Firmware Signing
On Thu, Aug 27, 2015 at 5:29 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Thu, Aug 27, 2015 at 10:57:23AM -, David Woodhouse wrote:
SELinux uses: security_load_policy(data, len), refer to selinuxfs
sel_load_ops.
Since its write operation on its file_operation is sel_write_load()
and that is as follows:
static ssize_t sel_write_load(struct file *file, const char __user *buf,
size_t count, loff_t *ppos) {
...
}
We should be able to add yet-another LSM hook here to let the kernel /
LSM have access to the inode, is that LSM hook desirable ? But folks,
before you answer note that there's a growing trend here! Its point 1
Kees had made earlier. I was hesitant to go into details as I think
fw signing needs to be baked first but.. since we're reviewing all
these details now it seems logical to go down the rabbit hole further.
Everywhere where we fetch a file from within the kernel either
directly (say firmware load, 802.11 regulatory request) or from
userspace request (SELinux policy load node) we end up having to
sprinkle a new LSM hook. In fact for modules and kexec there were
syscalls added too. There might be a possiblity for sharing some of these
requests / code so some review is in order for it.
Here's my review if we wanted to try sharing things, in consideration
and review of:
* SELinux policy files
* modules
* firmware / system data (consider replacing CRDA)
* kexec
* SELinux policy files:
sel_write_load() is very specific, its part of the selinuxfs and it
just uses copy_from_user() to dump the data from the file onto a
vmalloc'd piece of memory. We don't exactly read arbitrary files from the
fs
then.
If we *really* wanted to generalize things further we probably could
but I'm not going to lead any discussion about design over selinuxfs,
I'll let the folks behind it think about that themselves.
While I question the usefulness of a SELinux policy signature in the general
case,
there are some situations where it might make sense, e.g. embedded systems
with no post-build customizations, and I'm not opposed to added a signature
to
the policy file for that reason.
Even triggered updates make sense, since you can at least have some form of
trust
of where that binary policy came from.
It isn't always that simple, see my earlier comments about
customization and manipulation by the policy loading tools. Policy
signatures are nice, I support their addition, but I believe they will
only be useful for certain usage scenarios and not really usable for
general systems.
However, I haven't given any serious thought yet to how we would structure
the
new blob format so as to support both signed/unsigned policies as well as
existing policies which predate any PKCS #7 changes.
Huh, not following? Perhaps, I am not following what your laying down here.
Right now there is no signing on the selinux policy file. We should be able
to just use the firmware signing api's as is (I have not looked on linux-next
yet)
to unpack the blob.
I haven't looked at the existing fw signing hook in any detail to be
able to comment on its use as a policy verification hook. As long as
we preserve backwards compatibility and don't introduce a new
mechanism/API for loading SELinux policy I doubt I would have any
objections.
In the case of falling back to loading an unsigned blob, we could do it ala
kernel
module style. If it fails do to invalid format fall back to attempting to
read it as a straight policy file.
It seems like we could aim to do a bit better than try-and-see, but
once again, I haven't looked at yet in detail so I'll defer to you
judgement at this point.
If it fails on signature verification, we could still unpack it and pass it
on. So you would want to
be able to control if the signed unpacking from pkcs7 fails, whether or not
its fatal.
We would also likely want to convey this state, the ability to change this
setting to userspace in a
Controlled fashion via selinuxfs. Ie I would want to know that I can load
modules without valid signatures,
And that my
