# patchare il kernel

## iko

Una domanda che mi pongo da parecchio tempo...  

Ma ci sono problemi a installare patch del kernel su gentoo   :Question: 

Sarei in questo caso interessato ad installare la patch di suspend2 su un kernel hardened. (Sono a conoscenza che esiste nel portage già il kernel patchato ma non è hardened)

grazie

ciao

Fede

----------

## crisandbea

 *iko wrote:*   

> Una domanda che mi pongo da parecchio tempo...  
> 
> Ma ci sono problemi a installare patch del kernel su gentoo  
> 
> Sarei in questo caso interessato ad installare la patch di suspend2 su un kernel hardened. (Sono a conoscenza che esiste nel portage già il kernel patchato ma non è hardened)
> ...

 

quale lo scopo per fare ciò ???  comunque se le patch sono compatibili credo che modificando l'ebuild dovresti farcela.Last edited by crisandbea on Tue Mar 06, 2007 2:47 pm; edited 1 time in total

----------

## gutter

Se le due patch non sono incompatibili, potresti provare a modificare uno degli ebuild ed aggiungere il patchset.

----------

## iko

 *crisandbea wrote:*   

> 
> 
> quale lo scopo per fare ciò ???  

 

Beh avere un kernel con le features hardened e la comodità dell hibernate... xchè è cosi strano? forse c'è qualcosa che ignoro?   :Confused: 

----------

## iko

 *gutter wrote:*   

> Se le due patch non sono incompatibili, potresti provare a modificare uno degli ebuild ed aggiungere il patchset.

 

Uhmm chiedo perchè quando ho lanciato il 

```

patch -p1 < suspend.patch

```

tutto è andato a buon fine salvo per il fatto che mi ha generato un file signal.c.rej

```

  #include <linux/ptrace.h>

  #include <linux/signal.h>

  #include <linux/capability.h>

  #include <asm/param.h>

  #include <asm/uaccess.h>

  #include <asm/unistd.h>

--- 23,29 ----

  #include <linux/ptrace.h>

  #include <linux/signal.h>

  #include <linux/capability.h>

+ #include <linux/freezer.h>

  #include <asm/param.h>

  #include <asm/uaccess.h>

  #include <asm/unistd.h>

```

----------

## djinnZ

le patch possono essere realmente incompatibili a livello di codice (ovvero grsec non può andare d'accordo con hibernate, ma non mi pare) oppure possono essere incompatibili a livello di diff.

Mi spiego meglio se il la patch di hibernate è stata costruita su un kernel vanilla e deve modificare la funzione x alla riga 100 di un file e tu ci applichi grsec prima che midifica la funzione y precedente facendo sì che x sia alla riga 200 patch fallisce quella parte della modifica e la scarta in un apposito file .rej .

Manualmente vai a vedere come deve essere inserita e modifichi il sorgente. A questo punto dovrebbe funzionare.

Ovviamente da questo puoi creare un tuo patchset ma non so se è per pigrizia dei devel ;-P (se i file e le differenze sono parecchie è un lavoraccio infame e non è detto che alla fine funziona) o perchè non è nella linea "politica" di gentoo stravolgere il codice a questa maniera.

Prova a farti un tuo ebuild a partire da uno dei due, lancialo con ebuild unpack e verifica in work se sono state applicate tutte correttamente, altrimenti riprova sino a trovare l'ordine che comporta meno modifiche. Se ci riesci senza avere modifiche manuali, ovviamente, riporta un bug con l'ebuild.

edit: ha scritto prima che finissi. cmq devi verificare se è solo l'include che è stato scartato od anche altro ma ti conviene provare con un ebuild non con un kernel già patchato può essere che dipenda da una qualsia delle patch.

----------

## crisandbea

 *iko wrote:*   

>  *crisandbea wrote:*   
> 
> quale lo scopo per fare ciò ???   
> 
> Beh avere un kernel con le features hardened e la comodità dell hibernate... xchè è cosi strano? forse c'è qualcosa che ignoro?  

 

non è strano, lo chiedevo per curiosità, e sopratutto se ne avevi la reale necessità di usare un kernel hardened. tutto qua..

il contenuto del file che dicevi è quello che hai postato??? 

se cosi fosse mi sembrano solo inclusioni di librerie di sistema, suppongo utili al funzionamento di alcune cose.

ciao

----------

## iko

 *djinnZ wrote:*   

> 
> 
> Manualmente vai a vedere come deve essere inserita e modifichi il sorgente. A questo punto dovrebbe funzionare.
> 
> 

 

L'unico problema che c'era era nella riga dell'include perchè infatti c'era l'include del grsecurity che sballava la "posizione" in cui doveva essere messo l header del suspend.

L'ho inserito a mano e tutto è stato compilato.

Ora devo solo verificare dopo il reboot se funziona...

Visto la domanda che mi è stata fatta sul perchè... è per caso sbagliato concettualmente avere un kernel hardened con il supporto per l hibernate?

grazie

ciao

Fede

----------

## iko

 *crisandbea wrote:*   

>  *iko wrote:*    *crisandbea wrote:*   
> 
> quale lo scopo per fare ciò ???   
> 
> Beh avere un kernel con le features hardened e la comodità dell hibernate... xchè è cosi strano? forse c'è qualcosa che ignoro?   
> ...

 

Scusa mi hai anticipato di poco nella risposta   :Laughing: 

Beh, si tratta di un server quindi mi sarebbe utile installare un kernel hardened... L'uso di hibernate lo vorrei in quanto certe volte sono obbligato a spegnerlo e quando eseguo delle operazioni come ad esempio l'emerge di un pacchetto grosso non vorrei combinare danni stoppandolo.

----------

## djinnZ

No, ma come ti ho detto i devel possono aver scelto di non fare modifiche alle patch per evitare confusioni (se per questa versione ha funzionato non è detto che sia stato possibile per le precedenti e che lo sarà in futuro) ma può essere anche che sino ad ora nessuno lo ha richiesto. Per questo ti ho consigliato di renderlo sistematico con un ebuild e sottoporlo.

----------

## .:chrome:.

 *iko wrote:*   

> Beh, si tratta di un server quindi mi sarebbe utile installare un kernel hardened... L'uso di hibernate lo vorrei in quanto certe volte sono obbligato a spegnerlo e quando eseguo delle operazioni come ad esempio l'emerge di un pacchetto grosso non vorrei combinare danni stoppandolo.

 

non è per niente vero, quello che dici sull'hardened.

non è detto che se hai una macchina che offre servizi sia necessario, anzi... ci sono molte controindicazioni, specie quando si hanno in mano macchine per la produzione.

quanto al suspend, scusa se te lo dico, ma sono indeciso se definirla una bestemmia o una follia. suspend su una macchina per la produzione è pericolosissimo. parli di sicurezza e poi vuoi sospendere il sistema. queste due cose non possono coesistere nello stesso discorso, sia che tu mi parli di sicurezza intesa come integrità dei dati, che come confidenzialità.

se vuoi un consiglio, punta sugli hardened-sources standard senza nemmeno abilitare né PaX né GRSecurity

----------

## djinnZ

Non sarei così categorico. In fin dei conti una utilità, limitata, potrebbe esserci, ovviamente su server di tipo più casalingo o esposti ad utenze particolarmente strafottenti.

Poni il caso che cade la tensione, lavori per un pò, ricade, rilavori per un pò (trovami un utonto medio che non lo fa, anche in ambiti più professionali) fino a che non esaurisci quasi del tutto la carica della batteria e ti restano un paio di minuti di autonomia e sai che il computer ci mette in genere due/tre minuti. A questo punto cosa fai?

Usi il suspend e fermi il pc in attesa che la linea si ristabilisce e che la batteria si sia ricaricata a sufficienza per poter riavviare e fare uno shutdown in sicurezza o rischi che l'arresto sia incompleto?

Un comportamento decisionale del genere non è implementato ancora, se non erro, ma potrebbe essere interessante come _ulteriore_ ripeto _ulteriore_ misura di sicurezza (oltre ad un serio blocco che impedisca agli idioti di continuare ad accendere il computer anche se l'autonomia è agli sgoccioli).

Al di fuori di usi del genere quoto quanto sopra.

Usare hibernate per fermare la macchina durante un emerge è pericoloso, se proprio hai necessità di riprendere usa la festure keeptemp.

----------

## Kernel78

 *djinnZ wrote:*   

> Poni il caso che cade la tensione, lavori per un pò, ricade, rilavori per un pò (trovami un utonto medio che non lo fa, anche in ambiti più professionali) fino a che non esaurisci quasi del tutto la carica della batteria e ti restano un paio di minuti di autonomia e sai che il computer ci mette in genere due/tre minuti. A questo punto cosa fai?

 

Presumo che con batteria tu intenda la batteria di un ups ma per il resto il tuo esempio mi rimane completamente oscuro, potresti spiegarti meglio ?

Grazie.

----------

## .:deadhead:.

 *djinnZ wrote:*   

> ...

 

Tu avrai fatto le tue analisi e probabilmente sarai giunto a questa conclusione. 

Personalmente non mi metteri a patchare un kernel già pesantemente patchato come quello hardened che a dir poco stravolge molti dei funzionamenti interni dei kernel vanilla.

Cmq se hai un UPS , non credo che tu abbia bisogno dei suspend: ti basta configurare correttamente il demone apcupsd e dargli lo shutdown quando la batteria ha n minuti rimanenti. Inoltre puoi impostare la macchina affinchè torni su quanto la corrente è tornata. C'è da dire che forse + che un kernel suspend , ci sarebbe del lavoro da fare con l'elettricista.

----------

## djinnZ

Dato che l'affidabilità della rete elettrica dove ho lo studio è a livelli da terzo mondo per causa del tipico megacantiere del piffero (ed augurando "devotamente il cancher nel core" a chi ha deciso l'opera) appena capita una giornata più ventosa od arriva il natale con le dannate luminarie per strada inizio ad avere continue interruzioni di breve durata. Quindi mi sono posto il problema per "necessità".

Mettiamo che l'autonomia a piena carica è di un'ora, se la linea si interrompe per cinque minuti in una giornata tutto a posto, se va via per due ore ad un certo punto il pc si spegne. Fin qui siamo nella normale gestione del monitor UPS etc.

Ma che succede se ogni 15 minuti l'alimentazione si interrompe per due/tre minuti (o peggio sono "semplici" cali di tensione)? Arrivi verso le cinque del pomeriggio (quindi quando manca troppo per rimandare il lavoro a domani e troppo poco per attendere) con autonomia praticamente a zero. Ed al primo blackout il computer si spegne senza terminare lo shutdown o mentre sta terminando l'avvio, perchè qualche imbecille va a provare a riaccenderlo in continuazione, lo dico per esperienza.

@deadhead

proprio impostare il riavvio automatico ti può mettere a rischio, anche senza deficienti di torno. La scansione iniziale dei dischi è una fase critica indipendentemente dal filesystem che usi. Un arresto improprio può sempre fare danni. Hybernate può essere una soluzione quando l'alternativa non esiste.

Sempre perchè vi sfido a trovare un utonto medio che non va a riaccendere il computer appena torna la luce senza pensare che sarebbe il caso di dare un paio di minuti alla batteria per riprendersi o dare uno sguardo al display, se c'è. Per quanto possa sommergere di improberi le collaboratrici o quel decerebrato del praticante in mia assenza lo fanno sempre, non è che lo fanno apposta, non ci arrivano proprio.

Ed ho fior di colleghi che trovo sempre alle prese con backup mancati e lavoro da rifare perchè sono loro i primi a fare queste stronzate.

Premesso che questa è una delle tante cose che ho nel cassetto dei ToDo sto parlando, supponendo ups che ti assicura 30 minuti di autonomia a piena carica, un uptime al remount di 30 secondi, avvio completo 1 minuto e shutdown in uno e mezzo, di impostare sempre lo shutdown automatico nell'ups monitor da:

se autonomia < 10 minuti spegni (come si fa di solito per star tranquilli)

a

se autonomia < 5 minuti allora se autonomia < 2 hybernate altrimenti spegni

oppure inserire in apcontrol all'evento loadlimit se autonomia < 2 hybernate dopo la notifica (in questo modo al reboot l'unica cosa che il sistema proverà a fare sarà terminare prima lo shutdown, che secondo me è la soluzione più logica). 

ed aggiungere in rc (prima dell'fsck, non del remount rw di root e del mount -a, ovviamente)

se autonomia < 5 minuti spegni.

Così sei al riparo da ogni possibilità di errore. Anche se l'hibernate è inaffidabile lo è sempre meno del tirare la spina. Ed ovviamente al resume non si deve lavorare ma solo terminare correttamente lo shutdown. A queste condizioni è una ulteriore misura di sicurezza contro l'utenza cretina con server ad avvio automatico o non presidiati.

Ovviamente devi chiamare un programma che non fa parte dell'albero principale ma di usr direttamente in rc per monitorare l'ups al boot e questo non è che va molto d'accordo con norme standard e consuetudini, in particolare con l'avvio da initrd.

E ripeto, in mancanza di incompatibilità dichiarate tra le due patch, su un server può essere una ulteriore soluzione.

Poi sulle gestione di un portatile con kernel suspend2 normale questo approccio può portare ad usare dei limiti ridotti con maggiore sicurezza rispetto alle impostazioni standard.

----------

