INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Selon un mode de mise en œuvre, les instructions destinées à être exécutées dans le contexte d’exécution de niveau de droits d’accès sécurisé, sont directement générées avec le niveau de droit d’accès exclusivement sécurisé.
Selon un mode de mise en œuvre, ladite identification dans le code source, comprend une sélection de fonctions présentant une déclaration, dans le code source, communiquant ladite sélection.
Selon un autre aspect il est également proposé un produit programme d’ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre le procédé tel que définit ci-avant.
Selon un autre aspect, il est également proposé un support lisible par ordinateur comprenant des instructions qui, lorsqu’elles sont exécutées par un ordinateur, conduisent celui-ci à mettre en œuvre le procédé tel que définit ci-avant.
Selon un autre aspect, est également proposé un circuit intégré comportant une unité de traitement adaptée pour mettre en œuvre la phase de compilation du procédé tel que défini ci-avant, et pour exécuter le programme logiciel compilé, ladite unité de traitement pouvant avoir des contextes d’exécution de niveaux de droits d’accès sécurisé et non-sécurisé, et/ou des contextes d’exécution de niveaux de droits d’accès privilégié et non-privilégié.
Selon un autre aspect, il est proposé un circuit intégré comportant une unité de traitement adaptée pour avoir un contexte d’exécution de niveau de droits d’accès sécurisé et un contexte d’exécution de niveau de droits d’accès non-sécurisé, l’unité de traitement étant capable de traiter des instructions ayant un niveau de droits d’accès exclusivement sécurisé et étant matériellement configuré de sorte qu’une exécution desdites instructions peut accéder à des zones mémoires de niveau de droit d’accès sécurisé, et ne peut pas accéder à des zones mémoires de niveau de droit d’accès non-sécurisé.
Selon un mode de réalisation, l’unité de traitement est configurée pour tester une donnée représentative du niveau de droits d’accès exclusivement sécurisé, dans un code binaire des instructions exécutées, et traiter l’instruction avec la configuration matérielle correspondant au niveau de droits d’accès communiqué par ladite donnée.
Il est déjà connu des produits de ce type en particulier les hydrocarbures obtenus par la synthèse de Fischer-Tropsch et des dérivés de la pyrolyse de la biomasse.
Mais, pour permettre l’utilisation à très grande échelle de combustibles liquides renouvelables, il faut développer d’autres produits à partir de ressources largement disponibles, par des procédés simples, à un coût faible et sans avoir à remplacer les équipements de chauffage tels que les chaudières et les radiateurs.
Une condition impérative pour cela est d’utiliser des biocombustibles renouvelables ayant un point éclair compatible avec règles de sécurité applicables aux combustibles fossiles, à savoir un point éclair supérieur à 55°C pour le remplacement du fioul domestique et un point éclair supérieur à 70°C pour le remplacement du fioul lourd. Ceci exclut de nombreux combustibles renouvelables tels que les mono-alcools à moins de 6 atomes de carbone dans la molécule et les esters à moins de 9 atomes de carbone.
L’invention répond à ce probléme par l’utilisation de di-alcools ayant un point éclair suffisamment élevé, tels que l’ethylène glycol qui a un point éclair de 111°C et le propylène glycol, aussi appelé propanediol, dont les isomères, 1,2 propanediol ou 1,3 propanediol, ont tous deux un point éclair supérieur à 100°C.
Ces produits peuvent être obtenus de différentes manières : par modification chimique ou fermentation de la biomasse agricole ou forestière ou de sous-produits des industries agricoles et forestières, soit à partir du gaz carbonique de l’atmosphère par électro-réduction ou hydrogénation, ce qui correspond à une ressource très abondante.
Ces produits peuvent être utilisés en mélange avec les combustibles fossiles en fonction de leur solubilité dans ces derniers qui dépend notamment de la température. On caractérise ces mélanges par le taux d’incorporation volumique qui est de x% quand on mélange x% de combustible renouvelable avec 1-x% de combustible fossile. Dans toute la mesure du possible, on vise un taux d’incorporation volumique supérieur à 5%.
Ces produits peuvent surtout, de manière surprenante car ceci n’a jamais été utilisé de façon industrielle, remplacer à 100% les combustibles fossiles dans les chaudières et les fours. Il faut seulement dans certains cas adapter les réglages de la température et la proportion d’air au niveau du bruleur pour tenir compte de la viscosité et de la composition chimique de ces produits qui est différente de celle des combustibles fossiles.
Exemple 1. Utilisation d’éthylène glycol en substitution complète du fioul domestique
L’éthylène glycol a un point éclair de 111°C et une viscosité de 1 mPa.s à 25°C.
De l’éthylène glycol pur a été utilisé en substitution complète du fioul domestique dans une petite chaudière destinée à faire des tests de combustion. Le fonctionnement de la chaudière s’est révélé satisfaisant. Les émissions de particules et d’hydrocarbures imbrulés ont été fortement réduites par rapport à celles du fioul domestique.
Exemple 2. Utilisation de 1,2 propanediol en substitution complète du fioul lourd
Le 1,2 propanediol a un point éclair de 107°C et une viscosité de 58 mPa.s à 20°C.
Du 1,2 propanediol a été utilisé en substitution du fioul lourd dans une petite chaudière destinée à faire des tests de combustion. Il n’a pas été nécessaire de procéder à un réchauffage du combustible comme c’est le cas pour la combustion du fioul lourd. Le fonctionnement de la chaudière s’est révélé satisfaisant. Les émissions de particules et d’hydrocarbures imbrulés ont été fortement réduites par rapport à celles du fioul lourd.
Procédé de détermination de la susceptibilité d’un microorganisme à un agent antimicrobien DOMAINE TECHNIQUE GENERAL
L’invention a trait au domaine de l’analyse microbiologique, et en particulier de la caractérisation de microorganismes, notamment la prédiction du caractère sensible ou résistant de levures, de moisissures et de bactéries à un agent antimicrobien.
On note que dans le premier mode de réalisation décrit ici, les communications au sein de l’entité applicative NFk entre ses différents modules et sous-modules logiciels s’appuient sur le protocole HTTP/2. Toutefois cette hypothèse n’est pas limitative en soi, et d’autres protocoles de communication peuvent être envisagés, comme par exemple les protocoles QUIC, RPC (pour « Remote Procedure Call » en anglais), CORBA, etc.
Par ailleurs, dans le premier mode de réalisation décrit ici, on a envisagé trois modules distincts (NFk-A, NFk-B, NFk-C) ; toutefois, ceci relève de choix d’implémentation de l’invention (par exemple trois micro-services reprenant respectivement la logique fonctionnelle de ces trois modules), et en variante, on peut envisager un autre choix d’implémentation de l’invention (par exemple, le module de notification embarquant le module de réception).
Lorsque l’ordinateur 3 héberge une entité de contrôle NRF 2 conforme à l’invention, sa mémoire morte 6 comprend un enregistrement d’un programme d’ordinateur PROG-2, comportant des instructions définissant les principales étapes d’un procédé de gestion selon le premier mode de réalisation de l’invention.
On note que, dans l’hypothèse où une architecture de micro-services est envisagée pour implémenter également l’entité de contrôle NRF 2, la fréquence des modifications du profil d’une entité applicative auprès de l’entité de contrôle, quelle que soit l’origine de ces modifications, est en général suffisamment faible pour qu’une seule instance d’un micro-service implémentant le module de réception suffise pour traiter le trafic des signalements. Par ailleurs, le trafic induit par les notifications émises par le module de notification pour les besoins de l’invention ne devrait avoir quasiment aucun impact sur la bande passante du réseau, même multiplié par le nombre d’entités applicatives de type fonctions réseau dans un réseau cœur 5G.
Nous allons maintenant décrire, en référence à la , les principales étapes d’un procédé de notification et d’un procédé de gestion selon l’invention, lorsqu’ils sont mis en œuvre respectivement par l’entité applicative NFk, k entier compris entre 1 et N, et l’entité de contrôle NRF 2 du système 1, dans le premier mode de réalisation.
Dans le premier mode de réalisation décrit ici, on suppose en préliminaire, que les entités applicatives NF1,…,NFN sont rattachées à l’entité de contrôle NRF 2 et ont été configurées avec une adresse de joignabilité (ex. URI pour « Uniform Resource Identifier ») de cette dernière. On suppose par ailleurs que les micro-services de chaque entité applicative NFk, k=1,…,N, portant un traitement sur un ou plusieurs attributs du profil de l’entité applicative NFk, ont souscrit préalablement auprès du module de notification NFk-C de l’entité applicative à la notification des événements affectant le profil de l’entité applicative NFk (ou éventuellement uniquement les attributs du profil en question les impactant), comme évoqué précédemment.
Dès le démarrage de l’entité applicative NFk (étape E10), le sous-module SUBS-MNGR de gestion de souscription de cette dernière crée une souscription auprès de l’entité de contrôle NRF 2 via son API afin de s’abonner aux notifications de tout événement affectant son propre profil auprès de l’entité de contrôle NRF 2 (autrement dit susceptible d’entrainer un changement du profil en question auprès de l’entité de contrôle NRF 2, quelle que soit la nature de ce changement (création, modification d’attributs, suppression)) (étape E20). A cet effet, il renseigne dans la requête de souscription qu’il adresse à l’entité de contrôle NRF 2 via son API (définie dans le document 3GPP TS 29.510 introduit précédemment) : l’attribut nfInstanceIdCond (qui désigne l’instance de fonction NF visée par la souscription) avec la valeur nfInstanceId de l’entité applicative NFk (comprise dans son propre profil NF_PROFk) ; l’attribut nfStatusNotificationUri (qui désigne la ressource vers laquelle envoyer les notifications) avec la valeur de l’adresse de joignabilité, à savoir l’URI dans l’exemple envisagé ici, du module de réception NFK-B qui est destiné à recevoir les notifications de mises à jour du profil NF_PROFk ; et de façon optionnelle, l’attribut validityTime (qui caractérise la durée de validité de la souscription) avec la date de fin de validité de la souscription. Il convient de noter que dans le premier mode de réalisation décrit ici, le sous-module SUBS-MNGR est configuré pour prolonger le cas échéant cette date d’expiration afin que la souscription reste toujours active pendant le fonctionnement de l’entité applicative NFk. Il peut à cet effet utiliser une opération UpdateSubscription connue en soi.
En variante, la souscription du sous-module SUBS-MNGR peut viser plus généralement des entités applicatives de même type que l’entité applicative NFk (plutôt que de désigner spécifiquement l’entité applicative NFk), par exemple assurant la même fonctionnalité ou encore correspondant à la même fonction réseau que l’entité applicative NFk, de sorte que toute modification affectant le profil d’une telle entité applicative (et donc incidemment de l’entité applicative NFk) est notifiée à l’entité applicative NFk et plus particulièrement à son module de réception NFk-B.
Sur réception de la demande de souscription de l’entité applicative NFk (étape F10), l’entité de contrôle NRF 2 via son module d’enregistrement 2-B enregistre les informations relatives à cette demande de souscription (étape F20).
Puis, dans le premier mode de réalisation décrit ici, une fois la souscription créée, le sous-module NFinst-MNGR de gestion enregistre auprès de l’entité de contrôle NRF 2 le profil NF_PROFk de l’entité applicative NFk, de façon connue en soi telle que décrite dans le document 3GPP TS 29.510 (paragraphe 5.2.2.2) (étape E30). Il envoie notamment ici une requête d’enregistrement HTTP PUT dans le corps de laquelle il fournit le profil NF_PROFk de l’entité applicative NFk.
Ce profil NF_PROFk, comme détaillé précédemment, comprend une pluralité d’attributs caractérisant l’entité applicative NFk, et notamment, dans l’exemple illustratif envisagé ici, les attributs listés dans le document TS 29.510 dans la table 6.1.6.2.2-1 en section 6.1.6.2.2. Ces attributs comprennent, de façon non exhaustive, l’identifiant ( nfInstanceId ) de l’entité applicative NFk (qui est une instance d’une fonction réseau donnée) à créer (le même identifiant que celui fourni lors de la souscription le cas échéant), le type ( nfType ) de l’entité applicative NFk (i.e. type de la fonction réseau ici), l’état ( nfStatus ) de l’entité applicative, son nom ( nfInstanceName ), le réseau PLMN (pour « Public Land Mobile Network » en anglais) ( plmnList ) auquel elle est rattachée, ses adresses IPv4 et IPv6 ( ipv4Addresses , ipv6Addresses ), sa priorité ( priority ) par rapport aux autres entités applicatives de même type (i.e. aux autres instances de la même fonction réseau), sa capacité ( capacity ), sa charge ( load ), sa localisation ( locality ), etc.
Cette demande d’enregistrement du profil NF_PROFk auprès de l’entité de contrôle NRF 2 constitue en soi un signalement d’un événement affectant le profil de l’entité applicative NFk destiné à être enregistré auprès de l’entité de contrôle NRF 2 au sens de l’invention.
Sur réception de la requête d’enregistrement par le module de réception 2-A de l’entité de contrôle NRF 2 (étape F30), cette dernière enregistre l’entité applicative NFk : elle mémorise son profil NF_PROFk à l’URI indiquée dans la requête d’enregistrement et associe à l’entité applicative NFk un état « disponible » (étape F40). Elle peut dès lors publier ce profil NF_PROFk auprès d’autres entités du réseau l’interrogeant à propos des entités applicatives qu’elle gère.
Par ailleurs, cet enregistrement déclenche l’envoi, par le module de notification 2-C de l’entité de contrôle NRF 2, d’une notification aux entités du réseau ayant souscrit à une notification des événements affectant le profil de l’entité applicative NFk, et en particulier, à l’entité applicative NFk elle-même (et plus spécifiquement à son module de réception NFk-B) (étape F50).
L’unité de traitement peut typiquement appartenir à un système tel qu’un microcontrôleur ou un microprocesseur.
Des niveaux de droits d’accès hiérarchisés sont par exemple les niveaux de droits d’accès privilégié et non-privilégié, le niveau de droits d’accès privilégié étant hiérarchiquement supérieur au niveau de droit d’accès non-privilégié.
D’autres niveaux de droits d’accès hiérarchisés sont par exemple les niveaux de droits d’accès sécurisé et non-sécurisé, le niveau de droits d’accès sécurisé étant hiérarchiquement supérieur au niveau de droit d’accès non-sécurisé.
Classiquement, les droits d’accès de niveau privilégié et de niveau non-privilégié permettent notamment de donner l’accès et d’empêcher l’accès à des fonctions sensibles du système, par exemple des fonctions de programmation de commandes du système, telles que la configuration du système au démarrage (usuellement « boot » en anglais) ou la programmation des droits d’accès. Certaines ressources matérielles, telles que des registres de piles, peuvent être dupliquée dans les domaines respectivement privilégiés et non-privilégiés.
Les droits d’accès de niveau sécurisé et de niveau non-sécurisé correspondent généralement à une séparation physique d’éléments matériels sécurisés et non-sécurisés, et à une séparation de mémoires ou de zones mémoires respectives. Les éléments sécurisés sont généralement prévus pour mettre en œuvre des fonctions critiques de sécurité, telles que les chiffrement/déchiffrement accédant à des données sensibles et secrètes.
On notera qu’une exécution dans des éléments matériels de niveau sécurisé ou non-sécurisé, peut avoir en outre une hiérarchie de contextes d’exécution privilégié et non-privilégié.
Lorsqu’un bug ou une injection de faute se produit, le système exécute des opérations incontrôlées, dans le sens où certaines instructions peuvent ne pas être exécutées, certaines instructions non-prévues peuvent être exécutées, et encore certains registres peuvent être utilisés avec des valeurs inattendues.
Selon l’événement ci-dessus se produisant, si le système est placé dans le contexte d’exécution ayant le niveau de droits d’accès hiérarchiquement supérieur, alors le système peut effectuer n’importe quelle opération et éventuellement exécuter une instruction qui ne devrait pas avoir le niveau de droits d’accès supérieur. Il s’agit d’une vulnérabilité du système, pouvant entraîner une fuite de secret, par exemple dans le cadre d’une analyse maîtrisée d’ingénierie inversée.
On se réfère aux figures 1A et 1B, illustrant schématiquement un flux d’exécution de tâches d’une unité de traitement ayant des contextes d’exécution hiérarchisés.
La illustre un problème classique pouvant se produire entre des contextes d’exécution privilégié CPU_Priv, et non-privilégié CPU_NPriv.
Dans une exécution normale Norm, les instructions exécutées INST_EXE dans le mode privilégié CPU_Priv peuvent accéder à des données DAT_ACCS de niveau privilégié Dat_Priv et non-privilégié Dat_NPriv ; et, les instructions exécutées INST_EXE dans le mode non-privilégié CPU_NPriv sont normalement prévues pour n’accéder qu’à des données DAT_ACCS de niveau non-privilégié Dat_NPriv.
En cas d’erreur Err dans une exécution normale, si des instructions exécutées INST_EXE dans le mode non-privilégié CPU_NPriv commandent un accès à des données DAT_ACCS de niveau privilégié Dat_Priv, alors le contexte d’exécution CPU_NPriv bloque cet accès non-permis NP.
Cela étant, la même erreur Err cumulée avec une autre erreur ou une injection de faute Err/Flt_inj empêchant la transition de contexte cxt_swtch de l’unité de traitement, peut effectivement provoquer un accès illicite à des données privilégiées Dat_Priv par une instruction non-privilégiée.
En effet, étant donné que la seconde erreur ou injection de faute Err/Flt_inj a provoqué que l’unité de traitement est restée dans le contexte privilégié CPU_Priv, les instructions prévues pour être exécutées dans le mode non-privilégié et commandant un accès à des données DAT_ACCS de niveau privilégié Dat_Priv, sont permises par le contexte d’exécution CPU_Priv.
La illustre un problème similaire pouvant se produire dans les contextes d’exécution sécurisé CPU_Sec et non-sécurisé CPU_NSec.
Etant donné la séparation matérielle entre les contextes d’exécution sécurisé CPU_Sec et non-sécurisé CPU_NSec, la vulnérabilité n’a pas lieu pendant les transitions de contexte NS->S cpy, S->NS cpy, usuellement hautement protégées, mais pendant une phase de traitement sécurisé Trtmt_S. En effet, les traitements sécurisés Trtmt_S comportent typiquement des phases de calculs, par exemple de cryptographie, visant la performance et en conséquence typiquement moins protégés. Ainsi une erreur ou une injection de faute Err/Flt_inj pendant la phase de traitement peut engendrer une écriture de données issues du traitement sécurisé CPU_Sec vers un emplacement mémoire non-sécurisé Dat_NSec (car le contexte d’exécution sécurisé CPU_Sec peut accéder par défaut au mode non-sécurisé, en particulier grâce à une unité de gestion de mémoire « MMU » (pour « Memory Management Unit » en anglais) et une unité d’attribution de sécurité « SAU » (pour « Secure Attribution Unit » en anglais) du processeur.
Il existe un besoin de prémunir les unités de traitement ayant des contextes d’exécutions hiérarchisés contre ce type de vulnérabilités et les dysfonctionnements en résultants.
Selon un aspect, il est proposé à cet égard un procédé comprenant une phase de compilation, au sein d’une unité de traitement, d’un programme logiciel destiné à être exécuté par ladite unité de traitement, ladite unité de traitement pouvant avoir des contextes d’exécution de niveau de droits d’accès sécurisé et non-sécurisé et/ou des contextes d’exécution de niveau de droits d’accès privilégié et non-privilégié, le procédé comprenant une phase de compilation générant des instructions en langage machine ayant un niveau de droits d’accès exclusivement sécurisé si ces instructions sont destinées à être exécutées dans le contexte d’exécution de niveau de droits d’accès sécurisé, et des instructions ayant un niveau de droits d’accès non-privilégié si ces instructions sont destinées à être exécutées dans le contexte d’exécution de niveau de droits d’accès non-privilégié.
En effet, d’une part la hiérarchie entre les niveaux sécurisé et non-sécurisé est typiquement faite de sorte que le niveau sécurisé est capable d’accéder dans le niveau de droit d’accès sécurisé et dans le niveau de droit d’accès non-sécurisé, tandis que le niveau non-sécurisé est capable d’accéder dans le niveau de droit d’accès non-sécurisé uniquement. D’autre part, la hiérarchie entre les niveaux privilégié et non-privilégié est typiquement faite de sorte que le niveau privilégié est capable d’accéder dans le niveau de droit d’accès privilégié et dans le niveau de droit d’accès non-privilégié, tandis que le contexte d’exécution de niveau non-privilégié est capable d’accéder dans le niveau de droit d’accès non-privilégié uniquement.
Or, dans un mode de mise en œuvre, lors d’une phase d’exécution du programme logiciel compilé, au sein de l’unité de traitement, lesdites instructions ayant le niveau de droits d’accès exclusivement sécurisé sont capable d’accéder à des zones mémoires de niveau de droit d’accès sécurisé et sont incapable d’accéder à des zones mémoires ayant le niveau de droit d’accès non-sécurisé.
En d’autres termes, les instructions en langage machine générées par la phase de compilation selon cet aspect seront intrinsèquement incapables de produire un accès illicite vers des données de niveau de droit d’accès ne correspondant pas au niveau dans lequel elles sont exécutées.
Ainsi, d’une part une instruction exécuté dans le niveau sécurisé ne peut pas engendrer une écriture de données issues du contexte d’exécution sécurisé vers un emplacement mémoire non-sécurisé.
Et d’autre part, une instruction ayant le niveau de droit d’accès non-privilégiée ne peut pas provoquer un accès à des données privilégiées, et même si l’unité de traitement est forcée dans le contexte d’exécution le plus « permissif », c’est-à-dire par exemple dans le cas où une transition de contexte à échouée et l’unité de traitement est restée dans le contexte d’exécution de niveau de droit d’accès privilégié pour exécuter des instructions normalement destinées au contexte d’exécution de niveau non-privilégié.
En pratique, l’instruction ayant le niveau de droit d’accès non-privilégiée pourra faire une tentative d’accès à des données privilégiées, ce qui générera une exception. L’exception pourra être traitée par le processeur qui pourra décider comment gérer cette tentative illicite (et par exemple effectuer une réinitialisation complète, un redémarrage de l’application, ou d’autres mesures).
Selon un mode de mise en œuvre, la phase de compilation génère les instructions ayant le niveau de droits d’accès exclusivement sécurisé si ces instructions sont destinées à être exécutées dans une phase de traitement particulière du contexte d’exécution de niveau de droits d’accès sécurisé, par exemple une phase de traitement sécurisé typiquement plus vulnérable aux attaques que d’autres phases du contexte d’exécution sécurisé.
Selon un mode de mise en œuvre, la phase de compilation comprend : - une génération des instructions en langage machine indistinctement des contextes d’exécution auxquels ces instructions sont destinées à être exécutées, et - un post-traitement des instructions générées, adapté pour remplacer au moins certaines instructions générées ayant un niveau de droits d’accès ne correspondant pas au niveau de droits d’accès de son contexte d’exécution par des instructions ayant le niveau de droits d’accès correspondant au niveau de droits d’accès de son contexte d’exécution.