Auteur Sujet: Capacité d'un processeur à gérer le https  (Lu 8151 fois)

0 Membres et 1 Invité sur ce sujet

e-TE

  • Client Free fibre
  • *
  • Messages: 750
  • Déville-les-Rouen (76)
Capacité d'un processeur à gérer le https
« Réponse #24 le: 31 décembre 2015 à 13:32:24 »
c'est pas plutôt des processeurs qui avaient deja les circuits pour, mais dont le support n'avait pas eu le temps d'être suffisamment fait pour l'introduire "officiellement" dès le début? et après coup, l'implèmentation a passé les tests et la modif du bios permettrait de faire connaitre au système que le support est présent?
tout comme certaines cartes graphiques sont bridés par le bios pour désactiver certaines parties?

Marin

  • Client Bbox vdsl
  • Modérateur
  • *
  • Messages: 2 783
  • 73
Capacité d'un processeur à gérer le https
« Réponse #25 le: 31 décembre 2015 à 13:43:44 »
et la modif du bios permettrait de faire connaitre au système que le support est présent?

À priori, le BIOS n'est qu'un des moyens possibles de pousser une version récente du microcode vers le CPU (on peut aussi le faire côté OS). Je ne vois donc pas spécialement de raison de se focaliser dessus.

corrector

  • Invité
Capacité d'un processeur à gérer le https
« Réponse #26 le: 31 décembre 2015 à 13:49:36 »
Quelles sont les protections contre une reprogrammation du CPU?

Marin

  • Client Bbox vdsl
  • Modérateur
  • *
  • Messages: 2 783
  • 73
Capacité d'un processeur à gérer le https
« Réponse #27 le: 31 décembre 2015 à 13:53:09 »
Signature (RSA probablement impliqué). Documenté ici :

(cliquez sur la miniature ci-dessous - le document est au format PDF)

vivien

  • Administrateur
  • *
  • Messages: 32 863
    • Twitter LaFibre.info
Capacité d'un processeur à gérer le https
« Réponse #28 le: 31 décembre 2015 à 14:14:02 »
Ubuntu propose dans la partie "pilotes propriétaires" un microcode pour le processeur Intel :



A noter, qu'il faut relativiser le "ce périphérique ne fonctionne pas" : Pour la carte WiFi Broadcom, les drivers libres fonctionnent bien, d'où la non utilisation des drivers propriétaires :


02:00.0 Network controller: Broadcom Corporation BCM43224 802.11a/b/g/n (rev 01)
Subsystem: Dell Wireless 1520 Half-size Mini PCIe Card
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 17
Region 0: Memory at f4100000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=2 PME-
Capabilities: [58] Vendor Specific Information: Len=78 <?>
Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000  Data: 0000
Capabilities: [d0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us
ClockPM+ Surprise- LLActRep+ BwNot- ASPMOptComp-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP+ BadDLLP+ Rollover- Timeout+ NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [13c v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 00-00-fa-ff-ff-5e-88-9f
Capabilities: [16c v1] Power Budgeting <?>
Kernel driver in use: bcma-pci-bridge

corrector

  • Invité
Capacité d'un processeur à gérer le https
« Réponse #29 le: 31 décembre 2015 à 14:24:22 »
Signature (RSA probablement impliqué). Documenté ici :
Très intéressant!

Paul

  • Client Bell (Canada)
  • *
  • Messages: 4 146
  • Varennes, QC (CA)
    • Twitter
Capacité d'un processeur à gérer le https
« Réponse #30 le: 01 janvier 2016 à 15:53:23 »
C'est un des processeurs les plus catastrophiques d'Intel : Le Pentium III à seulement 1 ghz fait aussi bien.
Alors que la pub promettait un gain jusqu’à 100% ramené a une fréquence d'horloge identique entre Pentium IV et Pentium III.

Il y avait ce problème de puissance, mais aussi la RDRAM qui coûtait un bras et la fonction chauffage d'appoint (et du coup, fonction réacteur à cause des ventilos).

 

Mobile View