[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH 15/15] xsm: add a default policy to .init.data
- To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxx
- From: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
- Date: Thu, 9 Jun 2016 12:58:17 -0400
- Delivery-date: Thu, 09 Jun 2016 16:58:29 +0000
- Ironport-phdr: 9a23:wiRgoh9GAoOaGf9uRHKM819IXTAuvvDOBiVQ1KB80e8cTK2v8tzYMVDF4r011RmSDdSdtK8P2rWempujcFJDyK7JiGoFfp1IWk1NouQttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXsq3G/pQQfBg/4fVIsYL+lS8iN0o/miKibwN76XUZhvHKFe7R8LRG7/036l/I9ps9cEJs30QbDuXBSeu5blitCLFOXmAvgtI/rpMYwuwwZgf8q9tZBXKPmZOx4COUAVHV1DnoxrPHPmVGDCFHXpyhUbmJDuxxEGQXapDr9WY/8qGOuv+xxwiSFe8bxSqg5Q2+K5KZ3Uh74ziwAMmh9uHHajIl8gbxWpDqlpgdj2MjEbYfTM+BxLY3HetZPaWNHX8tVHwBMSqymZoIBR74NMupVoJP0j0cfphu5Qw+3DaXgzSEe1Sy+5rEzz+l0SVKO5wcnBd9b9S2O9Ng=
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
On 06/09/2016 11:30 AM, Andrew Cooper wrote:
On 09/06/16 15:47, Daniel De Graaf wrote:
diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
index 4a264c2..6ffccb2 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -36,6 +36,17 @@ static inline int verify(struct xsm_operations *ops)
return 0;
}
+extern char __xsm_init_policy_start[], __xsm_init_policy_end[];
+
+static void __init xsm_policy_init(void)
+{
+ if ( policy_size == 0 && __xsm_init_policy_end != __xsm_init_policy_start )
+ {
+ policy_buffer = __xsm_init_policy_start;
I think this might cause a problem for ARM.
xsm_dt_init(void) does
ret = xsm_core_init();
xfree(policy_buffer);
which might now try freeing a piece of initdata. Even going back to c/s
a8f2fb51c19 which introduced this code, I can't spot its justification.
The buffer is allocated and populated in xsm_dt_policy_init.
It also looks like the entire policy buffer can be const, at which point
it can be linked slightly higher in .init.data with the other
logically-const data.
Sure, although this will require quite a bit of const propagation down into
the FLASK security server (or casting it away).
--
Daniel De Graaf
National Security Agency
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
